Does anyone tried rebuilding boot.img for Streak?
Standard tools for unpacking and repacking the boot.img do not work, because Streak boot.img has a non-standard layout.
I managed to extract zImage and initrd manually from a working boot.img from r2-4399-streak-superboot.zip
gzip signatures 1F 8B 08 00 are at offsets:
0x49E0 - kernel
0x242000 - initrd
I extracted them manually using:
Code:
dd if=boot.img of=kernel.gz ibs=1 skip=18912 count=2348576
dd if=boot.img of=initrd.cpio.gz ibs=1 skip=2367488
But after reconstructing it into a boot.img again and flashing, Streak does not boot.
Code:
mkbootimg --base 0x20000000 --cmdline 'console=ttyMSM2,115200n8 androidboot.hardware=qcom' --kernel kernel.gz --ramdisk initrd.cpio.gz -o boot.img
fastboot -i 0x413c flash boot boot.img
Even after modyfing mkbootimg sources accordingly to carlosloz post, the generated boot.img still does not boot.
Does anyone know what magic sauce Dell adds to its boot.img ?
The changes that were proposed by carlosloz were identical the the changes I'd made to my mkboot the day before, and that was able to create a boot.img that did boot an extracted 4399 kernel and ramdisk.
I'll remember to post either the source or elf of it when I get home tonight for you to try.
see this page over at android-dsl.com Edit and Re-Pack Boot Images
fone_fanatic said:
see this page over at android-dsl.com Edit and Re-Pack Boot Images
Click to expand...
Click to collapse
The very second line of my post stated that this instructions do not work for Streak.
kwaaq said:
I'll remember to post either the source or elf of it when I get home tonight for you to try.
Click to expand...
Click to collapse
Thanks. I hope this would work.
So far I'm just running in circles scratching my head :/
Yes!
I got enlightenment yesterday and found a way of building boot.img
Attached you will find a boot.img that contains only kernel, adbd and busybox.
You may use it to see how deep the Streak Hole goes.
I was able to chroot to an Ubuntu Linux installation using this image.
Code:
[email protected]:~/Android/boot$ fastboot -i 0x413c flash boot boot.img
sending 'boot' (3136 KB)... OKAY
writing 'boot'... OKAY
[email protected]:~/Android/boot$ fastboot -i 0x413c reboot
rebooting...
[email protected]:~/Android/boot$ adb shell
~ $ su
su: access granted, courtesy of www.magicandroidapps.com
/ # ls
bin init.qcom.post_boot.sh root
default.prop init.qcom.rc sbin
dev init.qcom.sh sys
etc init.rc system
init proc tmp
/ # ls /sbin
adbd
/ # mount -t yaffs2 /dev/block/mtdblock6 /system
/ # ls /system
PreLoadNetworkSettings customization lost+found
Wallpapers etc media
app fonts ts.conf
bin framework usr
bootpriority.xml lib xbin
build.prop logfilter.ini
busybox lost+found
/ # umount /system
/ # mkdir /ubuntu
/ # mount -t ext2 /dev/block/mmcblk1p2 /ubuntu
/ # ls /ubuntu
bin home mnt sbin system
boot lib opt selinux tmp
dev lost+found proc srv usr
etc media root sys var
/ # PATH=/usr/bin:/usr/sbin:/bin:/sbin
/ # chroot /ubuntu /bin/bash
[email protected]:/# ls
bin dev home lost+found mnt proc sbin srv system usr
boot etc lib media opt root selinux sys tmp var
[email protected]:/# exit
/ #
~ $
OK, so I download your boot.img file and fastboot flashed it. After the reboot it comes to a black screen but I get no ADB driver prompt on my computer. I assume it's just freezing on boot.
What version of the Streak are you running the rom on?
JoeJonnyBoy75 said:
OK, so I download your boot.img file and fastboot flashed it. After the reboot it comes to a black screen but I get no ADB driver prompt on my computer. I assume it's just freezing on boot.
What version of the Streak are you running the rom on?
Click to expand...
Click to collapse
It's based on 4399 build, so it possibly runs on 21-EU models only.
Black screen is not good. You should see a short blank and see the Dell logo again with lower intensity of softbuttons light.
How did you manage to get the kernel and ramdisk back together?
I'm currently working on replacing the internal sdcard with a 16GB one but I need to modify the init.rc files to make it work.
<rant>I could behave like Paul @ MoDaCo and just ignore the question. But... </rant>
Like I mentioned the kernel and initrd start with gzip signature.
So you need to extract:
- header: 0 - 0x49DF
- kernel.gz: 0x49E0 - 0x241FFF
- initrd.cpio.gz: 0x242000 - EOF
Disassembling several working boot.img revealed that the offsets are always the same, and the usually empty header contains something that looks like a bootloader code. So I figured mkbootimg file with zero-filled header won't work.
So, I created new initrd (mkbootfs or straight cpio - both work), padded it with /dev/zero to 4k page size, concatenated header+kernel+newinitrd.
Almost there. You need to update header offsets and sizes. initrd offset stays the same, but size is different. initrd size is 4 bytes from 0x10 byte in header. Just enter the size of initrd (before padding with zeros) there, and you're done.
First I did it manually. Now I have a simple bash script to automate the work.
Above method works 100%. Every boot.img I generate works fine.
The key is to start with a working boot.img for your device - you need a kernel suited to your hardware.
Any chance you'd like to share your script?
One other quick question. I understood most of your instructions, although this isn't really my field of expertise, except how/where to enter the size of the init. If I'm understanding you correctly it goes at address 0x00000010.
Which would mean that in your red pill the entry you have at that address is DA DD 0C 00?
Also if you have time could you explain the padding part?
I think I'm close to getting this working, and look forward to custom init files.
The following information got outdated.
See http://codex.xiaoka.com/wiki/streak:kernel_porting#flashing
(Attachment Removed)
JoeJonnyBoy75 said:
Any chance you'd like to share your script?
Click to expand...
Click to collapse
Sure. No prob.
But mind it's SuperUgly(TM) but it gets the job done.
Click to expand...
Click to collapse
JoeJonnyBoy75 said:
One other quick question. I understood most of your instructions, although this isn't really my field of expertise, except how/where to enter the size of the init. If I'm understanding you correctly it goes at address 0x00000010.
Which would mean that in your red pill the entry you have at that address is DA DD 0C 00?
Also if you have time could you explain the padding part?
I think I'm close to getting this working, and look forward to custom init files.
Click to expand...
Click to collapse
0x000CDDDA = 843226 bytes, which is the size of my initrd.
The page size of boot.img is 4k so you need to pad the initrd to fill the whole last page with something - preferably zeros.
smokku said:
Does anyone tried rebuilding boot.img for Streak?
Standard tools for unpacking and repacking the boot.img do not work, because Streak boot.img has a non-standard layout.
Click to expand...
Click to collapse
I was able to extract boot.img using the command "unpack-bootimg.pl" found in split_bootimg.zip from that link.
Code:
$ unpack-bootimg.pl boot.img
kernel written to boot.img-kernel.gz
ramdisk written to boot.img-ramdisk.cpio.gz
gzip: ../boot.img-ramdisk.cpio.gz: decompression OK, trailing garbage ignored
591 blocks
extracted ramdisk contents to directory boot.img-ramdisk/
Or is this not the proper way to do it?
fone_fanatic said:
I was able to extract boot.img using the command "unpack-bootimg.pl" found in split_bootimg.zip from that link.
[...]
Or is this not the proper way to do it?
Click to expand...
Click to collapse
IIRC unpack-bootimg.pl extracts initrd correctly, but kernel is broken,
and split_bootimg.pl the other way around - kernel is OK, but initrd is incomplete.
But splitting the image is easy. The reconstruction using standard tools (mkbootimg) does not work though.
smokku said:
IIRC unpack-bootimg.pl extracts initrd correctly, but kernel is broken,
and split_bootimg.pl the other way around - kernel is OK, but initrd is incomplete.
But splitting the image is easy. The reconstruction using standard tools (mkbootimg) does not work though.
Click to expand...
Click to collapse
Ahh ok, haven't tried to repack yet, just been snooping around in it.
Sent from my Dell Streak using XDA App
Apologies, first time I've actually gotten home at a sane hr for the past two weeks.
Thank you very much smokku. I've finally, successfully, recompiled my boot.img and am able to make changes.
Here are the step I used to get it to work. Note that the kernel for the 2.1 roms starts at a lower address then the 1.6 ones.
1. Unpack-bootimg.pl got me the initrd folder and contents.
2. I ended up extracting the header and kernel via a hex editor. I used the gzip headers to find the start of the initrd and then purged it.
3. This left me with a header/kernel file and the initrd folder. I then made the changes to initrd I wanted. (Still lots of testing to do)
4. I modified the script provided by smokku (awesome) to work with the header/kernel file being one file instead of two.
5. Ran the script and recorded the output size.
6. Opened the new compiled boot file with a hex editor and entered the size at address 0x10 (as per smokku).
7. Installed the new boot.img with fastboot and rebooted.
Now it all works and I'm able to modify to my hearts content. Guess I now have to do it with the 8105 build.
Thanks smokku, couldn't have done it without you.
Now the only missing link is the kernel source.
Related
With VEGAn 5.11 and Pershoot kernel. I want to do a few things when it boots up. I don't see the usual /etc/init.d kind of structure.
I did find init.rc and even found a link that describes its peculiar syntax. But editing that file (after remounting) doesn't "take" -- I assume it is on initfs and gets copied to a RAM disk on boot.
Is there anywhere easily user writeable where you can stick something in the boot sequence? Seems like that would be a common enough thing to need to do.
Thanks!
The init.rc is in the ramdisk, and the ramdisk is in the boot.img (found in all the stock and modded ROMs).
Here's a good guide on how unpack / repack that file: http://android-dls.com/wiki/index.php?title=HOWTO:_Unpack,_Edit,_and_Re-Pack_Boot_Images
(obviously it's a bit technical) What I can tell you is that you don't need any cmdline options for the boot.img
Here's a real quick breakdown of what I do (Ubuntu user):
Code:
./unpack-bootimg.pl boot.img
go to the extracted ramdisk folder, make my changes and then:
Code:
find . | cpio -o -H newc | gzip > ../newramdisk.cpio.gz
cd ..
mkbootimg --kernel boot.img-kernel.gz --ramdisk newramdisk.cpio.gz -o newboot.img
"newboot.img" being my new boot.img. That's how the boot.img in all my mods are created.
Thank you and yeah I figured that was it. Technical is not an issue as I sling unix/linux for ages. Salute to you for all your work on this platform.
Well I cheated a little. Here's what I did:
I noticed that you had added to the bottom of /init.rc a one shot service for /system/etc/shuttle_ins.sh.
So I just remounted rw for /system and added the following to the TOP of /system/etc/shuttle_ins.sh:
# added by aaw
if [ -f /system/etc/rc.local ]; then
sh /system/etc/rc.local &
fi
# end aaw
So now I can put what I want in rc.local -- start up sshd or whatever. In this case here's what I actually wanted:
#!/bin/sh
# this is run at the end of the init.rc sequence if it exists
until mount | grep -m1 sdcard2 ; do sleep 5 ; done # wait for sdcard2 mount
mkdir /mnt/sdcard/sdcard2 # make mount point (might fail, but who cares?)
mount -o bind /mnt/sdcard2 /mnt/sdcard/sdcard2
Of course, this assumes I will always have sdcard2 or it spins. Could put a timeout in I guess, but for me this is always the case. Now things like players that only look in /sdcard can find stuff on sdcard2 as well.
A bit of a hack. I wonder if the release DEVs would consider adding an rc.local in user land in a nicer way? Maybe have a system rc.0 that does the -f test for rc.local and that way if you wanted to add an rc.local you could but if you didn't no harm or foul.
Or did I miss a smarter way to do this?
Thanks for the help (and the great releases, of course!).
I found this in the market: https://market.android.com/details?id=os.tools.scriptmanager
Lets you run scripts at boot time. Haven't tried it for that though, but it could work instead of my rc.local fix. A little different since I assume it runs late (after Android is up) unlike the rc.local which runs before Android, unless I'm mistaken.
Hey fellas!!!
This is my first real contribution to my xda friends .I happy to share with you guys the script to make ODIN flashable rom for ext4 devices.
First of all I would like to say that this script currently supports only International variants of sgs2,sgs3 and SG Note.This is because I own only Note (similar to s2) and my friend has s3 which I used to make s3 compatible.I can support any devices if you guys can give me the required data
So now into the topic
In order to work with the script,you need the following:
A PC/Laptop with linux installed either as dualboot or in vm
A rooted Phone which supported by the script.
A usb cable
And of course you need your brain
Apart from the hardware,you will also need:
A stock rom from which you need to take the following:
cache.img
modem.bin
hidden.img
and a custom kernel(zImage) of you choice.(recovery.img and boot.img in case of s3)
Now download the script and do the following:
Extract ODIN-script.tar anywhere.
Run first_time.sh (Needed Only for the first time)
Put the above collected .img's,.bin and/or zImage inside ODIN-script directory
Connect your phone to PC/Laptop with usb debugging enabled.
Run the script and follow the instructions
Your Rom will be in the same directory in few mins
Note1:The Rom obtained by the above is not a full wipe rom.If you need to make it full wipe(factory reset),you need aditional empty data.img(for note/s2) or userdata.img(s3).I will upload data.img for Note.It "may" work on s2 too.But I havent tested.so its on your own risk
S3 users,I'm sorry I can help you .Because I dont know the size of /data partition to make an empty image.
Note2:You can always flash the rom with .pit and repartition.I have always used .pit to flash my rom.But still you are at your own risk.
Disclaimer:Do this at your own risk!!!I'm not responsible if you brick your phone.(Though you cannot if you do everything correctly )
Download link and changelog on next post.
And finally if you like my project and if you think you need to support me for future updates on this,Please do donate .And do not copy/edit/alter this work without my permission!!!
Download Links and changelogs
Changelog for v1:
Code:
[LIST]
[*]Initial release
[/LIST];)
Changelog for v2:
Code:
[LIST]
[*]Cleaned the code and redone entirely
[*]Added support for preload for some devices
[*]bug fixes
[/LIST]
Thanks to:
1.As-I9000 for zlibs and first_time.sh
vijai2011 said:
Reserved
Click to expand...
Click to collapse
Reserved!!!
really awesome...going to try now and let you know the feedback...
Ok...Thats good...Just an update...Dont add cache.img for now...It takes forever in recovery to flash....Found the issue and working on a fix
vijai2011 said:
Ok...Thats good...Just an update...Dont add cache.img for now...It takes forever in recovery to flash....Found the issue and working on a fix
Click to expand...
Click to collapse
thank you and i was about to test and i will refrain from doing that till you release the fix!
grgsiocl said:
thank you and i was about to test and i will refrain from doing that till you release the fix!
Click to expand...
Click to collapse
Hey...You can try it without cache.img as long as you have csc within you /system
But still if you have added cache.img,it will boot but only with couple of reboots and a looooong time in recovery
vijai2011 said:
Hey fellas!!!
Note1:The Rom obtained by the above is not a full wipe rom.If you need to make it full wipe(factory reset),you need aditional empty data.img(for note/s2) or userdata.img(s3).I will upload data.img for Note.It "may" work on s2 too.But I havent tested.so its on your own risk
[/COLOR]
Click to expand...
Click to collapse
If you needed FULL WIPE DATA - FACTORY RESET, you need to put the image cache file with the command wipe data...
as i9000 said:
If you needed FULL WIPE DATA - FACTORY RESET, you need to put the image cache file with the command wipe data...
Click to expand...
Click to collapse
Nope...instead I have added a empty data.img It will wipe off data...But didn't make it for s3 because I have heard s3 has /data and /sdcard combined.So if I make one for s3,it will wipe sdcard too.But need a confirmation on this
And I have fixed recovery issue too in v2 and it should be fine now.
Finally had a look on your script too.It also looks good.good job.nice work .May be we two can work together to make a kitchen???
Sent from my GT-N7000 using xda app-developers app
I used your script as guiding for customizing my own odin rom.
- I untarred my firmware.tar.md5
- $ simg2img system.img.ext4 system.raw
- $ sudo mount -t ext4 -o loop system.raw /tmp
I didn't change a thing and then repacked it
- make_ext4fs -s -l 512M -a system newsystem.img.ext4 /tmp
- chown 1000:1000 newsystem.img.ext4
- packed everything with $tar -H ustar -cvf out.tar *.img.* fat.bin
- signed the package md5sum -t out.tar >> out.tar
- mv out.tar out.tar.md5
I flashed it, had no problems, but after the flashing i see "failed to mount /system (invalid argument)
And as my system partition doesn't get mounted, i cant startup my phone.
Does anyone have a clue on what i could be doing wrong?
1bymany said:
I used your script as guiding for customizing my own odin rom.
- I untarred my firmware.tar.md5
- $ simg2img system.img.ext4 system.raw
- $ sudo mount -t ext4 -o loop system.raw /tmp
I didn't change a thing and then repacked it
- make_ext4fs -s -l 512M -a system newsystem.img.ext4 /tmp
- chown 1000:1000 newsystem.img.ext4
- packed everything with $tar -H ustar -cvf out.tar *.img.* fat.bin
- signed the package md5sum -t out.tar >> out.tar
- mv out.tar out.tar.md5
I flashed it, had no problems, but after the flashing i see "failed to mount /system (invalid argument)
And as my system partition doesn't get mounted, i cant startup my phone.
Does anyone have a clue on what i could be doing wrong?
Click to expand...
Click to collapse
If you did exactly what you posted,then,
1. You should not have got system.img.ext4 but system.img and so simg2img is simg2img system.img system.img.ext
2./temp in mount command would be your temp filesystem where system files are stored.Use a relative path like TempDir in your PWD
3. Are you sure the make_ext4fs line is correct?You said you used my script as reference and I have never used that command at all.Its like:
Code:
sudo ./mkuserimg.sh -s TempDir factoryfs.img ext4 ./temp 893386752B
(in mb is also fine)
where the numbers indicate the size of system partition in Bytes.Be sure to cd to ext4_utils before executing this command and should always be run as sudo as the mount is done as sudo.And donot include .ext4 at the end.Use just img.Works better.
4.again...chown should be sudo.As the img is owned by root and so you cannot chown it with basic user permissions.Simple user hierarchy
5.You did a blunder here in tar command if you put the original system.img and the newly packed img in the same directory.As the command will include all .img's which we donot want.
vijai2011 said:
If you did exactly what you posted,then,
1. You should not have got system.img.ext4 but system.img and so simg2img is simg2img system.img system.img.ext
2./temp in mount command would be your temp filesystem where system files are stored.Use a relative path like TempDir in your PWD
3. Are you sure the make_ext4fs line is correct?You said you used my script as reference and I have never used that command at all.Its like:
Code:
sudo ./mkuserimg.sh -s TempDir factoryfs.img ext4 ./temp 893386752B
(in mb is also fine)
where the numbers indicate the size of system partition in Bytes.Be sure to cd to ext4_utils before executing this command and should always be run as sudo as the mount is done as sudo.And donot include .ext4 at the end.Use just img.Works better.
4.again...chown should be sudo.As the img is owned by root and so you cannot chown it with basic user permissions.Simple user hierarchy
5.You did a blunder here in tar command if you put the original system.img and the newly packed img in the same directory.As the command will include all .img's which we donot want.
Click to expand...
Click to collapse
First of all, thanks for the reply.
second:
1. My phone is not rooted yet, it's a GT-S6500D aka Samsung galaxy tab. So I used a firmware.tar.md5 (that i have flashed to test and works)
and in this firmware.tar.md5 i have following files: boot.img, cache.img.ext4, fat.bin, hidden.img.ext4, recovery.img and system.img.ext4
So the system.img.ext4 wasn't a typo and the system.raw is just an arbitrary name i have chosen.
2. I don't get the mountpoint. Is this the mountpoint on the phone? of on my computer?
3. I have analysed the mkuserimg.sh script, and it is just a wrapper that flips the argument order. I have no clue why they made it..
So i doubt my problem would be in this line, but I will try, as i don't know what else can go wrong
4. chown should indeed be sudo, no doubt about that I just didn't type it here
5. I skipped this step a bit in the explanation, but i made the sure the directory only concluded the necessary files, naming the original files from step 1 or modified files.
6. I don't know if this could help, but if i unpack for example system.img.ext4 and repack it again, the new file will be bigger then the original one.. I was thinking maybe Samsung adjusted some things, but maybe i need some more arguments in my make_ext4fs command..
grtz
Fixed it!
The problem was that i was using a size of 512M without knowing where it came from.
I flashed the original firmware back to the phone, did a
Code:
adb shell "df /system "
to know what size my img needed to be. In my case it was a total size of 492M. So i used following command to make my system.img.ext4
Code:
make_ext4fs -s -l 492M -a system system.img.ext4 /system
Now trying to pack my own kernel in the boot.img
thanks for the support!
1bymany said:
Fixed it!
The problem was that i was using a size of 512M without knowing where it came from.
I flashed the original firmware back to the phone, did a
Code:
adb shell "df /system "
to know what size my img needed to be. In my case it was a total size of 492M. So i used following command to make my system.img.ext4
Code:
make_ext4fs -s -l 492M -a system system.img.ext4 /system
Now trying to pack my own kernel in the boot.img
thanks for the support!
Click to expand...
Click to collapse
Sorry for the late response .got a little busy.Happy that you solved it .Just an hint,you can use -h to see the size better readable by humans(In M and G) in df command incase you find its in kb or B
Sent from my GT-N7000 using xda app-developers app
Updated to v2
vijai2011 said:
Updated to v2
Click to expand...
Click to collapse
thanks man
I have update.img from venor of my tablet. I would like to make a custom rom and later CyanogenMod. At this moment I need to extract boot.img form update.img
mkimage -l update.img displays:
mkimage: Bad Magic Number: "update.img" is no valid image
Image Type : Davinci UBL Boot Image
UBL magic : 57464b52
Entry Point: 00010066
nr of pages: 00000401
start block: 07dd0105
start page : 290e1201
Any idea?
You can download update.img from:
https://mega.co.nz/#!XFExEDBL!OkPfQwWDp0JDzRHIg4TZQk6lt3EwEJiDfR2IyOE6p_4
mafamafa said:
I have update.img from venor of my tablet. I would like to make a custom rom and later CyanogenMod. At this moment I need to extract boot.img form update.img
mkimage -l update.img displays:
mkimage: Bad Magic Number: "update.img" is no valid image
Image Type : Davinci UBL Boot Image
UBL magic : 57464b52
Entry Point: 00010066
nr of pages: 00000401
start block: 07dd0105
start page : 290e1201
Any idea?
You can download update.img from:
https://mega.co.nz/#!XFExEDBL!OkPfQwWDp0JDzRHIg4TZQk6lt3EwEJiDfR2IyOE6p_4
Click to expand...
Click to collapse
try using ext2explore...
ext2explore didn’t show anything
mr.harsh said:
try using ext2explore...
Click to expand...
Click to collapse
Unfortunately ext2explore didn’t show anything. Any idea? Maybe somebody download the file I posted I mega.co.nz and check it?
unmkbootimg doing the job for you
mafamafa said:
Unfortunately ext2explore didn’t show anything. Any idea? Maybe somebody download the file I posted I mega.co.nz and check it?
Click to expand...
Click to collapse
There is programm called unmkbootimg. type:
unmkbootimg boot.img
will create zImage and initramfs.cpio.gz files in current directory. scripts/extract-ikconfig will give you config from kernel.
kaptorali said:
There is programm called unmkbootimg. type:
unmkbootimg boot.img
will create zImage and initramfs.cpio.gz files in current directory. scripts/extract-ikconfig will give you config from kernel.
Click to expand...
Click to collapse
Shoud I run it on my Tablet? Shoud I install something on my tablet?
mafamafa said:
Shoud I run it on my Tablet? Shoud I install something on my tablet?
Click to expand...
Click to collapse
If you have unpacked ROM and got yourromfolder/RFSFAT16_BOOT_00000000000 then all you need
>unmkbootimg yourromfolder/RFSFAT16_BOOT_00000000000
To get boot.img from tablet: install Term(terminal) (to tablet), run terminal, type:
>su
>busybox dd if=/dev/block/nandc of=/mnt/sdcard/boot.img
Copy boot.img from /mnt/sdcard/ (or other directory) to "extsd", insert to PC and run unmkbootimg
From adb shell (linux style):
>./adb start-server
In tablet turn on "usb adb debugging". Plug tablet to PC with usb. Run:
>./adb shell busybox dd if=/dev/block/nandc of=/mnt/sdcard/boot.img
>./adb pull /mnt/sdcard/boot.img boot.img
Run unmkbootimg.
mkimage -l update.img gives you header (first 64bites) of your boot.img - all right.
Also unmkbootimg type output for building (packing) new_boot.img!
mafamafa said:
Any idea?
Click to expand...
Click to collapse
$ dd if=update.img skip=1 bs=13155412 of=boot.img
I've updated unmkbootimg so it handles embedded boot images now. Download it and run it directly on your update.img
$ unmkbootimg update.img
unmkbootimg version 1.2 - Mikael Q Kuisma <[email protected]>
File update.img not a plain boot image, seeking for embedded image ... found!
Kernel size 8073252
Kernel address 0x60408000
Ramdisk size 6380372
Ramdisk address 0x62000000
Secondary size 0
Secondary address 0x60f00000
Kernel tags address 0x60088000
Flash page size 16384
Board name is ""
Command line ""
*** WARNING ****
This image is built using NON-standard mkbootimg!
OFF_KERNEL_ADDR is 0x00380100
OFF_RAMDISK_ADDR is 0x01F78100
OFF_SECOND_ADDR is 0x00E78100
Please modify mkbootimg.c using the above values to build your image.
****************
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 0x60087f00 --pagesize 16384 -o new_boot.img
---------------
$ ls
initramfs.cpio.gz update.img zImage
$
Click to expand...
Click to collapse
I'm used to install RemixOS manually on a HardDrive partition and using GRUB for multibooting with Ubuntu, Windows, etc. This time I found some trouble installing new Marshmallow based build. It seems like Jide started using Squashfs+lz4 compression on this build and shipped squashfs-tools with Ubuntu can't manage it.
For the ones who don't know what "manually installing" means:
1- Download RemixOS .zip
2- Extract .zip and mount ISO extracted
3- Copy all ISO contents to a new partition where RemixOS will be installed ~8GB or more
4- Uncompress system.sfs using unsquashfs tool (this will generate system.img)
5- Deleste system.sfs
6- Create "data" folder alongside the files extracted from ISO
7- Make new custom GRUB entry for RemixOS on the correct used partition
8- Boot RemixOS from multiboot GRUB
So the best and easy way to solve the unsquashing problem is to download squashfs-tools source and building it with lz4 support.
Here the steps:
1- We' are going to build squashfs with full support for every available compress method (lzo,lz4,lzma,gzip) so we need dev packages, just run:
Code:
sudo apt-get install liblzo2-dev liblzma-dev liblz4-dev
2- Create a working folder and download squashfs-tools source
3- Open terminal go to working folder and uncompress source:
Code:
tar -zxvf squashfs4.3.tar.gz
NOTE: if they release a new version you need to replace "4.3"
4- Go to source folder and open makefile for editing:
Code:
cd squashfs4.3/squashfs-tools
gedit Makefile
NOTE: if they release a new version you need to replace "4.3"
5- In te Makefile uncomment (erase "#") in the following lines:
#XZ_SUPPORT = 1
#LZO_SUPPORT = 1
#LZ4_SUPPORT = 1
#LZMA_XZ_SUPPORT = 1
6- Compile and Install:
Code:
make
sudo make install
If everything goes right you can now open a new terminal and unsquash every squashfs file you can find and of course new LZ4 compressed from RemixOS. I hope this result helpfull for anyone!
NOTE: If you are not interested in having some un/compress type you can avoid installing xxx-dev corresponding package and DO NOT comment corresponding line on Makefile.
what about on elementary Os?
lukss12 said:
I'm used to install RemixOS manually on a HardDrive partition and using GRUB for multibooting with Ubuntu, Windows, etc. This time I found some trouble installing new Marshmallow based build. It seems like Jide started using Squashfs+lz4 compression on this build and shipped squashfs-tools with Ubuntu can't manage it.
For the ones who don't know what "manually installing" means:
1- Download RemixOS .zip
2- Extract .zip and mount ISO extracted
3- Copy all ISO contents to a new partition where RemixOS will be installed ~8GB or more
4- Uncompress system.sfs using unsquashfs tool (this will generate system.img)
5- Deleste system.sfs
6- Create "data" folder alongside the files extracted from ISO
7- Make new custom GRUB entry for RemixOS on the correct used partition
8- Boot RemixOS from multiboot GRUB
So the best and easy way to solve the unsquashing problem is to download squashfs-tools source and building it with lz4 support.
Here the steps:
1- We' are going to build squashfs with full support for every available compress method (lzo,lz4,lzma,gzip) so we need dev packages, just run:
Code:
sudo apt-get install liblzo2-dev liblzma-dev liblz4-dev
2- Create a working folder and download squashfs-tools source
3- Open terminal go to working folder and uncompress source:
Code:
tar -zxvf squashfs4.3.tar.gz
NOTE: if they release a new version you need to replace "4.3"
4- Go to source folder and open makefile for editing:
Code:
cd squashfs4.3/squashfs-tools
gedit Makefile
NOTE: if they release a new version you need to replace "4.3"
5- In te Makefile uncomment (erase "#") in the following lines:
#XZ_SUPPORT = 1
#LZO_SUPPORT = 1
#LZ4_SUPPORT = 1
#LZMA_XZ_SUPPORT = 1
6- Compile and Install:
Code:
make
sudo make install
If everything goes right you can now open a new terminal and unsquash every squashfs file you can find and of course new LZ4 compressed from RemixOS. I hope this result helpfull for anyone!
NOTE: If you are not interested in having some un/compress type you can avoid installing xxx-dev corresponding package and DO NOT comment corresponding line on Makefile.
Click to expand...
Click to collapse
Could you upload the system.img?
kabelon said:
what about on elementary Os?
Click to expand...
Click to collapse
I have never used it, if you're asking if it will work to do the installation steps for RemixOS, well as it is Ubuntu based I think the answer probably is yes.
Orion116 said:
Could you upload the system.img?
Click to expand...
Click to collapse
I'm on a 1Mbit connection and system.img is 2,7GB so I'm not able to upload it. If you are on windows try to find squash-tools for windows with LZ4 support. If you're running Ubuntu do the steps I have mentioned it's easy an it takes no more than 15 minutes.
lukss12 said:
I'm on a 1Mbit connection and system.img is 2,7GB so I'm not able to upload it. If you are on windows try to find squash-tools for windows with LZ4 support. If you're running Ubuntu do the steps I have mentioned it's easy an it takes no more than 15 minutes.
Click to expand...
Click to collapse
The issue is I am on Manjaro, an arch based OS. I'll try something similar on manjaro
Orion116 said:
The issue is I am on Manjaro, an arch based OS. I'll try something similar on manjaro
Click to expand...
Click to collapse
Try the same thing I described but using pacman I think it will work. If you fail (but I doubt) I will upload the image for you. But please try to do it because it is a big effort for me to spend my poor connection a lot of hours uploading the image.
Edit: just focus on lz4 package
lukss12 said:
Try the same thing I described but using pacman I think it will work. If you fail (but I doubt) I will upload the image for you. But please try to do it because it is a big effort for me to spend my poor connection a lot of hours uploading the image.
Edit: just focus on lz4 package
Click to expand...
Click to collapse
Seems I didn't have to install the packages
---------- Post added at 11:22 PM ---------- Previous post was at 11:17 PM ----------
lukss12 said:
Try the same thing I described but using pacman I think it will work. If you fail (but I doubt) I will upload the image for you. But please try to do it because it is a big effort for me to spend my poor connection a lot of hours uploading the image.
Edit: just focus on lz4 package
Click to expand...
Click to collapse
I got a system.img :good: Now to remember how to set up the grub for it:cyclops:
Orion116 said:
Seems I didn't have to install the packages
---------- Post added at 11:22 PM ---------- Previous post was at 11:17 PM ----------
I got a system.img :good: Now to remember how to set up the grub for it:cyclops:
Click to expand...
Click to collapse
Great.
Add this to custom file in /etc/grub.d
Code:
menuentry "Remix-OS" {
set root='(hdx,y)'
linux kernel root=/dev/ram0 androidboot.hardware=remix_x86_64 androidboot.selinux=permissive quiet DATA=/data
initrd /android/initrd.img}
(hdx,y) makes reference to the partition where you are installing RemixOS, Generally it is (hd0,y) where 'y' is the number of the partition
This setup works if RemixOS files are on root folder of partition
Edit: I need to warn you that my PC hang on a black screen after Setup Wizard on first boot if you have this problem ask me for the workaround
I have it booting but no WiFi, rats. It worked in the last LP build.
lukss12 said:
I'm used to install RemixOS manually on a HardDrive partition and using GRUB for multibooting with Ubuntu, Windows, etc. This time I found some trouble installing new Marshmallow based build. It seems like Jide started using Squashfs+lz4 compression on this build and shipped squashfs-tools with Ubuntu can't manage it.
For the ones who don't know what "manually installing" means:
1- Download RemixOS .zip
2- Extract .zip and mount ISO extracted
3- Copy all ISO contents to a new partition where RemixOS will be installed ~8GB or more
4- Uncompress system.sfs using unsquashfs tool (this will generate system.img)
5- Deleste system.sfs
6- Create "data" folder alongside the files extracted from ISO
7- Make new custom GRUB entry for RemixOS on the correct used partition
8- Boot RemixOS from multiboot GRUB
Click to expand...
Click to collapse
You don't need to unpack the system.sfs if you want
to manually install this. i.e. you don't need #4 or #5; and can save ~1.5GB of space. On the other hand if you want system rw - then you need the ext4 .img [as well as modified initrd.img]; and they seem to have started using better grub configs by default; i.e. using search instead of setting root to a partition.
HypoTurtle said:
You don't need to unpack the system.sfs if you want
to manually install this. i.e. you don't need #4 or #5; and can save ~1.5GB of space. On the other hand if you want system rw - then you need the ext4 .img [as well as modified initrd.img]; and they seem to have started using better grub configs by default; i.e. using search instead of setting root to a partition.
Click to expand...
Click to collapse
I actual just copied the grub.cfg for resident mode from the iso proper and used grub customizer to add it to my triple booted laptop. To bad Boardcom wifi is shot though otherwise it is perfect.
And how to add it to GRUB menu?
gb_14 said:
And how to add it to GRUB menu?
Click to expand...
Click to collapse
You can copy grub.cfg from original ISO into your /boot directory like Orion16 did. Or just edit /etc/grub.d/custom file as I told him in a previous post and run "sudo update-grub"
HypoTurtle said:
You don't need to unpack the system.sfs if you want
to manually install this. i.e. you don't need #4 or #5; and can save ~1.5GB of space. On the other hand if you want system rw - then you need the ext4 .img [as well as modified initrd.img]; and they seem to have started using better grub configs by default; i.e. using search instead of setting root to a partition.
Click to expand...
Click to collapse
Yes androidx86 first test for system.sfs, then system.img and last for system folder. On androidx86 builds I was able to boot with system folder and it was so in first RemixOS builds but now it is not working anymore (RemixOS loops at boot). I think that having installed an OS means also having RW permission over system files but it's just an opinion.
About modified initrd.img you don't need to unpack system.sfs for this method. But currently there is no modified initrd.img for last RemixOS and I don't have the time to do it.
I NEED TO WARN EVERYONE: if you modify system files mounting system.img as RW future OTAs will refuse to install and you will need to replace your custom system with the original one if you want OTA update.
lukss12 said:
Yes androidx86 first test for system.sfs, then system.img and last for system folder. On androidx86 builds I was able to boot with system folder and it was so in first RemixOS builds but now it is not working anymore (RemixOS loops at boot). I think that having installed an OS means also having RW permission over system files but it's just an opinion.
About modified initrd.img you don't need to unpack system.sfs for this method. But currently there is no modified initrd.img for last RemixOS and I don't have the time to do it.
I NEED TO WARN EVERYONE: if you modify system files mounting system.img as RW future OTAs will refuse to install and you will need to replace your custom system with the original one if you want OTA update.
Click to expand...
Click to collapse
I have one posted here
But yea if you go the full way [if you're on ext4] and dump the system.img into a system folder; then you don't need to modify the initrd.img for rw.
I used #1 on Bash for Windows; [just wanted to check the uncompressed system file] so kudos for that
HypoTurtle said:
I have one posted here
But yea if you go the full way [if you're on ext4] and dump the system.img into a system folder; then you don't need to modify the initrd.img for rw.
I used #1 on Bash for Windows; [just wanted to check the uncompressed system file] so kudos for that
Click to expand...
Click to collapse
Good to have an initrd.img but is it RemixOS 3.x based?
About system dump on system folder, it was not working anymore with recent 2.x builds (I haven't tested it on 3.x).
Now RemixOS 3.x build comes with built in SU so I can remount RW system from Terminal or using ESFileExplorer (or similar one) and only need to have system.img for editing files within RemixOS. (I forgot I was using modified initrd.img to achieve this with system.img as you said you need to make system folder dump to edit files within RemixOS and without modified initrd.img)
But as I mentioned it will break OTA... So having an intrd.img is important.
Btw if you see anyone having trouble with new Jide Setup Wizard in 3.x, the fix is to delete /priv-app/JideSetupWizard from system.img or RemixOS will not pass welcome screen
(So no OTA for me until Jide fix this up for my PC)
lukss12 said:
Good to have an initrd.img but is it RemixOS 3.x based?
About system dump on system folder, it was not working anymore with recent 2.x builds (I haven't tested it on 3.x).
Now RemixOS 3.x build comes with built in SU so I can remount RW system from Terminal or using ESFileExplorer (or similar one) and only need to have system.img for editing files within RemixOS. But as I mentioned it will break OTA... So having an intrd.img is important.
Btw if you see anyone having trouble with new Jide Setup Wizard in 3.x, the fix is to delete /priv-app/JideSetupWizard from system.img or RemixOS will not pass welcome screen
(So no OTA for me until Jide fix this up for my PC)
Click to expand...
Click to collapse
Yea, that one is 3.x based. I have a simple script somewhere so that you could make your own [its a simple unpack; search for ro; replace with rw and repack].
And JSW - I just disabled the app [with pm disable com.jide.setupwizard] instead of removing it.
Still not sure how you are getting rw without a rw initrd.img; with RemixOS just because you have su doesn't mean you can remount rw afaik.
Code from stock initrd.img:
Code:
check_root()
{
local r
if [ "`dirname $1`" = "/dev" ]; then
[ -e $1 ] || return 1
blk=`basename $1`
[ ! -e /dev/block/$blk ] && ln $1 /dev/block
dev=/dev/block/$blk
r=$(ls /sys/block/$blk/removable /sys/block/*/$blk/../removable 2>/dev/null)
[ -n "$r" ] && r=$(cat $r) || r=0
else
dev=$1
fi
try_mount ro $dev /mnt || return 1
if [ -n "$iso" -a -e /mnt/$iso ]; then
mount --move /mnt /iso
mkdir /mnt/iso
mount -o loop /iso/$iso /mnt/iso
SRC=iso
elif [ ! -e /mnt/$SRC/ramdisk.img ]; then
return 1
fi
removable=$r
zcat /mnt/$SRC/ramdisk.img | cpio -id > /dev/null
[ -n "$SYSTEM" ] && blk=`basename $SYSTEM` || blk=
if [ -b "/dev/$blk" ]; then
[ ! -e /dev/block/$blk ] && ln /dev/$blk /dev/block
mount -o ro /dev/block/$blk system
elif [ -e /mnt/$SRC/system.sfs ]; then
mount -o loop /mnt/$SRC/system.sfs /sfs
mount -o loop,ro /sfs/system.img system
mount_system_dev_img_if_necessary
elif [ -e /mnt/$SRC/system.img ]; then
mount -o loop,ro /mnt/$SRC/system.img system
elif [ -d /mnt/$SRC/system ]; then
mount --bind /mnt/$SRC/system system
else
rm -rf *
return 1
fi
mkdir mnt
if [ -n "$DEBUG" ]; then
echo " found at $1"
fi
rm /sbin/mke2fs
hash -r
}
HypoTurtle said:
Yea, that one is 3.x based. I have a simple script somewhere so that you could make your own [its a simple unpack; search for ro; replace with rw and repack].
And JSW - I just disabled the app [with pm disable com.jide.setupwizard] instead of removing it.
Still not sure how you are getting rw without a rw initrd.img; with RemixOS just because you have su doesn't mean you can remount rw afaik.
Code from stock initrd.img:
Click to expand...
Click to collapse
You are right!!! I was using a modified initrd for having rw on 2.x and I didn't remember . Will try pm disable thanks :good:
lukss12 said:
You can copy grub.cfg from original ISO into your /boot directory like Orion16 did. Or just edit /etc/grub.d/custom file as I told him in a previous post and run "sudo update-grub"
Click to expand...
Click to collapse
Thanks
Hello
I am working with a Nanopi Fire3 board. I need to change the boot logo and boot animation.
With this Android Lollipop :
112.124.9.243/dvdfiles/S5P6818/images-for-eflasher/android-lollipop-images.tgz
Click to expand...
Click to collapse
If I unpack with the following method, the new image has a completely different size and does not boot.
Code:
apt install android-tools-fsutils
simg2img rootfs.img r.img
mount -t ext4 -o loop r.img /mnt
… To Change Something …
umount /mnt
img2simg r.img rootfs.img
I have tried to root the device, no tool found online works.
I have tried to unpack/repack, no tool found online works.
Tools like mkbootimg just copies the img file (it doesn't extract anything)
I am also trying to compile android completely, and it fails in the middle of the build process.
Would you have any advice please? I have run out of options
Thank you :good: