Database Develop

[HACK] compiled mkbootimg and unpack/repack linux scripts for boot.img

want to edit your boot.img?
included files in zip: mkbootimg (i compiled this file from android source), unpack-bootimg.pl, repack-bootimg.pl
i edited the repack script to compile the nexus s img correctly.
Code:
--base 0x30000000 --pagesize 4096
first dump original boot.img:
Code:
cat /dev/mtd/mtd2 > /sdcard/boot.img
then drag/drop to your linux box to edit file.
use unpack script:
Code:
./unpack-bootimg.pl boot.img
you will end up with 2 compressed files and 1 folder.
finished editing and want to repack boot.img, for example:
Code:
./repack-bootimg.pl <kernel> <ramdisk-directory> <outfile>
most info and scripts pulled from here: http://android-dls.com/wiki/index.php?title=HOWTO:_Unpack,_Edit,_and_Re-Pack_Boot_Images, thanks to the original author.
test your new boot.img:
Code:
fastboot boot boot.img

Two things:
1. if you have any bad blocks in your boot partition, this method will fail to extract the boot.img (you need to skip bad blocks, but cat will just get an error)
2. you can replace just the kernel (leaving the ramdisk and parameters intact) using:
Code:
% fastboot flash zimage zImage
The bootloader will read-modify-write the boot partition, replacing the kernel only.

how would you skip bad blocks? i never thought of a phone as having bad blocks.

k0mpresd said:
i never thought of a phone as having bad blocks.
Click to expand...
Click to collapse
All flash devices can have bad blocks. But it usually isn't something the end user would notice, unless there are so many and something is wrong that you're losing drive space.
edit: more info here if your curious http://en.wikipedia.org/wiki/Flash_memory

hmm, very strange thing happening to me. I've only gotten my boot.img to compile and boot successfully once with this method, but now I can't seem to get it to compile? I keep getting errors of the file name or file type. I'm using the correct usage.. If I compile manually with mkbootimg on the cmd line it'll compile but it won't boot. Just bootloops at the Google splash..

Jroid try my Matr1x kernel and see what happens
Sent from my Nexus S using XDA App

The problem seems to be compiling the boot with the perl scripts, not the kernel itself.

Try manually:
Once unpacked do the boot.img-ramdisk.cpio.gz with the following command (moved to the ramdisk folder):
Code:
#sudo find . | cpio -o -H newc | gzip > ../<your boot name>.img-ramdisk.cpio.gz
Then cd ../
And repack:
Code:
#./mkbootimg --kernel <your boot name>.img-kernel.gz --ramdisk <your boot name>.img-ramdisk.cpio.gz --base 0x30000000 --pagesize 4096 -o boot.img

you can replace just the kernel (leaving the ramdisk and parameters intact) using:
Code:
% fastboot flash zimage zImage
The bootloader will read-modify-write the boot partition, replacing the kernel only.
Click to expand...
Click to collapse
It won't work on the Nexus S.

python08 said:
It won't work on the Nexus S.
Click to expand...
Click to collapse
exactly, i'd love to be able to do this for some testing but it doesn't allow me.
EDIT: yes it does. Swetland is right

Chamb' said:
Try manually:
Once unpacked do the boot.img-ramdisk.cpio.gz with the following command (moved to the ramdisk folder):
Code:
#sudo find . | cpio -o -H newc | gzip > ../<your boot name>.img-ramdisk.cpio.gz
Then cd ../
And repack:
Code:
#./mkbootimg --kernel <your boot name>.img-kernel.gz --ramdisk <your boot name>.img-ramdisk.cpio.gz --base 0x30000000 --pagesize 4096 -o boot.img
Click to expand...
Click to collapse
I've tied compiling a boot both manually (with cmdline) and with the perl scripts and have used a simple kernel.gz and ramdisk.cpio.gz for my file names.. doesn't really matter what I name it as long as it has the correct file format in this .gz and .cpio.gz right? the manual compile goes fine with base 0x30000000 and pagesize 4096
however, it does not boot and will bootloop at the Google splash

Used boot.img extracted from (what ROM ?) cat /dev/mtd/mtd2 ?
Is the phone start with this boot.img (unchanged) if you flash it by typing "fastboot flash..." ?
After that, just try to unpack and repack the boot.img without changes on ramdisk or kernel, if it works that means your changes suck (^^).
These commands (or perl scripts) work perfectly for me.

Lol I will try doing that. The boot.img I used is from stock 2.3.4, edited the ramdisk (specifically init.rc & init.herring.rc)
Like I said, first time I used the perl scripts I edited my ramdisk, threw in a netarchy kernel, it compiled fine and booted. Now if I use the perl script to repack with an aosp kernel, it gives me an error about file name and/or extension being wrong. Or complains it can't find mkbootimg when its there and executable. I'll re run it again and post errors
Sent from my Nexus S

he guys where is the boot image located? not the animation, the google logo at the start of the booting!
Sent from my Nexus S using XDA Premium App

ok so when I used the repack-bootimg.pl script, it kept giving me this error:
Code:
boot.img-kernel.gz Not a directory at ./repack-bootimg.pl line 13.
So I ran mkbootimg manually, without a cmdline comment as stated above. It compiled
and booted beautifully all stock with no init.rc or init.herring.rc edits.
however when I compile a boot.img coupled with a stock kernel and a modified ramdisk, I get a non-booting boot.img. One came out at 2.9 mb and the other at 5.6 mb neither boots using the same cmd that compiled the working boot. Must be my edits.. I literally only changed about 1 line in init.rc and another line in init.herring.rc that causing it not to boot.
By the way, I got some info on a stock boot.img using the unpackbootimg binary (not the perl script) and here's what it outputs:
Code:
#BOARD_KERNEL_CMDLINE console=ttyFIQ0 no_console_suspend
BOARD_KERNEL_BASE 30000000
BOARD_PAGE_SIZE 00001000
I enter that pagesize and it says it's not a valid value when I compile boot.img's

Borky_16 said:
he guys where is the boot image located? not the animation, the google logo at the start of the booting!
Sent from my Nexus S using XDA Premium App
Click to expand...
Click to collapse
part of the kernel
to change-https://github.com/morfic/Samsung-logo

ogdobber said:
part of the kernel
to change-https://github.com/morfic/Samsung-logo
Click to expand...
Click to collapse
yeah i know thanks for the link a helping source though!
Sent from my Nexus S using XDA Premium App

Sorry for the Control C Control V of it, but I just found this topic now..
I`m facing this problem when I try to unpack boot.img..
I have done it 2 days ago but dunno why, now I can`t..
Follows what is happening..
Code:
[email protected]:~/NS-bootwork$ ./unpack-bootimg.pl boot.img
Found a secondary file after the ramdisk image.
According to the spec (mkbootimg.h) this file can exist,
but this script is not designed to deal with this scenario.
The Kernel is built, as a zImage and the WLAN as a bmc3429.ko..
Just repeating, I have built this Kernel 2 days ago in the same way, without any problems, but now I`m struggling on the message after inputting ./unpack-bootimg.pl boot.img..
Dunno what else to try, I re-downloaded the unpack-bootimg.pl from 2 different sources, and still the same error..
Any ideas?
Many thanks..
P.S.: Ubuntu 11.04 x64..
EDIT
Well, I already solve it!
That is what I did..
As unpack-bootimg.pl was not working (don`t know why) I used split_bootimg.pl script, splitting the boot.img and created new ramdisk img..
Code:
./split_bootimg.pl boot.img
mkdir ramdisk
cd ramdisk
gzip -dc ../boot.img-ramdisk.gz | cpio -i
find . | cpio -o -H newc | gzip > ../newramdisk.cpio.gz
Then after just compiled the Kernel with
Code:
./mkbootimg --kernel zImage --ramdisk newramdisk.cpio.gz --base 0x30000000 --pagesize 4096 --cmdline _console_suspend=1 console=bull's -o newtestboot.img'no
Witches includes " --cmdline _console_suspend=1 console=bull's" to not break BT functionality, in the case of Nexus S..

I found the tools here work well: http://glandium.org/blog/?p=2214
...if you then use the code originally posted above:
Code:
sudo find . | cpio -o -H newc | gzip > ../<your boot name>.img-ramdisk.cpio.gz
./mkbootimg --kernel <your boot name>.img-kernel.gz --ramdisk <your boot name>.img-ramdisk.cpio.gz --base 0x30000000 --pagesize 4096 -o boot.img

[I9001] [SCRIPT] [ODIN] How to create an Odin package from a cwm-zip (or backup)

The script (see below) works as follows:
1. It takes the correct files from the BaseRom folder and copies them to the BuildOdin folder
2. If boot or recovery images exist in NewRom folder (extracted from the cwm zip) it will copy them to the BuildOdin folder too
3. It will create the system.img.ext4 file in the BuildOdin folder
4. It will copy the system folder in the NewRom folder to the system.img.ext4 file
5. It will tar and md5 the files in BuildOdin folder
So make sure you have:
1. The adsp.mbn, amss.mbn, cache.img.ext4 and preload.img.ext4 in the BaseRom folder
2. The boot.img and recovery.img in the NewRom folder (or BaseRom)
3. The system folder in the NewRom folder
And run the script
Code:
#!/bin/sh
echo 'Requesting password to allow running as root...'
sudo echo 'Thanks :)!'
# Make folder
if [ ! -d "BuildOdin" ]
then
mkdir BuildOdin
fi
# Copy BaseRom files
cp BaseRom/adsp.mbn BuildOdin/adsp.mbn
cp BaseRom/amss.mbn BuildOdin/amss.mbn
cp BaseRom/cache.img.ext4 BuildOdin/cache.img.ext4
cp BaseRom/preload.img.ext4 BuildOdin/preload.img.ext4
# Copy boot image
if [ -s NewRom/boot.img ]
then
cp NewRom/boot.img BuildOdin/boot.img
else
cp BaseRom/boot.img BuildOdin/boot.img
fi
# Copy recovery image
if [ -s NewRom/recovery.img ]
then
cp NewRom/recovery.img BuildOdin/recovery.img
else
cp BaseRom/recovery.img BuildOdin/recovery.img
fi
# Create system image
mysyssize=`du -s -h NewRom/system | awk 'BEGIN{FS="[M]"} {print $1}'`
mysyssizeincreased=$((mysyssize+50))
echo 'Filesize will be' $mysyssizeincreased 'MB'
echo 'dd empty image...'
dd if=/dev/zero of=BuildOdin/system.img.ext4 bs=1M count=$mysyssizeincreased >&- 2>&-
echo 'make it ext4...'
mke2fs -F -T ext4 BuildOdin/system.img.ext4 >&- 2>&-
echo 'mounting...'
sudo mount -t ext4 -o loop BuildOdin/system.img.ext4 /mnt >&- 2>&-
echo 'copying system...'
cp NewRom/system/* /mnt -rp
sync
echo 'unmounting...'
sudo umount /mnt
# Create Odin and Odin MD5 files
cd BuildOdin
echo 'tarring...'
tar -cf MyOdinpack.tar adsp.mbn amss.mbn boot.img cache.img.ext4 preload.img.ext4 recovery.img system.img.ext4
echo 'copying...'
cp MyOdinpack.tar MyOdinpack.tar.md5
echo 'md5sum...'
md5sum -t MyOdinpack.tar>>MyOdinpack.tar.md5
echo 'done!'
It looks like it works. I do have some stuff I am wondering about:
1. I have added 50 MB to the filesize, with 30 MB additional I still got a not enough diskspace error. Wondering why...
2. Will it work this way? When looking at a cwm-zip it does contain a system folder but they also contain some other stuff... who knows... anyone care to test?
Well, looks like it's not all that easy. The script works, it creates a file with the exact same files as the one created with dd on the device, but for some reason when using it in Odin, it doesn't work...
Creating the Odin package is superfast now, but will still require some more testing. I guess I should do it with a ROM that I have done before... but too lazy atm...
Btw, this way I could create an Odin package from a CWM backup too If ever needed, just let me know
Regards,
Nika.

you could try making system.img file, then rename it to system.img.ext4. Sound foolish probably, but sometimes these double extensions are just added as an indicator. in this case for the system to look up what partition type to take. (I could be horribly wrong tho. But there are like 0 tools on internet for an ext4 maker so not many options available)

Maybe create an empty ext4 image on PC, mount loopback in cwm and copy files to it.
Sent from my GT-I9001 using XDA App

Create image on your phone using busybox
Edit: I updated the script.
I played a bit with the busybox:
my working dir is /sdcard/external_sd/imgtest!
DD a file of ~300MB
busybox dd if=/dev/zero of=myimg.img bs=1M count=300
Create a ext4 filesystem on this img
busybox mke2fs -F -T ext4 -L Image myimg.img
Create a new /dev node, named "loop99", type "block device" (b), and some major and minor number
busybox mknod /dev/block/loop99 b 7 99
Prepare your new loop device with an img file (delete is with losetup -d /dev/block/loop99)
busybox losetup /dev/block/loop99 /sdcard/external_sd/imgtest/myimg.img
Mount it finally
busybox mount /dev/block/loop99 /sdcard/external_sd/imgtest/mymnt
Now you may copy what you want, say /system, to this img.
And unmount it (make sure it's not in use anymore)
busybox umount /dev/block/loop99
Maybe invoke some commands to check the size of /system? A quick one liner would be
busybox df /system -h | grep /system | awk 'BEGIN{FS="[M]"} {print $2}' | awk 'BEGIN{FS="[.]"} {print $1}'
Could be part of the shell script, saved to a variable and increased by some MB just to make sure^^
A very quick and dirty script:
#!/bin/sh
mysyssize=`busybox df /system -h | grep /system | awk 'BEGIN{FS="[M]"} {print $2}' | awk 'BEGIN{FS="[.]"} {print $1}'`
mysyssizeincreased=$((mysyssize+20))
mkdir /sdcard/external_sd/myimages
mkdir /sdcard/mnt/
mkdir /sdcard/mnt/mymnt
cd /sdcard/external_sd/myimages
echo Filesize is $mysyssizeincreased
echo Now dd a new image for your folder
echo dd in progress...
busybox dd if=/dev/zero of=myimgfile.img bs=1M count=$mysyssizeincreased
echo mke2fs with type ext4 on your file...
busybox mke2fs -F -T ext4 -L Imagename myimgfile.img
echo create new dev-node...
busybox mknod /dev/block/loop99 b 7 99
echo apply loopback setup on this node...
busybox losetup /dev/block/loop99 /sdcard/external_sd/myimages/myimgfile.img
echo mounting new image...
busybox mount /dev/block/loop99 /sdcard/mnt/mymnt
echo done!
echo
echo now copy your system files over preserving permissions...
cp /system/* /sdcard/mnt/mymnt -rp
sync
busybox umount /sdcard/mnt/mymnt
losetup -d /dev/block/loop99
rm /dev/block/loop99
echo done!
echo done!
echo done!
echo
Click to expand...
Click to collapse
Save as a .sh script and execute it. I tried with some ssh server on phone and shell on my PC.
Worked fine, but to be sure a test with a restore would be needed, so treat it as highly experimental.

Very nice, much appreciated!!! Will try (convert) them on ubuntu one of these days as I'd prefer to do the job on a dual-cpu machine

Well then you should skip the steps with mknod and so on. Mount is much more powerful there, so you should be able to do it with these commands:
dd if=/dev/zero of=/tmp/image bs=1M count=300
mkfs.ext4 /tmp/image
mount -o loop /tmp/image /mnt

Hmmm... getting a "is not a block special device" message when ext4-ing in linux. Either the command file is incorrect, or I need to suppress that message somehow... more news soon

Okay!! Here's the first version of the script:
Code:
#!/bin/sh
echo 'Requesting password to allow running as root...'
sudo echo 'Thanks :)!'
# Make folder
if [ ! -d "BuildOdin" ]
then
mkdir BuildOdin
fi
# Copy BaseRom files
cp BaseRom/adsp.mbn BuildOdin/adsp.mbn
cp BaseRom/amss.mbn BuildOdin/amss.mbn
cp BaseRom/cache.img.ext4 BuildOdin/cache.img.ext4
cp BaseRom/preload.img.ext4 BuildOdin/preload.img.ext4
# Copy boot image
if [ -s NewRom/boot.img ]
then
cp NewRom/boot.img BuildOdin/boot.img
else
cp BaseRom/boot.img BuildOdin/boot.img
fi
# Copy recovery image
if [ -s NewRom/recovery.img ]
then
cp NewRom/recovery.img BuildOdin/recovery.img
else
cp BaseRom/recovery.img BuildOdin/recovery.img
fi
# Create system image
mysyssize=`du -s -h NewRom/system | awk 'BEGIN{FS="[M]"} {print $1}'`
mysyssizeincreased=$((mysyssize+50))
echo 'Filesize will be' $mysyssizeincreased 'MB'
echo 'dd empty image...'
dd if=/dev/zero of=BuildOdin/system.img.ext4 bs=1M count=$mysyssizeincreased >&- 2>&-
echo 'make it ext4...'
mke2fs -F -T ext4 BuildOdin/system.img.ext4 >&- 2>&-
echo 'mounting...'
sudo mount -t ext4 -o loop BuildOdin/system.img.ext4 /mnt >&- 2>&-
echo 'copying system...'
cp NewRom/system/* /mnt -rp
sync
echo 'unmounting...'
sudo umount /mnt
# Create Odin and Odin MD5 files
cd BuildOdin
echo 'tarring...'
tar -cf MyOdinpack.tar adsp.mbn amss.mbn boot.img cache.img.ext4 preload.img.ext4 recovery.img system.img.ext4
echo 'copying...'
cp MyOdinpack.tar MyOdinpack.tar.md5
echo 'md5sum...'
md5sum -t MyOdinpack.tar>>MyOdinpack.tar.md5
echo 'done!'
It looks like it works. I do have some stuff I am wondering about:
1. I have added 50 MB to the filesize, with 30 MB additional I still got a not enough diskspace error. Wondering why...
2. Will it work this way? When looking at a cwm-zip it does contain a system folder but they also contain some other stuff... who knows... anyone care to test?
The script works as follows:
1. It takes the correct files from the BaseRom folder and copies them to the BuildOdin folder
2. If boot or recovery images exist in NewRom folder (extracted from the cwm zip) it will copy them to the BuildOdin folder too
3. It will create the system.img.ext4 file in the BuildOdin folder
4. It will copy the system folder in the NewRom folder to the system.img.ext4 file
5. It will tar and md5 the files in BuildOdin folder
So make sure you have:
1. The adsp.mbn, amss.mbn, cache.img.ext4 and preload.img.ext4 in the BaseRom folder
2. The boot.img and recovery.img in the NewRom folder (or BaseRom)
3. The system folder in the NewRom folder
And run the script
Regards,
Nika.

Well, looks like it's not all that easy. The script works, it creates a file with the exact same files as the one created with dd on the device, but for some reason when using it in Odin, it doesn't work...
Creating the Odin package is superfast now, but will still require some more testing. I guess I should do it with a ROM that I have done before... but too lazy atm...
Btw, this way I could create an Odin package from a CWM backup too If ever needed, just let me know

nikagl said:
Well, looks like it's not all that easy. The script works, it creates a file with the exact same files as the one created with dd on the device, but for some reason when using it in Odin, it doesn't work...
Creating the Odin package is superfast now, but will still require some more testing. I guess I should do it with a ROM that I have done before... but too lazy atm...
Btw, this way I could create an Odin package from a CWM backup too If ever needed, just let me know
Click to expand...
Click to collapse
I've been searching the forums for a general way to make Odin-flashable ROMs from CWM backups. I'm particularly interested in doing this for Samsung Galaxy 10.1/8.9/7.7 tabs (Honeycomb). Many tutorials use ADB and datadumps, which is fine but is very device-specific, and I haven't found one for the Honeycomb Galaxy Tabs. Using CWM backups seem cleanest and least-device specific way.
So I *AM* interested in how you would start with a full CWM backup, and (not using any base ROMs) get an Odin-flashable .tar.md5 file.

hmmmm bht ho gya hia yaar

kblam said:
I've been searching the forums for a general way to make Odin-flashable ROMs from CWM backups. I'm particularly interested in doing this for Samsung Galaxy 10.1/8.9/7.7 tabs (Honeycomb). Many tutorials use ADB and datadumps, which is fine but is very device-specific, and I haven't found one for the Honeycomb Galaxy Tabs. Using CWM backups seem cleanest and least-device specific way.
So I *AM* interested in how you would start with a full CWM backup, and (not using any base ROMs) get an Odin-flashable .tar.md5 file.
Click to expand...
Click to collapse
Hi kblam,
Well... it's still a work in progress. Not sure why it doesn't work at the moment, but here's my current script:
Code:
#!/bin/sh
echo 'Requesting password to allow running as root...'
sudo echo 'Thanks :)!'
# Make folder
if [ ! -d "BuildOdin" ]
then
mkdir BuildOdin
fi
# Copy BaseRom files
cp BaseRom/adsp.mbn BuildOdin/adsp.mbn
cp BaseRom/amss.mbn BuildOdin/amss.mbn
cp BaseRom/cache.img.ext4 BuildOdin/cache.img.ext4
cp BaseRom/preload.img.ext4 BuildOdin/preload.img.ext4
# Copy boot image
if [ -s NewRom/boot.img ]
then
cp NewRom/boot.img BuildOdin/boot.img
else
cp BaseRom/boot.img BuildOdin/boot.img
fi
# Copy recovery image
if [ -s NewRom/recovery.img ]
then
cp NewRom/recovery.img BuildOdin/recovery.img
else
cp BaseRom/recovery.img BuildOdin/recovery.img
fi
# Create system image
mysyssize=`du -s -h NewRom/system | awk 'BEGIN{FS="[M]"} {print $1}'`
mysyssizeincreased=$((mysyssize+50))
echo 'Filesize will be' $mysyssizeincreased 'MB'
echo 'dd empty image...'
dd if=/dev/zero of=BuildOdin/system.img.ext4 bs=1M count=$mysyssizeincreased >&- 2>&-
echo 'make it ext4...'
mke2fs -F -T ext4 BuildOdin/system.img.ext4 >&- 2>&-
echo 'mounting...'
sudo mount -t ext4 -o loop BuildOdin/system.img.ext4 /mnt >&- 2>&-
echo 'copying system...'
cp NewRom/system/* /mnt -rp
sync
echo 'unmounting...'
sudo umount /mnt
# Create Odin and Odin MD5 files
cd BuildOdin
echo 'tarring...'
tar -cf MyOdinpack.tar adsp.mbn amss.mbn boot.img cache.img.ext4 preload.img.ext4 recovery.img system.img.ext4
echo 'copying...'
cp MyOdinpack.tar MyOdinpack.tar.md5
echo 'md5sum...'
md5sum -t MyOdinpack.tar>>MyOdinpack.tar.md5
echo 'done!'
Taking out all unnessesary comments and commands, what it's supposed to do is the following:
1. First copy the files from the BaseRom (the ones you usually do not extract either):
Code:
cp BaseRom/adsp.mbn BuildOdin/adsp.mbn
cp BaseRom/amss.mbn BuildOdin/amss.mbn
cp BaseRom/cache.img.ext4 BuildOdin/cache.img.ext4
cp BaseRom/preload.img.ext4 BuildOdin/preload.img.ext4
2. Then take the boot and recovery from another folder as they usually need to be based on another kernel (f/e Skyhigh kernel ) and/or recovery (f/e CWM/Faemod):
Code:
cp NewRom/boot.img BuildOdin/boot.img
cp NewRom/recovery.img BuildOdin/recovery.img
3. Take the size of the new image (based on the system folder size + 50):
Code:
mysyssize=`du -s -h NewRom/system | awk 'BEGIN{FS="[M]"} {print $1}'`
mysyssizeincreased=$((mysyssize+50))
4. Create an empty system image
Code:
dd if=/dev/zero of=BuildOdin/system.img.ext4 bs=1M count=$mysyssizeincreased >&- 2>&-
5. Convert it to ext4
Code:
mke2fs -F -T ext4 BuildOdin/system.img.ext4 >&- 2>&-
6. Mount it and copy the new system files (can be unzipped from the cwm-zip) and unmount
Code:
sudo mount -t ext4 -o loop BuildOdin/system.img.ext4 /mnt >&- 2>&-
cp NewRom/system/* /mnt -rp
sync
sudo umount /mnt
7. The rest is same to building other md5 odin files. Combine them with tar and calculate and add the md5 sum
Code:
tar -cf MyOdinpack.tar adsp.mbn amss.mbn boot.img cache.img.ext4 preload.img.ext4 recovery.img system.img.ext4
cp MyOdinpack.tar MyOdinpack.tar.md5
md5sum -t MyOdinpack.tar>>MyOdinpack.tar.md5
As mentioned - I am not sure why the system image created this way does not work yet (I only tested it once) - maybe someone else is willing to test?
Regards,
Nika.

[Q] Modify boot.img of The Titan Prime ROM

Hello everybody,
I am using The Titan Prime ROM (Version 1.0.2) on my XT1068. It is very stable and fast. (Thanks to @Shawn5162 and his helpers!)
Nevertheless I would like to make some modifications to the boot.img. I am able to modify the system folder and resign the package.
But if I try to unpack and repack the boot.img the phone jumps immediately into the bootloader after the start and says 'Fastboot Reason: Fall-through from normal boot mode'.
I hoped you could have a look at my workflow and tell me what I am doing wrong:
First I take your Rom and unzip it:
Code:
$ unzip TitanPrimeROMv1.0.2-XT1068-69.zip -d Titan
$ cd Titan
Here is what the boot_info tells me:
Code:
$ boot_info boot.img
PAGE SIZE: 2048
BASE ADDRESS: 0x00000000
RAMDISK ADDRESS: 0x01000000
CMDLINE: 'console=ttyHSL0,115200,n8 androidboot.console=ttyHSL0 androidboot.hardware=qcom user_debug=31 msm_rtb.filter=0x37 vmalloc=400M utags.blkdev=/dev/block/platform/msm_sdcc.1/by-name/utags'
Then I unpack the boot image:
Code:
$ unpack boot.img
Boot = boot.img
unmkbootimg version 1.2 - Mikael Q Kuisma <[email protected]>
Kernel size 6449544
Kernel address 0x8000
Ramdisk size 807152
Ramdisk address 0x1000000
Secondary size 0
Secondary address 0xf00000
Kernel tags address 0x100
Flash page size 2048
Board name is ""
Command line "console=ttyHSL0,115200,n8 androidboot.console=ttyHSL0 androidboot.hardware=qcom user_debug=31 msm_rtb.filter=0x37 vmalloc=400M utags.blkdev=/dev/block/platform/msm_sdcc.1/by-name/utags"
This image is built using standard mkbootimg
Extracting kernel to file zImage ...
Extracting root filesystem to file initramfs.cpio.gz ...
All done.
---------------
To recompile this image, use:
$ mkbootimg --kernel zImage --ramdisk initramfs.cpio.gz --base 0x0 --cmdline 'console=ttyHSL0,115200,n8 androidboot.console=ttyHSL0 androidboot.hardware=qcom user_debug=31 msm_rtb.filter=0x37 vmalloc=400M utags.blkdev=/dev/block/platform/msm_sdcc.1/by-name/utags' -o new_boot.img
---------------
2974 blocks
Now I make some minor modification to the boot image like adding a file:
Code:
$ touch boot/ramdisk/hello_ramdisk
Then I try to rebuild the ramdisk:
Code:
$ mkbootimg --kernel boot/zImage --ramdisk boot/new-ramdisk.cpio.gz --base 0x0 --cmdline 'console=ttyHSL0,115200,n8 androidboot.console=ttyHSL0 androidboot.hardware=qcom user_debug=31 msm_rtb.filter=0x37 vmalloc=400M utags.blkdev=/dev/block/platform/msm_sdcc.1/by-name/utags' -o boot.img
I remove the boot folder, zip it and sign it:
Code:
$ mv boot ../
$ zip -r myrom.zip *
$ java -classpath /opt/android-sdk/tools/sign/testsign.jar testsign myrom.zip myrom-signed.zip
Then I place the file on the sdcard and try to install it via TWRP ‘Install’.
I am not sure what I am doing wrong any help would be appreciated :fingers-crossed:
Edit
I have tried the same procedure with CM-12-unofficial and stock ROMs and the result is the same, if I touch anything.

Did you ever solve this problem?
Edit: https://github.com/xiaolu/mkbootimg_tools worked for me.

[HELP][Q] How to properly repack ramdisk in order to avoid boot stuck?

Hello mates!
I've been playing with XT1097's boot.img and need some help as my boot.img fails to boot if I repack ramdisk.
Using abootimg
Extracting boot.img contents:
Code:
abootimg -x boot.img ==> produces bootimg.cfg, initrd.img and zImage files in the current directory
Updating boot.img contents without touching ramdisk (using the one extracted in the previous step):
Code:
abootimg -u boot.img -r initrd.img
If I extract initrd.img and try to repack it, then system fails at boot:
Extracting ramdisk (initrd.img) contents:
Code:
abootimg-unpack-initrd ==> produces a ramdisk subdir
Repacking without modyfing ramdisk folder contents:
Code:
abootimg-pack-initrd newramdisk.img
Updating boot.img with newramdisk.img
Code:
abootimg -u boot.img -r newramdisk.img
Even though the generated boot.img's size matches the original one - 10444800 bytes - system gets stuck at boot logo.
The same issue happens if I use these tools combined:
mkbootimg, unmkbootimg, gzip and cpio
Any ideas are welcome

How To Guide How to add additional files to an TWRP image

How to add additonal files to an TWRP image
The recovery image TWRP is very useful for the maintenance of the Android OS.
It's the Swiss Army knife for maintaining phones running the Android OS but sometimes you might miss some files in the TWRP recovery.
To add additional files to an TWRP image the instructions from the HowTo How to change files in the boot image can be used.
To make sure that the new files are also added to an TWRP installed in the boot partition additional steps are necessary.
To unpack and repack the TWRP image the Magisk binary magiskboot is necessary. This binary is part of TWRP so creating the new image should be done while the phone is booted from the TWRP image.
So to add additional files to an TWRP image do:
Bash:
# boot into the TWRP image
#
adb reboot bootloader
sudo fastboot boot /data/backup/ASUS_ZENFONE8/twrp/twrp-3.7.0_12-0-I006D.img
Wait until booting the TWRP image is done and open an adb shell
Bash:
adb shell
Create some directories for the work on the phone:
Bash:
mkdir -p /data/develop/workdir/twrp/ramdisk
Copy the TWRP image file from your PC to the working directory on the phone
Bash:
adb push twrp-3.7.0_12-0-I006D.img /data/develop/workdir/twrp
Unpack the image file:
Bash:
cd /data/develop/workdir/twrp
magiskboot unpack -h twrp-3.7.0_12-0-I006D.img
e.g.
Code:
ASUS_I006D:/data/develop/workdir/twrp # magiskboot unpack -h twrp-3.7.0_12-0-I006D.img
Parsing boot image: [twrp-3.7.0_12-0-I006D.img]
HEADER_VER [3]
KERNEL_SZ [18627321]
RAMDISK_SZ [34811448]
OS_VERSION [99.87.36]
OS_PATCH_LEVEL [2099-12]
PAGESIZE [4096]
CMDLINE [twrpfastboot=1]
KERNEL_FMT [gzip]
RAMDISK_FMT [gzip]
VBMETA
ASUS_I006D:/data/develop/workdir/twrp #
ASUS_I006D:/data/develop/workdir/twrp # ls -ltr
total 324223
-rw-rw---- 1 u0_a119 media_rw 100663296 2022-10-12 13:38 twrp-3.7.0_12-0-I006D.img
-rw-r--r-- 1 root root 100663296 2022-10-28 15:55 new-boot.img
-rw-rw-rw- 1 root root 66 2022-10-28 16:14 header
-rw-r--r-- 1 root root 41943552 2022-10-28 16:14 kernel
-rw-r--r-- 1 root root 88384000 2022-10-28 16:14 ramdisk.cpio
drwxrwxrwx 2 root root 3452 2022-10-28 16:15 ramdisk
ASUS_I006D:/data/develop/workdir/twrp #
Unpack the ramdisk from the TWRP image:
Bash:
cd /data/develop/workdir/twrp/ramdisk
cpio -idm <../ramdisk.cpio
The directory /data/develop/workdir/twrp/ramdisk now contains the contents of the ramdisk used for TWRP.
Now add the new files for the image to the directory /data/develop/workdir/twrp/ramdisk:
In this example we will add the binaries zsh, sqlite3, and vi.
Bash:
cd /data/develop/workdir/twrp/ramdisk
cp ../../newfiles/sqlite3 ./system/bin/
cp ../../newfiles/zsh ./system/bin/
cp ../../newfiles/vi ./system/bin/
Note:
In case you want to add new binaries :
To check if the binaries will work in TWRP execute the binaries while the phone is booted from the original TWRP image. If the binaries need additional libraries not included in TWRP just also add them to the TWRP image into the directory ./system/lib64 of the image.
The next step is necessary to make sure that TWRP will copy the new files also to a TWRP installation in a boot partition:
For each new file add an entry to the files
./ramdisk-files.sha256sum
./ramdisk-files.txt
in the directory with the contents from the ramdisk.
The file ramdisk-files.txt contains the name and path of the files used in the ramdisk for the boot partition and the file ramdisk-files.sha256sum contains the checksum for each of the files for the ramdisk.
Note:
If you change an existing file that is mentioned in the file ./ramdisk-files.sha256sum you must also correct the entry in that file.
So do for each new file:
echo <file_with_path_not_starting_with_a_dot_or_slash> >>ramdisk-files.txt ; done
sh256sum <file_with_path_startinge with_a_slash> >>ramdisk-files.sha256sum
e.g:
Code:
ASUS_I006D:/data/develop/workdir/twrp/ramdisk # for i in system/bin/sqlite3 system/bin/vi system/bin/zsh ; do sha256sum ./$i >>ramdisk-files.sha256sum ; echo "$i" >>ramdisk-files.txt ; done
ASUS_I006D:/data/develop/workdir/twrp/ramdisk #
Check the result.
Code:
ASUS_I006D:/data/develop/workdir/twrp/ramdisk # tail -4 ramdisk-files.sha256sum
8a8ff76cbda445f08ba3552598085089883f9d594cd7716e90f3411a8b82f8a0 ./twres/fonts/DroidSansMono.ttf
09fcec146d9ecba0f2a0b7362b52d2f87607a3c5760c94ba5fcd900e423e16f8 ./system/bin/sqlite3
3a221d10ffc275cadaf79fb1a00c39c9083ce672ea111205301e277091a04b51 ./system/bin/vi
354e415da42503ed4211907adf93ed8bfb14ce2e2d8418fcd7a3227873b4b53f ./system/bin/zsh
ASUS_I006D:/data/develop/workdir/twrp/ramdisk #
ASUS_I006D:/data/develop/workdir/twrp/ramdisk # tail -4 ramdisk-files.txt
twres/fonts/DroidSansMono.ttf
system/bin/sqlite3
system/bin/vi
system/bin/zsh
ASUS_I006D:/data/develop/workdir/twrp/ramdisk #
Correct the entry for the file ramdisk-files.txt in the file ramdisk-files.sha256sum :
Bash:
cd /data/develop/workdir/twrp/ramdisk
cp ./ramdisk-files.sha256sum ./ramdisk-files.sha256sum.org
NEW_ENTRY="$( sha256sum ./ramdisk-files.txt )" && sed -i -e "s#.*\./ramdisk-files.txt#${NEW_ENTRY}#g" ./ramdisk-files.sha256sum
Check the entries in the file ramdisk-files.sha256sum
Bash:
sha256sum --status -c ./ramdisk-files.sha256sum ; echo $?
If the output of that command is not 0 use
Bash:
sha256sum -c ./ramdisk-files.sha256sum | grep -v OK
to get the entry with the invalid checksum. Fix the entry and check again.
Now repack the ramdisk:
Bash:
cd /data/develop/workdir/twrp/ramdisk
find . | cpio -o >../ramdisk.cpio
And recreate the image file:
Bash:
cd /data/develop/workdir/twrp
magiskboot repack twrp-3.7.0_12-0-I006D.img
e.g
Code:
ASUS_I006D:/data/develop/workdir/twrp # magiskboot repack twrp-3.7.0_12-0-I006D.img
Parsing boot image: [twrp-3.7.0_12-0-I006D.img]
HEADER_VER [3]
KERNEL_SZ [18627321]
RAMDISK_SZ [34811448]
OS_VERSION [99.87.36]
OS_PATCH_LEVEL [2099-12]
PAGESIZE [4096]
CMDLINE [twrpfastboot=1]
KERNEL_FMT [gzip]
RAMDISK_FMT [gzip]
VBMETA
Repack to boot image: [new-boot.img]
HEADER_VER [3]
KERNEL_SZ [18618540]
RAMDISK_SZ [37358888]
OS_VERSION [99.87.36]
OS_PATCH_LEVEL [2099-12]
PAGESIZE [4096]
CMDLINE [twrpfastboot=1]
ASUS_I006D:/data/develop/workdir/twrp #
The file new-boot.img contains the TWRP image with the additional files.:
ASUS_I006D:/data/develop/workdir/twrp # ls -ltr new-boot.img
-rw-r--r-- 1 root root 100663296 2022-10-28 16:28 new-boot.img
ASUS_I006D:/data/develop/workdir/twrp #
To test the image, rename the file, copy the file to an PC and boot the phone from the image:
Bash:
mv new-boot.img twrp-3.7.0_12-0-I006D-enhanced.img
Execute on the PC:
Bash:
adb pull /data/develop/workdir/twrp/twrp-3.7.0_12-0-I006D-enhanced.img
adb reboot bootloader
sudo fastboot boot twrp-3.7.0_12-0-I006D-enhanced.img
Connect via adb to the phone booted from the new TWRP image and check the result:
Code:
ASUS_I006D:/ # ls -l /system/bin/zsh /system/bin/sqlite3 /system/bin/vi
-rwxr-xr-x 1 root root 1714720 2022-10-28 16:19 /system/bin/sqlite3
-rwxr-xr-x 1 root root 1815152 2022-10-28 16:19 /system/bin/vi
-rwxr-xr-x 1 root root 2004808 2022-10-28 16:19 /system/bin/zsh
ASUS_I006D:/ #
ASUS_I006D:/ # /system/bin/sqlite3 --version
3.39.3 2022-09-05 11:02:23 4635f4a69c8c2a8df242b384a992aea71224e39a2ccab42d8c0b0602f1e826e8
ASUS_I006D:/ #
ASUS_I006D:/ # /system/bin/vi --version | head -1
VIM - Vi IMproved 8.1 (2018 May 18)
ASUS_I006D:/ #
ASUS_I006D:/ # /system/bin/zsh --version
zsh 5.9 (aarch64-unknown-linux-android)
ASUS_I006D:/ #
Advanced Usage
To be able to distinguish the new image from the original one you can change or add values in the file ./default.prop in the ramdisk for the image, e.g.:
Bash:
# before creating the new ramdisk
cd /data/develop/workdir/twrp/ramdisk
echo "ro.product.type=enhanced" >>default.prop
Then when booted from the image you can check the new property, e.g.:
Code:
ASUS_I006D:/ # getprop ro.product.type
enhanced
ASUS_I006D:/ #
Notes:
The file default.prop is not listed in the checksum file ramdisk-files.sha256sum for the image.
Adding new files to ramdisk-files.sha256sum is not mandatory but recommended
To add files to the image that should not be copied to an TWRP installation in a boot partition just add them to the ramdisk but not to the file ramdisk-files.txt.
see also How to install TWRP via script
Update 28.11.2022 /bs
see als How to compile TWRP for the ASUS Zenfone 8