I have currently been testing the method of rooting leaked 2.1 phones. There was a little discussion running in that thread (and other threads, I've found) that poses the question whether or not the RUU is the same as 2.1 Leak v3.
The RUU I'm using is referenced here: http://forum.xda-developers.com/showthread.php?t=695667 -- which can be found here: http://shipped-roms.com/shipped/Des...WWE_2.36.605.1_release_signed_with_driver.exe
Leak 2.1 v3 I'm using is referenced here: http://androidforums.com/htc-droid-eris/69688-htc-droid-eris-os-2-1v3-download.html -- which can be found here: http://www.mediafire.com/?qymwuzug5gl
So, the process that I've been using to root these phones involves flashing the RUU OTA onto the phone. With some help from user bftb0, I have taken the time to do the analysis.
How did I get system.img and boot.img off of the RUU OTA, you might ask? Well, after I flashed the RUU OTA onto the phone, I went through the Incredible/Slide root method to root the phone I'm working with (without changing any phone settings within Sense). After getting adb to recognize the device in recovery, I took the steps necessary to flash Amon_RA's recovery. I then took a Nandroid backup of my phone, and extracted the system.img and boot.img files off of the SD card where the Nandroid backup was stored.
Then, I used unyaffs to unpack system.img into 2 separate directories, and used split_bootimg.pl to unpack boot.img
so, for split_bootimg.pl I did this, starting at the directory where each respective boot.img file is
Code:
$ mkdir unpak
$ cd unpak
$ split_bootimg.pl ../boot.img
... [output] ...
$ mkdir ramdisk
$ cd ramdisk
$ gunzip -c ../boot.img-ramdisk.gz | cpio -i
The test after it's unpacked
Code:
#!/bin/bash
mydir=`pwd`
for tree in leakv3 RUU ; do
cd $tree
touch ./md5sigs
find . -type f -print | while read fnam ; do md5sum $fnam >> ./md5sigs ; done
cd $mydir
done
cat leakv3/md5sigs RUU/md5sigs | sort | uniq -u
Code:
$ ./md5test.sh
6951ac78e8f9ae5e6c4c4cb50803fed9 ./bin/su
9512ebf90efee5ea996ec59456cf4b03 ./md5sigs
c6212fa45ab99c3a5d731bca06184023 ./md5sigs
This output should be expected; we should expect the su executable to be in one and not the other if I've rooted it, and the md5sigs that the script creates are not going to have the same md5sums
Pastebins for both the leak v3 list of md5sums, and RUU list of md5sums
Leak v3 md5sigs pastebin: http://pastebin.com/PGZDbC1r
RUU OTA md5sigs pastebin: http://pastebin.com/qz5z0Vdr
Conclusion: They are identical
Related
Maybe a noob question, but how do you guys split and repack SGS3 boot.img ?
The usual perl scripts don't seem to work with any S3 boot.img I came across (neither for the Galaxy Tab 7.7 boot.img's btw).
I keep getting this error :
Android Magic not found in boot.img. Giving Up.
Click to expand...
Click to collapse
Thanks for answering.
To unpack, you can do this:
Code:
abootimg -x boot.img && mkdir newramdisk && cd newramdisk && zcat ../initrd.img | cpio -i --no-absolute-filenames
Of course, that assumes you have abootimg installed. The above will split the zImage and the ramdisk from the boot.img and then proceed to extract the files from the ramdisk. Some ramdisks are not Gzip compressed so in that case use cat instead of zcat. Also: run that as root to make sure you don't mangle the files' permissions. I haven't tried repacking, though. ("find . -print | cpio -o -H newc | gzip > ../initrd.img" followed by "cd .. ; abootimg -u boot.img -r initrd.img" worked for my U8800pro, but I've had no need to try it with GS3 images.) I'd start by looking at the tools that come with the official Samsung source distribution and guides that tell you how to build a Samsung kernel.
Thanks a lot for this thorough answer
Trying this right now.
Couldn't find a specific Samsung kernel-related tutorial, though good idea to go take a look at Samsung's official kernel documentation.
qwerty12 said:
To unpack, you can do this:
Code:
abootimg -x boot.img && mkdir newramdisk && cd newramdisk && zcat ../initrd.img | cpio -i --no-absolute-filenames
Of course, that assumes you have abootimg installed. The above will split the zImage and the ramdisk from the boot.img and then proceed to extract the files from the ramdisk. Some ramdisks are not Gzip compressed so in that case use cat instead of zcat. Also: run that as root to make sure you don't mangle the files' permissions. I haven't tried repacking, though. ("find . -print | cpio -o -H newc | gzip > ../initrd.img" followed by "cd .. ; abootimg -u boot.img -r initrd.img" worked for my U8800pro, but I've had no need to try it with GS3 images.) I'd start by looking at the tools that come with the official Samsung source distribution and guides that tell you how to build a Samsung kernel.
Click to expand...
Click to collapse
Great!! Thanks for your information.
Here is what I use. Inside there are three binaries and two perl scripts,, copy the binaries into /usr/bin/ or you can add them in their own place and add that to the path. Then use this to help you use the files
Thanks for that too, ima try those scripts
Getting this error :
~$ perl unpack-bootimg.pl boot.img
could not find any embeded ramdisk images. Are you sure this is a full boot image?
Click to expand...
Click to collapse
Apparently, from what I have been reading, Samsung uses a different type of kernels than other manufacturers.
Although there's a huge number of custom samsung kernels out there. There might be a way^^
Here is the kernel i'm trying to edit if anyone wanna give a try at unpacking it for me.
That is true up until the S3 boot.img/kernel They have always used a zImage. Now Google has forced them to move over to EXT4 system and change the kernel format.
That file is only 2.88 mb's that is way too small to be a full kernel. Even for stock with no tweaks. That's why you are having an error.
This is the original boot.img from the CM9 for Galaxy Tab 7.7 update.zip
However i get the same error when trying to unpack S3 stock boot.img or even CM10 boot.img, although when i try the same scripts on my Xperia Play's kernels they unpack properly.
Good thing if Google made Samsung do kernels like others
Hi,
Did you manage to unpack/repack the SGS3 boot image? I'm trying to modify init.rc in an international SGS3 (i9300).
I've managed to unpack the boot image (from /dev/block/mmcblk0p5) as per qwerty12's command but how do I repack it?
Thanks!
i like my android for home use ,but as a IT maneger it will be nice to have linux on my prime as well. thar is any toturial that expline how to make my prime duel boot this 2 OS?
Overview
Follow this thread: Ubuntu | How-to install it on the Prime . NOTICE: developer-thread
Mainly there are 2 methods:
Flash-boot:
The thread starts with LilStevies work from Androidroot. There you have to flash the correspondent boot-kernel to start either android or linux. So far I don't know of an existing LilStevie rom with the kexec/kexecboot method (kexec: Linux as bootloader).
SDCard-existence-driven-init
Running linux with root_chooser_v1/2/3 form tux_mind which starts around thead-page 35 uses a modified init. Dualboot: with SDCard in slot -> linux | without SDCard in slot -> Android
See: Gentoo Wiki and hack-job if you are on Asus stock rom.
You can also use chroot method - but it's not dualboot.
I had method 1 running. But for me it is not working for daily useage. (reflashing s*c*s :angel
Now i will use the SDCard-existence-driven-init
I can't use the posted boot-blob because I'm not on the Asus stock kernel so Android starts but many processes crash so that it is not useable. I use the Energy-Rom with the Clemsyn-kernel. (Prime is unlocked, nvflash-activated and rooted)
Be warned: You could damage/ brick your device following the instructions. Backup all!! A whole nvflash backup is reccomended. Be carful. Use your brain. I'm not responsible for any damages.
Up to now I tested my own 'unchanged' fastboot boot-blob:
Enter APX-Mode: put in USB cable + hold [Vol up]+[Power] (until vibrating, screen stays black)
Code:
$ sudo wheelie -r --blob blob.bin
$ sudo nvflash -r --read 6 blobNv.LNX
$ sudo nvflash -r --go
Unpack blob:
Code:
$ abootimg -x blobNv.LNX
repack blob (be sure you have blobpack for TF201 i.e. from CM10 repo):
Code:
$ abootimg --create testNv.LNX -k zImage -r initrd.gz -f bootimg.cfg
$ blobpackTF201 testFb.blob LNX testNv.LNX
start into fastboot-mode: put in USB cable [Vol down]+[Power] (until you can choose fastboot/USB symbol)
Code:
$ fastboot -i 0x0b05 flash boot testFb.blob
$ fastboot -i 0x0b05 reboot
The blob flashes well - I can see the blue progerss-bar. By the way: this produces a backup blob of the bootpartition which you can reflash via fastboot to start android if sth went wrong.
Now I need to insert the root_chooser init into the ramdisk to get linux from SDCard started...
I got a half working root_chooser. It starts android but not linux.
Here is what I did to modify the boot-loader with Clemsyn kernel and the modified init from tux_mind:
At first I read the LNX patition from the TF201 (unlocked, nvflash-able/wheelie, rooted):
Boot into APX-mode:
Code:
$ sudo bin/wheelie -r --blob bin/blob.bin
$ sudo bin/nvflash -r --read 6 blobNv.LNX
$ sudo bin/nvflash -r --go
Unpack the blob:
Code:
$ abootimg -x blobNv.LNX
You will get bootimg.cfg, initrd.img and zImage.
Now unpack the initial ramdisk:
Code:
$ mkdir ramdisk
$ cd ramdisk
$ gzip -dc ../initrd.img | cpio -i
Clone tux_minds data and copy your extracted custom rom ramdisk to newroot:
Code:
$ cd ..
$ git clone https://github.com/tux-mind/tf201-dev.git
$ rm -r tf201-dev/initramfs/newroot/*
$ cp -r ramdisk/* tf201-dev/initramfs/newroot/
[I][SIZE="2"]#edit 22 feb 2013[/SIZE][/I]
$ cd tf201-dev/initramfs
$ mkdir data && mkdir dev && mkdir sys
$ cd ../../..
[I][SIZE="2"]#edit end[/SIZE][/I]
OPTIONAL start compile root_chooser/init via crosscompile
Change the compiler in Makefile. I use Ubuntu with arm-linux-gnueabi-gcc (maybe it would be better to use arm-linux-gnueabihf-gcc) from the repo for crosscompiling:
Edit Makefile in tf201-dev/root_chooser:
Code:
#--Head-------------------- snip
CC=arm-linux-gnueabi-gcc
LD=arm-linux-gnueabi-ld
#CC=arm-unknown-linux-gnueabi-gcc
#LD=arm-unknown-linux-gnueabi-ld
#-------------------------- snap
Now compile and copy it to the initramfs:
Code:
$ make v2
$ cp root_chooser ../initramfs/init
OPTIONAL end
Now pack the initrd, make a blob and flash it to the TP
Code:
$ cd tf201-dev/initramfs
$ find . | cpio --create --format='newc' > ../../myinitrd
$ cd ../..
$ gzip myinitrd
$ chmod 777 myinitrd.gz
$ abootimg --create testNv.LNX -k zImage -r myinitrd.gz
$ bin/blobpackTF201 testFb.blob LNX testNv.LNX
Start into fastbootmode:
Code:
$ fastboot -i 0x0b05 flash boot testFb.blob
$ fastboot -i 0x0b05 reboot
Start into andorid open Terminal Emulator and type:
Code:
$ su
# vi /data/.boot
/dev/mmcblk1p1:/:/sbin/init
[esc] :wq
I followed this guide to set up my sdCard. That's it. Insert sdCard, reboot.
Android starts but not Linux from the sdCard. I got the following message back in android:
Code:
[I][B]FIXED[/B][SIZE="2"] see edit 22 feb 2013[/SIZE][/I]
[COLOR="Silver"]$ cat /boot_chooser.log
unable to mount /sys - No such file or directory[/COLOR]
New error message (inserted sdCard occurs boot-loops, remove sdCard to start android):
Code:
$ cat /boot_chooser.log
unable to mount /dev/mmcblk1p1 on /newroot - No such file or directory
I'm feeling so close to fire up Linux on my Transformer. Who can give me hint?
gophix said:
New error message (inserted sdCard occurs boot-loops, remove sdCard to start android):
Code:
$ cat /boot_chooser.log
unable to mount /dev/mmcblk1p1 on /newroot - No such file or directory
Click to expand...
Click to collapse
got it yeah! linux and android starting up! BUT VERY INSTABILE !!!
I had to use another sdCard and recompiled the kernel with some flags activated:
My hama 16GB class 10 doesn't seem to work well with the TP. I copied some data to the sdcard in android, there the I/O stream had several stops while copying data. Some forum members reported I/O errors in the system log (dmesg). I didn't have that errors but a variing throughput while copyint to sdCard.
The kernel I prepared this way:
Code:
downloading Clemsyn-kernel source:
$ wget https://www.dropbox.com/s/pjqd2b1edn6fiwu/tfcombofinal.zip
$ unzip tfcombofinal.zip
Get the actual kernel .config form the TP via adb and compile the kernel (I didn't patch, because I got error while compiling the kernel). I diffed my config to tux_minds and aktivated some flags.
Code:
$ adb pull /proc/config.gz
$ gzip -d config.gz
$ cp config tfcombofinal/.config
$ cd tfcombofinal
// patching should be like this:
// $ wget https://github.com/tux-mind/tf201-dev/raw/master/v2/kernel/JB15.patch
// $ patch -p1 < ../JB15.patch(v1/v2?) !!! do not patch !!!
$ make menuconfig
$ make -j4 ARCH=arm CROSS_COMPILE=arm-linux-gnueabi-
I didn't compile the modules.
After that I packed my kernel from tfcombo/arch/arm/boot/zImage into the blob ($ abootimg --create testNv.LNX -k zImage -r myinitrd.gz)
VERY INSTABILE !!! means: the linux starting kernel was compiled with hardfloat (arm-linux-gnueabihf-).Linux starts up and responds "a littel bit"; android starts up; work 5 mins and reboots.
So both are working the developer way
I will test an own armSF kernel next time (the way described in this post, up to now I run instable on armHF) and report if this makes android stable and additionally starts up linux.
The dual-boot works fine.
Look at lifeinarootshell.
The actual version root_chooser v6 starts linux (from SDcard, microSDcard, USB, loop-device, internal folder) and android with different kernels
It has a cofigurable bootloader via kexec.
Linux distributions (gentoo, ubuntu, arch linux, ...) are also available and are growing more and more in stability and performance.
gophix said:
The dual-boot works fine.
Look at lifeinarootshell.
The actual version root_chooser v6 starts linux (from SDcard, microSDcard, USB, loop-device, internal folder) and android with different kernels
It has a cofigurable bootloader via kexec.
Linux distributions (gentoo, ubuntu, arch linux, ...) are also available and are growing more and more in stability and performance.
Click to expand...
Click to collapse
Getting xorg to work on archlinux is somewhat messy at the moment. The tegra3 driver is built for an old xorg-server, and is not compatible with the new one in the archlinux repositories. I was able to make it work by recompiling xorg-server, though. I guess it would be easier if someone made an aur package with the old xorg-server.
Thank you very much gophix for your nice guide in the second post :fingers-crossed:
However, since the first attempts to get linux based distributions working on the TF201 like ubuntu or arch linux, there was not much progress anymore I feel this is somehow pitty due to the fact that the Prime is still a good and reasonable tablet. And it could be much more if there would be not these horrible restrictions set by Asus like encrypted bootloader.
But I don't want to criticise mainly in my post. Instead, I would like to promote a constructive discussion so that the TF201 receives new life
How about creating a new ubuntu image based on 14.04 since it receives long term support? Unfortunately, my knowledge is still rather limitted so far to do this by myself.
And what is your opinion, to go alternatively another way by using the xubuntu installation (13.04) developed for the TF300tg as shown here:
http://forum.xda-developers.com/showthread.php?t=2190847
As far as I know, both devices are quite similar. Or are there any good arguments to deny this idea?
I'm tired of asking the same question again and again but for the thousandth and the last time I'll try my best to explain y'all the jeopardy I'm in.
I'm trying to build cm-10.2 from source for Sony Xperia E (nanhu) and everything started off just fine until I had to generate the skeleton files. I decided to use the mkvendor.sh to generate em. I have no clue why, but Sony seems to be in love with .elf files. And the best part, mkvendor only works with a standard boot.img file. Since I found mkvendor.sh the only convincing option, I decided to not use the other 2 options given here.
I extracted the kernel.sin from the ftf package of the kernel I downloaded, used flashtool to in turn extract kernel.sin which produced kernel.elf. I tried two things:
1) Unpack kernel.elf (flashtool elf extractor) and then pack em into a boot.img file (Failed as I couldn't pack em because I didn;t know how to use mkbootimg)
2) Rename kernel.elf to boot.img. as suggested by a developer of CM11 for Xperia E (Worked and was also accepted by mkvendor.sh)
I used mkvendor and it said that i don't have unpackbootimg binaries. I tried to make them by using:
make -j4 out/host/linux-x86/bin/unpackbootimg
Sadly I didn't know how to proceed so I got the binary from here and copied it to /usr/bin/ and made executable using:
sudo chmod a+x /usr/bin/unpackbootimg
Rebooted and it worked but you will see below that it isn't fixed 100% but it just works. I moved on and decided to use the script again on the renamed kernel.elf file(i.e. boot.img)
This is the following error I encounter while using mkvendor:
[email protected]:~/tools/FlashTool$ cd ~/source/cm/branch/cm-10.2
[email protected]:~/source/cm/branch/cm-10.2$ ./build/tools/device/mkvendor.sh sony nanhu ~/Desktop/boot.img
Arguments: sony nanhu /home/carbogen-chemist/Desktop/boot.img
Output will be in /home/carbogen-chemist/source/cm/branch/cm-10.2/device/sony/nanhu
*** Error in `unpackbootimg': free(): invalid next size (fast): 0x09793170 ***
./build/tools/device/mkvendor.sh: line 84: 3943 Aborted (core dumped) unpackbootimg -i $BOOTIMAGEFILE > /dev/null
gzip: ../boot.img-ramdisk.gz: No such file or directory
cpio: premature end of archive
cp: cannot stat ‘/tmp/carbogen-chemist/bootimg/boot.img-zImage’: No such file or directory
Creating initial git repository.
~/source/cm/branch/cm-10.2/device/sony/nanhu ~/source/cm/branch/cm-10.2
Initialized empty Git repository in /home/carbogen-chemist/source/cm/branch/cm-10.2/device/sony/nanhu/.git/
[master (root-commit) d49b660] mkvendor.sh: Initial commit of nanhu
7 files changed, 95 insertions(+)
create mode 100644 AndroidBoard.mk
create mode 100644 AndroidProducts.mk
create mode 100644 BoardConfig.mk
create mode 100644 cm.mk
create mode 100644 device_nanhu.mk
create mode 100644 recovery.fstab
create mode 100644 system.prop
~/source/cm/branch/cm-10.2
Done!
Use the following command to set up your build environment:
lunch cm_nanhu-eng
And use the follwowing command to build a recovery:
. build/tools/device/makerecoveries.sh cm_nanhu-eng
Since the script seems to look up for boot.img-ramdisk.gz and boot.img-zImage, I decided to investigate a bit further. I renamed boot.img to kernel.elf and used flashtool elf extractor to unzip kernel.elf. I obtained four files as a result of the extraction:
1) kernel.elf.bootcmd
2) kernel.elf.cert
3) kernel.elf.Image
4) kernel.elf.ramdisk.gz
Since mkvendor needed boot.img-ramdisk.gz and boot.img-zImage, I renamed all the files:
1) kernel.elf.bootcmd >> kernel.img-bootcmd
2) kernel.elf.cert >> kernel.img-cert
3) kernel.elf.Image >> kernel.img-zImage
4) kernel.elf.ramdisk.gz >> kernel.img-ramdisk.gz
Now I repackaged them using mkelf.py script. Since I couldn't find any command specific to nanhu, I edited it to fit for the device:
python mkelf.py -o edited.elf [email protected] [email protected],ramdisk [email protected],cmdline
This command throws no error and produces edited.elf. All of the files are packed in except kernel.img-cert as I didn't know the arguments for it ([email protected]?x????????,cert). I rename the edited.elf to boot2.img.
But I get the same error as the one I get when I use the unedited kernel (boot.img)
What should I do to get out of this format abyss? Would I have better luck with mkbootimg? If so, could you point me out to a thread or tell me here itself how to use it?
Thank you all!
TheUltimateNoobist said:
I used mkvendor and it said that i don't have unpackbootimg binaries. I tried to make them by using:
make -j4 out/host/linux-x86/bin/unpackbootimg
Sadly I didn't know how to proceed so I got the binary from here and copied it to /usr/bin/ and made executable using:
sudo chmod a+x /usr/bin/unpackbootimg
Rebooted and it worked but you will see below that it isn't fixed 100% but it just works. I moved on and decided to use the script again on the renamed kernel.elf file(i.e. boot.img)
Click to expand...
Click to collapse
Fixed it myself. How did I miss that note at cyanogenmod porting?
Cd'ed to my working directory. Ran :
sudo make -j4 otatools
and grabbed unpackbootimg from WORKING_DIR/out/host/linux-x86/bin/unpackbootimg and pasted to /usr/bin
Made it executable by running:
sudo chmod a+x /usr/bin/unpackbootimg
Reboot!
It would also be very helpful if anyone could point out what the correct config for Xperia E is. (For EG >> blue_mint_defconfig is for Xperia T, semc_zeus_defconfig is for Xperia Play)
There is a file called README_Xperia, which contains the configuration names for the different phones in the kernel source can be used for. But my source doesn't contain it. So I would be very grateful if someone pointed it out!
Thank you!
TheUltimateNoobist said:
I'm tired of asking the same question again and again but for the thousandth and the last time I'll try my best to explain y'all the jeopardy I'm in.
I'm trying to build cm-10.2 from source for Sony Xperia E (nanhu) and everything started off just fine until I had to generate the skeleton files. I decided to use the mkvendor.sh to generate em. I have no clue why, but Sony seems to be in love with .elf files. And the best part, mkvendor only works with a standard boot.img file. Since I found mkvendor.sh the only convincing option, I decided to not use the other 2 options given here.
I extracted the kernel.sin from the ftf package of the kernel I downloaded, used flashtool to in turn extract kernel.sin which produced kernel.elf. I tried two things:
1) Unpack kernel.elf (flashtool elf extractor) and then pack em into a boot.img file (Failed as I couldn't pack em because I didn;t know how to use mkbootimg)
2) Rename kernel.elf to boot.img. as suggested by a developer of CM11 for Xperia E (Worked and was also accepted by mkvendor.sh)
I used mkvendor and it said that i don't have unpackbootimg binaries. I tried to make them by using:
make -j4 out/host/linux-x86/bin/unpackbootimg
Sadly I didn't know how to proceed so I got the binary from here and copied it to /usr/bin/ and made executable using:
sudo chmod a+x /usr/bin/unpackbootimg
Rebooted and it worked but you will see below that it isn't fixed 100% but it just works. I moved on and decided to use the script again on the renamed kernel.elf file(i.e. boot.img)
This is the following error I encounter while using mkvendor:
[email protected]:~/tools/FlashTool$ cd ~/source/cm/branch/cm-10.2
[email protected]:~/source/cm/branch/cm-10.2$ ./build/tools/device/mkvendor.sh sony nanhu ~/Desktop/boot.img
Arguments: sony nanhu /home/carbogen-chemist/Desktop/boot.img
Output will be in /home/carbogen-chemist/source/cm/branch/cm-10.2/device/sony/nanhu
*** Error in `unpackbootimg': free(): invalid next size (fast): 0x09793170 ***
./build/tools/device/mkvendor.sh: line 84: 3943 Aborted (core dumped) unpackbootimg -i $BOOTIMAGEFILE > /dev/null
gzip: ../boot.img-ramdisk.gz: No such file or directory
cpio: premature end of archive
cp: cannot stat ‘/tmp/carbogen-chemist/bootimg/boot.img-zImage’: No such file or directory
Creating initial git repository.
~/source/cm/branch/cm-10.2/device/sony/nanhu ~/source/cm/branch/cm-10.2
Initialized empty Git repository in /home/carbogen-chemist/source/cm/branch/cm-10.2/device/sony/nanhu/.git/
[master (root-commit) d49b660] mkvendor.sh: Initial commit of nanhu
7 files changed, 95 insertions(+)
create mode 100644 AndroidBoard.mk
create mode 100644 AndroidProducts.mk
create mode 100644 BoardConfig.mk
create mode 100644 cm.mk
create mode 100644 device_nanhu.mk
create mode 100644 recovery.fstab
create mode 100644 system.prop
~/source/cm/branch/cm-10.2
Done!
Use the following command to set up your build environment:
lunch cm_nanhu-eng
And use the follwowing command to build a recovery:
. build/tools/device/makerecoveries.sh cm_nanhu-eng
Since the script seems to look up for boot.img-ramdisk.gz and boot.img-zImage, I decided to investigate a bit further. I renamed boot.img to kernel.elf and used flashtool elf extractor to unzip kernel.elf. I obtained four files as a result of the extraction:
1) kernel.elf.bootcmd
2) kernel.elf.cert
3) kernel.elf.Image
4) kernel.elf.ramdisk.gz
Since mkvendor needed boot.img-ramdisk.gz and boot.img-zImage, I renamed all the files:
1) kernel.elf.bootcmd >> kernel.img-bootcmd
2) kernel.elf.cert >> kernel.img-cert
3) kernel.elf.Image >> kernel.img-zImage
4) kernel.elf.ramdisk.gz >> kernel.img-ramdisk.gz
Now I repackaged them using mkelf.py script. Since I couldn't find any command specific to nanhu, I edited it to fit for the device:
python mkelf.py -o edited.elf [email protected] [email protected],ramdisk [email protected],cmdline
This command throws no error and produces edited.elf. All of the files are packed in except kernel.img-cert as I didn't know the arguments for it ([email protected]?x????????,cert). I rename the edited.elf to boot2.img.
But I get the same error as the one I get when I use the unedited kernel (boot.img)
What should I do to get out of this format abyss? Would I have better luck with mkbootimg? If so, could you point me out to a thread or tell me here itself how to use it?
Thank you all!
Click to expand...
Click to collapse
Nevermind :/ Fixed it myself.
Repacked the edited files using mkbootimg.
mkbootimg --kernel kernel.img-zImage --ramdisk kernel.img-ramdisk.gz --cmdline kernel.img-bootcmd -o boot.img
I recently got my hands on a WeTek Hub. All round quite a nice little box, but the default lowmemorykiller settings are a little annoying, and sometimes result in the boot failing because the kernel decided to kill one of the startup processes. I'm trying to modify the settings in the init.rc, but I'm having a spot of trouble with a boot loop after repacking the boot image.
I copied the image off the device by using dd to extract the partition to a file, and then used the built-in FTP server to copy it off the device, and extracted it using unmkbootimg. after unzipping, extracting, modifying, and re-packing, I used mkbootimg to recreate the image, and dd'd it back onto the box (commands below).
Code:
dd if=/dev/block/boot of=/sdcard/boot.img
Code:
./unmkbootimg boot.img
mv initrd.img{,.gz}
gunzip initrd.img.gz
mkdir initrd
cp initrd.img initrd
cd initrd
cpio -i < initrd.img
rm initrd.img
# change stuff here
find . | cpio -o -H newc > ../initrd.cpio
cd ..
gzip initrd.cpio
./mkbootimg --kernel kernel.gz --ramdisk initrd.img.gz -o new_boot.img
Code:
dd if=/sdcard/new_boot.img of=/dev/block/boot
Unfortunately, that left me with a flashing WeTek logo as the it continuously rebooted. examining the logs from u-boot didn't give anything useful, but luckily I was able to get it into recovery and flash Ricardo's Android TV ROM back on there. Unfortunately, I'm still stuck with the original boot failure issue. Any clues as to what I've missed?
I do so
Code:
cd boot
../mkboot boot.img unpaсk
cd unpack/ramdisk
find . | cpio -o -H newc | gzip > ../ramdisk.packed
[I][B]# (edit size ramdisk in /boot/unpack/img_info file)[/B][/I]
cd ../..
../mkboot unpack boot.img
all is working
Hey all,
I am learning how Android works and am trying to figure out how I can update the Android filesystem by extracting a ramdisk from normal boot.img, adding some files, then flashing it back. So far, I have been unsuccessful in doing this and am hoping to figure out why. Here's the steps below I have taken:
Using a Google Pixel 4a, Android 11, kernel v 4.14 (i.e. not GKI)
High level:
Extract ramdisk.cpio from boot.img using magiskboot via adb on device, modify extract contents, sent back up to magiskboot, repackaged, then flashed via fastboot.
Detailed steps:
Grab ramdisk.cpio
Code:
$ # obtain the ramdisk.cpio from magiskboot
$ adb -d shell "cd ${BOOT_IMG_PATH}; ./magiskboot unpack boot.img"
$ adb -d pull /${BOOT_IMG_PATH}/ramdisk.cpio /tmp/
$ # attempt to modify the filesystem
$ mkdir /tmp/rd && cd rd
$ cpio -i < /tmp/ramdisk.cpio
$ touch yolo
$ echo "why doest this work" > system/wtf.txt
$ echo "why doest this work" > sys/wtf.txt
$ echo "why doest this work" > vendor/wtf.txt
#patch this directory back up and send to magiskboot
$ find . | cpio -oH new > /tmp/new.ramdisk.cpio
$ adb -d push /tmp/new.ramdisk.cpio ${BOOT_IMG_PATH}/ramdisk.cpio
$ adb -d shell "cd ${BOOT_IMG_PATH}; ./magiskboot repack boot.img
$ adb -d pull /${BOOT_IMG_PATH}/new-boot.img /tmp/
# apply this modifyied boot.img
$ adb reboot bootloader
fastboot flash boot /tmp/new-boot.img
fastboot reboot
After doing this, I'll adb back in to verify:
Code:
adb -d shell "find / -name "wtf.txt" 2>/dev/null
# silence.... always silence... no file change
* I am aware that Wu modifies the extracted dtb file from boot.img with a "magiskboot dtb dtb patch" command but that doesn't seem to apply to my particular boot.img as the fstab doesn't seem to be around
* I am aware that vbmeta and codesigning, I have disabled vbmeta via fastboot
* I am aware that there's A/B slots for flashing. I have tried flashing both slots to make sure the updated ramdisk is seen
* I am aware of magiskboot's kernel patch from skip_initramfs -> want_initramfs. I could use some clarification on this if it pertains to my problem
* My Android device uses "mount method C" from Wu's great writeup https://github.com/topjohnwu/Magisk/blob/master/docs/boot.md. That is, it's init's job to mount everything on my device. I guess I feel confused as to why init wouldn't mount the additional files that I've added to the ramdisk
Extremely grateful for help or guidance on what I've overlooked. Thanks y'all
You should probably examine your modified boot file to see if the new stuff is in there.
I don't use your tools or even deal with cpio as a file type.
Code:
C:\>echo Hello > sbin\bogus
C:\>imgutil /i boot.img sbin/bogus
C:\>imgutil /l boot.img
...
sbin/bogus
...