[script] repack-zImage.sh: Unpack and repack a zImage without kernel source, V. 5

Search This thread

mumbozver

Member
Feb 13, 2011
48
39
Thank for great work.

I have request, can You add LZMA compressed zImage support?
Lastest fugumod has LZMA compression, I tried Lestatious 1.8 - Fugumod 2.2 ALPHA 14 from here
 

mumbozver

Member
Feb 13, 2011
48
39
If you need something, I could give it to you ... just ask me :)

I already can extract init files from running kernel, however if they not deleted by later init scripts.
For me more interesting to change init scripts, and put it back to kernel image without compiling kernel myself or ask You to put something in initramfs. Repacking kernel images just more faster.
 

nullghost

Retired Recognized Developer
Jan 4, 2011
143
209
Oxford, OH
twitter.com
mizch: I'm getting an error related to the variable at_min
Code:
Trying size: 7793816  3896908./repack-zImage.sh: line 284: [: : integer expression expected

At some points it seems to have integers assigned to it, while at other points it seems to have the string "yes" assigned to it.
 

mizch

Senior Member
Nov 11, 2010
158
79
To reproduce the error, can you tell me what kernel you are using it on (download location)?
 

vishwanathptl

Retired Recognized Developer
Jun 1, 2009
260
927
37
Bangalore
mizch great work.

but it wont work on my zImage. its froyo kernel (GALAXY FIT s5670).

my zImage is abt 2.0 MB if pulled from mobile and its abt 3.0 MB if extracted from boot.img.

i am confused. i am not getting the rite zImage. plz help me. if u say i wil post both the zimages here. trying from 2 months but not getting anything.
 

mizch

Senior Member
Nov 11, 2010
158
79
I need to be able to reproduce the error here. So please provide a download link to the zImage in question (it's not a problem if it is buried in some .tar for flashing) and I'll look how I can help you.
 

mizch

Senior Member
Nov 11, 2010
158
79
Sorry, I cannot extract the zImage for you. This is out of scope for this program and for me. Please ask in a forum which handles your brand of phone how to get at the zImage. When you've extracted it and if the script here doesn't handle it, I'll gladly try to help.

I simply cannot be expected to know where each of those many hardwares around bury their zImage, nor do a Google research on this for any number of them. So I hope you can understand that you're on your own with that.
 

vishwanathptl

Retired Recognized Developer
Jun 1, 2009
260
927
37
Bangalore
its k i can understand but wen i tried with HTC Android Kitchen 0.161 - by dsixda, it extracted zImage and ramdisk. but wen i compared my ramdisk with the initramfs of I5700, there wer some files missing in mine. i dont kmow if kitchen extracted the ramdisk completely. Can u help me with this? can u tell me that kitchen extracted the ramdisk completely? Plz..... here is my boot img extracted from my device.The previous one was from firmware files downloaded from samfirmware.com.

http://www.mediafire.com/?9eq16hbxtgkjcb9
 

dxdiag32

Senior Member
Feb 21, 2011
902
350
Chongqing
i have some issue.
i unpack a zImage and then pack it,without any modifications.
but i can't flash it ,it stays bootlogo,what should i do?
 

brisk5181

Senior Member
Jan 17, 2011
143
11
www.galaxycommunity.com
Hmm, not working for me:

I always got this error:

./repack-zImage.sh -uv
Warning: there is aready an unpacking directory. If you have files added on
your own there, the repacking result may not reflect the result of the
current unpacking process.
mkdir -p /work/arm/1/zImage_unpacked
cd /work/arm/1/zImage_unpacked

repack-zImage.sh: Can't find a gzip header in file 'zImage'
Terminated


I am using openSUSE 11.2 "Emerald" - Kernel \r (\l).

I tried 2 zImages, one is from

http://derek.theblog.ca/galaxys-i9000m-gingerbread-upgrade
(file: http://www.multiupload.com/N8D9XZ1PIF)

and the speedmod kernel speedmod-kernel-k13e-500hz.tar

Both result the same error.

I tried both V6 and V4 of the script, same thing

Anyone can help?
 

arunmcops

Inactive Recognized Developer
Apr 20, 2010
1,378
862
Bareilly
OnePlus 6
Xiaomi Poco F3
Hi mizch,
I am getting this error when i am trying to unpack any zImage

repack-zImage.sh: Can't find a gzip header in file 'zImage'
Terminated

(Ubuntu 11.04 x32)

But same kernel i tried to unpack on Ubuntu 10.04/10.10 x64 works perfectly.

So this can't be scripts fault . OS fault possible ?
 

Dharam_Maniar

Retired Recognized Developer
Nov 24, 2010
2,555
3,009
33
Hi mizch,
I am getting this error when i am trying to unpack any zImage

repack-zImage.sh: Can't find a gzip header in file 'zImage'
Terminated

(Ubuntu 11.04 x32)

But same kernel i tried to unpack on Ubuntu 10.04/10.10 x64 works perfectly.

So this can't be scripts fault . OS fault possible ?
well, that can be the reason...I got it working on 10.10, and cdesai couldnt get it worked for 11.04...
 

Top Liked Posts

  • There are no posts matching your filters.
  • 36
    repack-zImage.sh is a bash script for Linux which allows you to unpack a kernel image (zImage) for modification and repack it afterwards into a new working kernel image.

    You don't need a kernel tree for this program nor a compiler. It should work with any zImage that contains an initramfs, for whatever phone, operating system or CPU architecture you like.

    My main purpose when I wrote it was to modify the initramfs of leaked Samsung i5800 firmware for which no kernel source is available.

    Usage:
    =====

    Put the unzipped script into some directory along your $PATH (e.g., /usr/local/bin). Put the unpacked files from initramfs_utils.zip into /usr/local/bin.

    Then simply run 'repack-zImage.sh -u' with your zImage in the current directory and it will create a directory named 'zImage_unpacked' which contains the unpacked blocks of your zImage. Refer to the comments near the start of the program to identify which file corresponds to which fragment of the original zImage. (The file name of the zImage should be "zImage". If it isn't, pass it as the only non-option argument. The subdirectory's name will change accordingly.)

    Most notably, there will be a directory 'initramfs' in there, which contains all files from the original initramfs in their original tree. You can modify the contents as you like, but keep in mind that your initramfs cannot grow larger than the space reserved for it in the original zImage. So you're restricted to relatively small changes which should, however, satisfy many needs. You always can call a script or executable on some other partition (including the SD card if already mounted) if you need more room for your modifications.

    After your modifications are done, cd back to the directory which contains zImage and zImage_unpacked and run 'repack-zImage.sh -p' to start the packing process.

    This will create a directory called 'zImage_packing' which contains your new zImage (and a zImage.tar for loaders like ODIN). It will emit (between others) one or two messages about a padding being done and about how many bytes were padded. This number (or the lower number of the two) is an indication about how many compressed bytes are left for further additions to the initrd.

    If your initramfs (or some other modified part) grows too large, the script will abort with an appropriate error message.

    In initramfs-utils.zip, three programs are provided. They should be copied to /usr/local/bin:
    * cpio_set0. This is a slightly modified cpio (compiled for 32 bit Linux). repack-zImage.sh will run without it, but there may be slightly more room in your initramfs if you use the modified one. It sets all file times in the archive to 0 (epoch), thus yielding better and consistent compression results. Else, the size of the compressed initramfs will differ from invocation to invocation due to differing atimes. Put it somewhere along your $PATH (e.g., /usr/local/bin).
    * gen_init_cpio and
    * gen_initramfs_list.sh. These are utilities copied from a kernel tree and used to support creation of an initramfs (in certain modes).

    'repack-zImage.sh --help' will output usage information.


    Happy hacking,

    mizch


    Current Version: 6
    2011-05-03
    ('repack-zImage.sh --version' will output version information.)

    - added support for lzma compressed ramdisks (both directions)

    Version 4
    2011-02-17

    - Workaround for ambiguous gunzip result, see post #20
    - Some code cleanup + CLI cleanup
    - better error detection

    Version 3
    2011-01-06

    - now also works with unzipped initramfs withing gzipped zImage part (i.e., all kinds of zImages)

    Version 1
    2011-01-05

    - initial version. Works only for gzipped initramfs within gzipped zImage (e.g., G3 Eclair kernels)

    -----------------------
    repack-zImage.zip contains version 4 of the script.
    For the newest version, download repack-zImage.v6.zip and initramfs-utils.zip.
    3
    Good work.

    Is this based off the i9000 script?

    Also, I've noticed with the i5800 Eclair firmwares that the initramfs is gzipped AND cpio'd. So... Kernel + initramfs.cpio.gz are gzipped together.

    Basically you need to extract [kernel+initramfs.cpio.gz].gz, extract initramfs.cpio.gz again, then extract initramfs with cpio.

    On Froyo, the kernel + initramfs.cpio is gzipped together, but nothing more. So after you extract the kernel and initramfs, you just need to extract with cpio after that.

    Hope that kind of helps..
    3
    repack-zImage.sh is a bash script for Linux which allows you to unpack a kernel image (zImage) for modification and repack it afterwards into a new working kernel image.

    You don't need a kernel tree for this program nor a compiler. It should work with any zImage that contains an initramfs, for whatever phone, operating system or CPU architecture you like.

    My main purpose when I wrote it was to modify the initramfs of leaked Samsung i5800 firmware for which no kernel source is available.

    Usage:
    =====

    Put the unzipped script into some directory along your $PATH (e.g., /usr/local/bin). Put the unpacked files from initramfs_utils.zip into /usr/local/bin.

    Then simply run 'repack-zImage.sh -u' with your zImage in the current directory and it will create a directory named 'zImage_unpacked' which contains the unpacked blocks of your zImage. Refer to the comments near the start of the program to identify which file corresponds to which fragment of the original zImage. (The file name of the zImage should be "zImage". If it isn't, pass it as the only non-option argument. The subdirectory's name will change accordingly.)

    Most notably, there will be a directory 'initramfs' in there, which contains all files from the original initramfs in their original tree. You can modify the contents as you like, but keep in mind that your initramfs cannot grow larger than the space reserved for it in the original zImage. So you're restricted to relatively small changes which should, however, satisfy many needs. You always can call a script or executable on some other partition (including the SD card if already mounted) if you need more room for your modifications.

    After your modifications are done, cd back to the directory which contains zImage and zImage_unpacked and run 'repack-zImage.sh -p' to start the packing process.

    This will create a directory called 'zImage_packing' which contains your new zImage (and a zImage.tar for loaders like ODIN). It will emit (between others) one or two messages about a padding being done and about how many bytes were padded. This number (or the lower number of the two) is an indication about how many compressed bytes are left for further additions to the initrd.

    If your initramfs (or some other modified part) grows too large, the script will abort with an appropriate error message.

    In initramfs-utils.zip, three programs are provided. They should be copied to /usr/local/bin:
    * cpio_set0. This is a slightly modified cpio (compiled for 32 bit Linux). repack-zImage.sh will run without it, but there may be slightly more room in your initramfs if you use the modified one. It sets all file times in the archive to 0 (epoch), thus yielding better and consistent compression results. Else, the size of the compressed initramfs will differ from invocation to invocation due to differing atimes. Put it somewhere along your $PATH (e.g., /usr/local/bin).
    * gen_init_cpio and
    * gen_initramfs_list.sh. These are utilities copied from a kernel tree and used to support creation of an initramfs (in certain modes).

    'repack-zImage.sh --help' will output usage information.


    Happy hacking,

    mizch


    Current Version: 6
    2011-05-03
    ('repack-zImage.sh --version' will output version information.)

    - added support for lzma compressed ramdisks (both directions)

    Version 4
    2011-02-17

    - Workaround for ambiguous gunzip result, see post #20
    - Some code cleanup + CLI cleanup
    - better error detection

    Version 3
    2011-01-06

    - now also works with unzipped initramfs withing gzipped zImage part (i.e., all kinds of zImages)

    Version 1
    2011-01-05

    - initial version. Works only for gzipped initramfs within gzipped zImage (e.g., G3 Eclair kernels)

    -----------------------
    repack-zImage.zip contains version 4 of the script.
    For the newest version, download repack-zImage.v6.zip and initramfs-utils.zip.

    Thank you for this utility. I've taken the liberty of making a couple of bugfixes - one to initialise compress_list in the -3 option case, and the other to initialise at_min to 0 rather than blank in gunzipWithTrailer. The first stops the -3 option hanging, and the second is cosmetic and prevents sh complaining.

    I can confirm it works with zImage 4.0.4 XWLPT for the Samsung Galaxy S II (i9100).

    Peter
    3
    I'm assuming this tool is dead, as I get same errors as last posters and seems no one can post the cause
    try following the same steps i've given in my kernel development tutorials and you shouldnt get any errors...
    2
    Got the zImage, thanks. I could reproduce the problem. What happens:

    Using gzip's magic number, I can tell the start of a gzipped section. To determine its end, I need the help of gunzip. It reports "trailing garbage" if its file is too long, "truncated file" if too small, "OK" otherwise.

    With your zImage, gunzip reports "truncated" when fed with 5749017 bytes, "trailing garbage" at 5749018. Obviously, only one of the two (not both!) can be correct. But this is what gunzip reports in your case. I found that 5749016 is the correct size. Erm.

    As a workaround, I now detect when the gunzip result is oscillating this way and if it does, I search nearby towards lower size values for an exact match. This is not an ideal solution but I have to deal with what gunzip returns and this fits it best.

    I'll do some cleanup and some final tests now and if they succeed, I will post the new version in about an hour or so in the first posting of this thread.

    EDIT: New version posted.