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.
It didn't work on zImage from Froyo firmware i tried. Great work however .
Works however for Eclair firmwares i've tested.
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..
In didn't go into Froyo for the i5800 until now. I used Eclair. It eases testing if you can compare things to a working kernel tree.
I see that Froyo doesn't use a compressed initramfs within the compressed kernel (which I doubt to make much sense anyway since compressing an already compressed part again is likely to produce a larger result). In theory, thus Froyo is easier to cope with than what I have now, but I have to write the code to handle it. This will need some time, maybe tomorrow, maybe the weekend.
And, no, this is not based on code from the i9000. It was written up from scratch. But I took some ideas from there and thank dkcldark for his good work.
mizch said:
In didn't go into Froyo for the i5800 until now. I used Eclair. It eases testing if you can compare things to a working kernel tree.
I see that Froyo doesn't use a compressed initramfs within the compressed kernel (which I doubt to make much sense anyway since compressing an already compressed part again is likely to produce a larger result). In theory, thus Froyo is easier to cope with than what I have now, but I have to write the code to handle it. This will need some time, maybe tomorrow, maybe the weekend.
And, no, this is not based on code from the i9000. It was written up from scratch. But I took some ideas from there and thank dkcldark for his good work.
Click to expand...
Click to collapse
If we can get this modified for Froyo, it will allow for native ext2 mounting within the initramfs. Then we can add things to it like the way CWM works - busybox, adb, etc... So that we have a recovery adb setup before /system mounts.
precurse said:
If we can get this modified for Froyo, it will allow for native ext2 mounting within the initramfs. Then we can add things to it like the way CWM works - busybox, adb, etc... So that we have a recovery adb setup before /system mounts.
Click to expand...
Click to collapse
Exactly, that could be very useful, since we could get ext2 (ext4 maybe if we compile it as a module ?) in /data natively
Gsam101 said:
Exactly, that could be very useful, since we could get ext2 (ext4 maybe if we compile it as a module ?) in /data natively
Click to expand...
Click to collapse
I already tried building ext4 and other modules off the i9000 sources... Didn't seem to work too well. Kept complaining about memmap or some random errors when I tried loading them.
Perhaps we can try them against JPF or something.
Heck.. or even allow a user to use a file off their SD card to loopback mount /system partitions... Or /data partitions - like how the i9000 has a (built-in) 16gb SD card.
precurse said:
I already tried building ext4 and other modules off the i9000 sources... Didn't seem to work too well. Kept complaining about memmap or some random errors when I tried loading them.
Perhaps we can try them against JPF or something.
Click to expand...
Click to collapse
I think so. Maybe we should just try to build an ext4 module with standard linux sources with armv6 as target ? Since i9000 has an armv7 processor..
Gsam101 said:
I think so. Maybe we should just try to build an ext4 module with standard linux sources with armv6 as target ? Since i9000 has an armv7 processor..
Click to expand...
Click to collapse
I setup my .conf to use the same CPU as what the G3 uses. I can't compile a kernel, but the modules compile.
It's a much different error I got from these modules than when I tried loading i9000 modules.
precurse said:
Heck.. or even allow a user to use a file off their SD card to loopback mount /system partitions... Or /data partitions - like how the i9000 has a (built-in) 16gb SD card.
Click to expand...
Click to collapse
Don't forget the internal SD of the sgs is on fast movienand SD memory, if one would loop back to his sdcard he would have to have a class 10 sdcard at least to get decent speed out of it.
I've posted a new version of repack-zImage.sh and the associated utilities in the first article of this thread. This version lifts the restriction which until now allowed only compressed initramfs disks. Now uncompressed ones are also supported.
This modification got somewhat tricky, as a newly created initramfs, when compressed, yields sizes different from the original (even if it contains exactly the same files) due to different ordering of the files. For a 2 MB ramdisk, a difference of 3k may not sound like much, but it is - if it is too large by this number in a zImage where the initramfs must fit into the original's room.
Some black magic was needed. Now the files are ordered like in the original, with additional files (if created by the user) appended at the end. Options are provided to change the optimisations if needed.
I tried with JPF and with JPA-custom, so changes are really good that you won't have to bother with the above and can just go ahead and do your own initramfs modifications.
Yeah, that worked for me. Thanks a lot .
have we (you all) found a way to unpack the froyo zimage yet? it worked great on eclair. thank you. and thanks for any help that you might provide.
i have tried on froyo for the epic but as it is unpacking it keeps looping 2 sets of numbers when i run the script. 5748017 5749018 and keeps repeating. any help would be great.
/Data and /cache ext2 conversion script.
Gsam101 said:
Exactly, that could be very useful, since we could get ext2 (ext4 maybe if we compile it as a module ?) in /data natively
Click to expand...
Click to collapse
hey here's a script that converts /data and /cache to ext2... i tried it.. worked for me.. i did not made this.. !
this is the work of MOTAFOCA !
quadarant score went from 305 to 515 and the best part.. internal memory shrunk from 176Mb to 161 Mb only
the script says its for i5508 but was made for 5800 as said by barquers
anyways.. here's the script.. hoping it will help
http://multiupload.com/O2ET4B8K0A
PS: im using MOTAFOCA's ROM... and script was made by MOTAFOCA not me
spdwiz18 said:
i have tried on froyo for the epic but as it is unpacking it keeps looping 2 sets of numbers when i run the script. 5748017 5749018 and keeps repeating. any help would be great.
Click to expand...
Click to collapse
It should work for any zImage. Sounds like a bug in the end detection for a compressed part. Can you provide me with a link to the zImage or contact me directly (PM/E-Mail) to pass me a copy? Then I'll go into it.
hey. does the script allows us to tweak the kernel so that it can be overclocked? ??
or we still need to wait for the kernel sources?
coolzarjun said:
does the script allows us to tweak the kernel so that it can be overclocked?
Click to expand...
Click to collapse
You cannot do that without writing your own cpufreq driver (if at all). You need the kernel sources to do this.
mizch said:
It should work for any zImage. Sounds like a bug in the end detection for a compressed part. Can you provide me with a link to the zImage or contact me directly (PM/E-Mail) to pass me a copy? Then I'll go into it.
Click to expand...
Click to collapse
Soryy gmail was not syncing for somereason. I will send tou what I have when I get home from work thanks.
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.
Sooo yeah.... anybody got some help for this one? I have searched google and the forums but can't clearly figure this out, but how do I get a Boot.img for this phone??? I have rebuilt the kernel 3 or 4 different ways and the output never yeilds one, however I apparently NEED one so I can peel away the ramdisk x( any ideas?
EDIT: Okay, so now that I can compile a working stock kernel for the Sidekick, where should I start now? I know we already have a working voodoo lagfix kernel, but I want to make CWM for the stock kernel, that sounds like a good spot. And adding in init.d sounds like another good start. Making my own may help me in understanding it all. I AM taking notes too
Zydrate_blue said:
Sooo yeah.... anybody got some help for this one? I have searched google and the forums but can't clearly figure this out, but how do I get a Boot.img for this phone??? I have rebuilt the kernel 3 or 4 different ways and the output never yeilds one, however I apparently NEED one so I can peel away the ramdisk x( any ideas?
Click to expand...
Click to collapse
If I recall correctly, I used the split_bootimg.pl script, and accompanying instructions, found here:
http://www.android-dls.com/wiki/?title=HOWTO:_Unpack%2C_Edit%2C_and_Re-Pack_Boot_Images
Start by unpacking and repacking a kernel that you already know is functional -- i.e. a copy of a kernel you have already successfully flashed. Once that repack can be flashed successfully, you can move on to making modifications to it, or packing a whole new initramfs and kernel.
I had to remove references to a few of Samsung's proprietary modules to get the kernel to build -- Samsung helpfully supplies the places for those sources to be put (IN TREE -- shame on you Samsung), but not the sources themselves. One such module was rfs, IIRC. I removed the Makefile references so I could finish a compile, then used copies of the compiled modules from an existing initrd. Where you run into compile failures, where the source code appears to be simply missing, this is probably the cause.
I found that I had to manually strip at least the modules that resulted when I built from sources, otherwise the finished image was far too large. Compare the sizes of your compiled kernel and module files to those of a known-working reference image. They should not be too far out of line.
I wish I had saved more notes from my own kernel builds. Regular Linux kernels are so easy, but earlier Android kernels are unnecessarily horrible to build. Still, if you run into any more issues, I'll try to help...
Oh, and please disable the keystroke logger!
nxd said:
If I recall correctly, I used the split_bootimg.pl script, and accompanying instructions, found here:
http://www.android-dls.com/wiki/?title=HOWTO:_Unpack%2C_Edit%2C_and_Re-Pack_Boot_Images
Start by unpacking and repacking a kernel that you already know is functional -- i.e. a copy of a kernel you have already successfully flashed. Once that repack can be flashed successfully, you can move on to making modifications to it, or packing a whole new initramfs and kernel.
I had to remove references to a few of Samsung's proprietary modules to get the kernel to build -- Samsung helpfully supplies the places for those sources to be put (IN TREE -- shame on you Samsung), but not the sources themselves. One such module was rfs, IIRC. I removed the Makefile references so I could finish a compile, then used copies of the compiled modules from an existing initrd. Where you run into compile failures, where the source code appears to be simply missing, this is probably the cause.
I found that I had to manually strip at least the modules that resulted when I built from sources, otherwise the finished image was far too large. Compare the sizes of your compiled kernel and module files to those of a known-working reference image. They should not be too far out of line.
I wish I had saved more notes from my own kernel builds. Regular Linux kernels are so easy, but earlier Android kernels are unnecessarily horrible to build. Still, if you run into any more issues, I'll try to help...
Oh, and please disable the keystroke logger!
Click to expand...
Click to collapse
Wow thanks nxd! I don't know if you have seen my other posts, but I'm a newbie at this stuff. Never too late to learn though right?
Now, as for the issues in the build, when I first tried to compile I was getting errors of an undeclared SEGMENT_SIZE in binfmt_aout.c so I searched around and was informed that the aout method is outdated? So I removed it from the config as instructed, seeing as it wasn't needed.
I've gotten to a compile resulting in the zImage and about 8 modules created. Now, the zImage is incomplete at this point if I am correct? If it's flashed, it will simply bootloop. (Because there is more to be done? i.e the ramdisk gz that loads the rom at the bootloader?)
Also, I will check the link about the logger, so I can disable it.
I appreciate all your help I really want to get this stuff down-pat eventually.
Zydrate_blue said:
I've gotten to a compile resulting in the zImage and about 8 modules created. Now, the zImage is incomplete at this point if I am correct? If it's flashed, it will simply bootloop. (Because there is more to be done? i.e the ramdisk gz that loads the rom at the bootloader?)
Click to expand...
Click to collapse
Correct, you need to put the modules onto an initramfs, and then assemble the zImage and initramfs into a boot.img. The URL I posted has instructions to both unpack and repack. I suggest that you obtain repack settings (command line, perhaps memory addressing) from an existing working image.
You can probably use the initramfs from an existing image as the basis for your new boot.img as well, replacing the modules from the old imitramfs with your new modules.
nxd said:
Correct, you need to put the modules onto an initramfs, and then assemble the zImage and initramfs into a boot.img. The URL I posted has instructions to both unpack and repack. I suggest that you obtain repack settings (command line, perhaps memory addressing) from an existing working image.
You can probably use the initramfs from an existing image as the basis for your new boot.img as well, replacing the modules from the old imitramfs with your new modules.
Click to expand...
Click to collapse
I hate to ask this because I'm afraid of being a pain in the a**.... but I hope you won't mind working with me, I'm in for the long run. Anyway, am I supposed to have a initramfs after the compile somewhere within the source? Or is this something I acquire from an an outside source? I promise I have done like 30-40 searches before hand. I have a feeling am missing something obvious -_-
Again, thank you for your generous help
Zydrate_blue said:
I hate to ask this because I'm afraid of being a pain in the a**.... but I hope you won't mind working with me, I'm in for the long run. Anyway, am I supposed to have a initramfs after the compile somewhere within the source? Or is this something I acquire from an an outside source? I promise I have done like 30-40 searches before hand. I have a feeling am missing something obvious -_-
Again, thank you for your generous help
Click to expand...
Click to collapse
The kernel compile will NOT produce an initramfs for you. It will produce the zImage (compressed kernel image) and modules.
The initramfs is an archive containing some files. During boot, when the kernel reaches the end of device initialization, it then creates an empty memory-backed filesystem, and extracts the initramfs contents into that new filesystem.
Ideally the initramfs would be generated by the Android build system, using the binaries produced by the kernel compile. But Samsung provides the bare minimum for GPL compliance, and so we don't get all the pieces we'd need for that. Presumably assembling those pieces is a big part of what windxixi has done, however.
When I worked up my boot.img, I used someone else's existing initramfs, dropped in my compiled modules and a few other minor changes, and then re-assembled it with my compiled zImage. If you're already working with windxixi's build kit and kernel sources, it might save you some time to use his initramfs as a basis for your own.
Really, once you've unpacked basically any SK4G boot.img, and extracted the files from the initramfs, I think you'll see the layout and that aspect the process will be clearer to you.
nxd said:
The kernel compile will NOT produce an initramfs for you. It will produce the zImage (compressed kernel image) and modules.
The initramfs is an archive containing some files. During boot, when the kernel reaches the end of device initialization, it then creates an empty memory-backed filesystem, and extracts the initramfs contents into that new filesystem.
Ideally the initramfs would be generated by the Android build system, using the binaries produced by the kernel compile. But Samsung provides the bare minimum for GPL compliance, and so we don't get all the pieces we'd need for that. Presumably assembling those pieces is a big part of what windxixi has done, however.
When I worked up my boot.img, I used someone else's existing initramfs, dropped in my compiled modules and a few other minor changes, and then re-assembled it with my compiled zImage. If you're already working with windxixi's build kit and kernel sources, it might save you some time to use his initramfs as a basis for your own.
Really, once you've unpacked basically any SK4G boot.img, and extracted the files from the initramfs, I think you'll see the layout and that aspect the process will be clearer to you.
Click to expand...
Click to collapse
I haven't found any boot.img from another kernel, however I have finally figured out how to unpack the zImage D I think I'm a bit closer now, however, now I need to figure out how to un-cpio the initramfs.cpio and/or use the intramfs folder I now have. (in the unpacked zImage)
Then the next step I suppose would be learning how to incorporate the modules that I have. hmm..
Zydrate_blue said:
I haven't found any boot.img from another kernel, however I have finally figured out how to unpack the zImage D I think I'm a bit closer now, however, now I need to figure out how to un-cpio the initramfs.cpio and/or use the intramfs folder I now have. (in the unpacked zImage)
Then the next step I suppose would be learning how to incorporate the modules that I have. hmm..
Click to expand...
Click to collapse
On the page I linked to in my first reply, under "Alternative Method", those instructions worked for me to split, unpack, repack, and assemble. Did they not work for you?
Regarding how to incorporate the modules, you would copy them into the extracted directory in the same locations in the initramfs as the existing module files. Generally something like /lib/modules. Look for files ending in '.ko'. They may be spread out a bit in your compiled kernel sources, but they should all be in one directory in your extracted initramfs directory.
As for an existing boot.img, it's a Froyo kernel, but there's this: http://forum.xda-developers.com/showthread.php?t=1663622.
nxd said:
On the page I linked to in my first reply, under "Alternative Method", those instructions worked for me to split, unpack, repack, and assemble. Did they not work for you?
Click to expand...
Click to collapse
I tried this method of repacking, but so far I have not been able to re-pack my zImage successfully. (I feel pretty close to getting this) Maybe I am putting the modules in the wrong place? Or perhaps I am skipping a step. I believe I need to assign more room for the modules. I am getting the error that initramfs_cpio is too large.
My initramfs has 2 directories in it- and I created a folder within called lib and placed the modules in there... that may be the wrong way, but I don't think it changes the need for more room in the kernel. Something to do with padding values maybe? /:
Also, the script I am using for this is from JunYoung- it is repack-zImage.sh a tool for de-compiling and recompiling a zImage. That's how I got to my initramfs directory in the new zImage I built with the source.
Zydrate_blue said:
I tried this method of repacking, but so far I have not been able to re-pack my zImage successfully. (I feel pretty close to getting this) Maybe I am putting the modules in the wrong place? Or perhaps I am skipping a step. I believe I need to assign more room for the modules. I am getting the error that initramfs_cpio is too large.
My initramfs has 2 directories in it- and I created a folder within called lib and placed the modules in there... that may be the wrong way, but I don't think it changes the need for more room in the kernel. Something to do with padding values maybe? /:
Click to expand...
Click to collapse
I think your extracted initramfs should have more than two directories.
Would you paste a listing of the files and directories here? Do this:
Code:
cd [path_to_extracted_initramfs] && find *
nxd said:
I think your extracted initramfs should have more than two directories.
Would you paste a listing of the files and directories here? Do this:
Code:
cd [path_to_extracted_initramfs] && find *
Click to expand...
Click to collapse
This is what I have after I unpack the zImage:
cpio-t
decompression_code
initramfs
initramfs/root
initramfs/dev
initramfs.cpio
kernel.img
padding3
padding_piggy
part3
piggy
piggy.gz
piggy.gz+piggy_trailer
piggy_trailer
ramfs+part3
sizes
EDIT: I also tested unpacking another zImage that is working, in fact I tried it on the Bali SK4G that we use currently (I hope that was okay with you /: I probably should have asked) but it just keeps displaying code as if it won't finish unpacking. It makes sense because there is a lot more to unpack, I think it is because it is compressed.
Zydrate_blue said:
This is what I have after I unpack the zImage:
cpio-t
decompression_code
initramfs
initramfs/root
initramfs/dev
initramfs.cpio
kernel.img
padding3
padding_piggy
part3
piggy
piggy.gz
piggy.gz+piggy_trailer
piggy_trailer
ramfs+part3
sizes
EDIT: I also tested unpacking another zImage that is working, in fact I tried it on the Bali SK4G that we use currently (I hope that was okay with you /: I probably should have asked) but it just keeps displaying code as if it won't finish unpacking. It makes sense because there is a lot more to unpack, I think it is because it is compressed.
Click to expand...
Click to collapse
You don't need my permission to use my Bali-based Linux kernel image or patches.
Where can I get a copy of this other boot.img you're working with? It seems clear the hacks and workarounds I used with the Bali-era kernel don't translate directly across. I'd like to take a look and see what I can make of it.
nxd said:
You don't need my permission to use my Bali-based Linux kernel image or patches.
Where can I get a copy of this other boot.img you're working with? It seems clear the hacks and workarounds I used with the Bali-era kernel don't translate directly across. I'd like to take a look and see what I can make of it.
Click to expand...
Click to collapse
Well, I never really found a literal "boot.img" from what I read I have to compile a zImage and in the sidekick's style system boots this as a boot.img??? And I have only used the one from kernel source so far, seeing as I could not get the Bali zImage to split.
As for the initramfs.cpio that us within the zImage, I tried to un-cpio it and I get an error about removing '/ from name?
I could send you the zImage I got from source o.e
EDIT: I never found a copy of boot.img, I couldn't even get one from an outer-source.
Sent from my SGH-T959V using xda app-developers app
Zydrate_blue said:
As for the initramfs.cpio that us within the zImage, I tried to un-cpio it and I get an error about removing '/ from name?
Click to expand...
Click to collapse
That's more of an advisory than an error. It's just telling you that it's stripping off the leading /, i.e. extracting to a relative path.
It sounds like you probably succeeded in extracting the initramfs.
nxd said:
That's more of an advisory than an error. It's just telling you that it's stripping off the leading /, i.e. extracting to a relative path.
It sounds like you probably succeeded in extracting the initramfs.
Click to expand...
Click to collapse
Well, then that sounds better! But what about this one:
cpio: dev/console: Cannot mknod: Operation not permitted
1 block
I forgot there was a following error
Zydrate_blue said:
Well, then that sounds better! But what about this one:
cpio: dev/console: Cannot mknod: Operation not permitted
1 block
I forgot there was a following error
Click to expand...
Click to collapse
You'll probably want to extract the files as root. Otherwise device nodes won't be created, like above, and permissions won't be kept on any of the files.
Be careful to be in a safe (i.e. empty) working directory when you do that. It will extract the files into your current working directory.
nxd said:
You'll probably want to extract the files as root. Otherwise device nodes won't be created, like above, and permissions won't be kept on any of the files.
Be careful to be in a safe (i.e. empty) working directory when you do that. It will extract the files into your current working directory.
Click to expand...
Click to collapse
Okay so now after I execute as root, it gives me this message:
cpio: /dev/console not created: newer or same age version exists
So the directories are empty after extracted?
Zydrate_blue said:
Okay so now after I execute as root, it gives me this message:
cpio: /dev/console not created: newer or same age version exists
So the directories are empty after extracted?
Click to expand...
Click to collapse
There's another argument you needed: --no-absolute-filenames
Unfortuantely it looks like cpio will have kept the absolute path and overwritten files on your real machine.
Extract into a directory using --no-absolute-filenames and see what files on your host system were overwritten. Those files should be recovered somehow before proceeding.
Sorry I didn't catch that.
nxd said:
There's another argument you needed: --no-absolute-filenames
Unfortuantely it looks like cpio will have kept the absolute path and overwritten files on your real machine.
Extract into a directory using --no-absolute-filenames and see what files on your host system were overwritten. Those files should be recovered somehow before proceeding.
Sorry I didn't catch that.
Click to expand...
Click to collapse
Oh god -_- wow I messed up then. well....the only file that was within the cpio was a file named console.... so I think I need to fix that?
I'm not mad or anything, it's a risk you take ya know? But I may need help.
EDIT: Okay so I reboot my laptop and it reboot fine, no issues. I don't think it actually overwrote any file (luckily because that cpio file didn't have anything in it...heh) So should I now try the command with the new argument?
Zydrate_blue said:
Oh god -_- wow I messed up then. well....the only file that was within the cpio was a file named console.... so I think I need to fix that?
I'm not mad or anything, it's a risk you take ya know? But I may need help.
EDIT: Okay so I reboot my laptop and it reboot fine, no issues. I don't think it actually overwrote any file (luckily because that cpio file didn't have anything in it...heh) So should I now try the command with the new argument?
Click to expand...
Click to collapse
I'll take a look at the boot image this evening. It would seem very odd to me if the only file on the initramfs was /dev/console.
ROM Explorer
From time to time I need to extract some files from various Android ROMs. So far I downloaded the ROM file and then started to search for further tools to extract files from the downloaded ROM. If all went well I ended up with an image I could open with ext4_unpacker to finally extract the files I needed. This whole procedure took a lot of time, involved tools from unknown sources and often simply didn't work. So I decided to create my own tool.
ROM Explorer can directly open the following files:
zip archives with img or new.dat entries
Samsung md5 archives
Sony ftf archives
Huawei update.app archives
img/ext4 image files
lz4 image files (used by Samsung)
sin fies (used by Sony)
In case you have a file which is not supported let me know. Maybe I find the time to add support. Or simply add it yourself - ROM Explorer is Open Source.
Usage
Download the installer and run it or build your own version with Visual Studio 2017.
Start the executable. You will see a window similar to ext4_unpacker. In the first line you select a file, in the second line you can choose an archive entry if the file is an archive file.
Loading a file or archive entry can take a significant amount of time and disk storage. ROM Explorer may need to create temporary files with several gigabytes. A fast flash disk helps a lot!
You can extract files or folders by dragging and dropping them to Windows Explorer.
Downloads
ROM Explorer 0.9
ROM Explorer 0.9.1
Thanks To
ROM Explorer would not exist without the distributed knowledge of this forum. Especially I want to thank worstenbrood, Androxyde, IgorEisberg for their work.
So I'm waiting for your comments - but be patient it may take some time for me to react
Reserved for whatever purpose...
Wew
Let me try and report you back
Thank you I will try this out. Thanks too for making it open source
Not Running on Windows 7 x64
samidos said:
Not Running on Windows 7 x64
Click to expand...
Click to collapse
0.9.1 should fix this. Be sure to first uninstall before installing 0.9.1.
After hours of google search and downloading countless apps that dont work I found this. This app is legit and works on windows 10 64bit. Thank you for your work.
Your app is GREAT! Thanks for sharing it.
Edit: Answered my own question. Windows 10 tip "Run As Administrator" and dont drag files "to the desktop" but instead to an Explorer window.
Can this program find the differences between compiled ROMs?
I ask this question because Xiaomi on the Mi 9 released an initial kernel with sourcecode that was changed over time without updating the GitHub https://github.com/MiCode/Xiaomi_Kernel_OpenSource/tree/cepheus-p-oss and because of this change, the ROMs have something different between how they connect to the cameras. The old ROM versions (4/1/2019 and before) connect fine to the cameras, but post that date, a custom kernel built from the GitHub source will fail to connect to the cameras. Since the change has not been made open source on GitHub, there has to be another way to find and patch new kernel builds in order for them to work. Would your software be able to extract these changes? If not, do you have any other ideas which may? Much appreciated.