LG G4 fails to complete LOS 14.1 boot after battery drained to zero [Fixed] - G4 Q&A, Help & Troubleshooting

The battery of a rooted, UsUed LG G4 running LineageOS 14.1 was accidentally allowed to drain to zero. After re-charging above 50%, the device failed to boot. The LOS boot screen "bubble on a string" animation would continue indefinitely.
The phone still booted to TWRP, download mode, and fastboot mode.
Originally, it was suspected that this was ILAPO. However, this suspicion was incorrect.
After extensive work creating a boot sector that would allow logging and a ton of help from @steadfasterX, it was discovered that various files in /data/system had been corrupted and had sizes of zero. Android would try to read values from these files, fail, and repeat.
First, a full TWRP backup of the phone was made and copied off-device. Then, I made a second backup of /data/system. Next, I deleted the following zero-byte files from /data/system using TWRP (or ADB after launching TWRP).
packages.list
packages.xml
profiles.xml
netpolicy.xml
notification_policy.xml
If this doesn't work, I would have considered deleting other zero-byte files in /data/system. I used "ls -laS" to get a size-ordered list of files in my current directory.
After a reboot, android re-created the files and booted to the lockscreen.
All of the apps in /data/data had already been cleared. Otherwise, Android would probably have choked on the differences between the user IDs that it wanted to assign to apps and the ownership of the various app folders.
The following links suggest ways to restore some apps from previously created backups
GitHub - joshuabragge/twrp-manual-restore: Automate individual app restores from an android TWRP backup
Automate individual app restores from an android TWRP backup - GitHub - joshuabragge/twrp-manual-restore: Automate individual app restores from an android TWRP backup
github.com
https://www.semipol.de/posts/2016/07/android-manually-restoring-apps-from-a-twrp-backup/
(Permanent archive: https://web.archive.org/web/2019083.../android-restoring-apps-from-twrp-backup.html)
There is no warranty on this solution. It was a makeshift effort created by an amateur. If you choose to duplicate it, you do so at your own risk. You may permanently destroy your phone.
Old post below:
I'm trying to understand whether a particular G4 (H815) has ILAPO. Its been sneezing, has a sore throat, and now can't taste anything^H^H oops, I mean:
- Previously, the phone would get hot during use.
- The phone has been UsUed.
- The battery was accidentally allowed to discharge to zero.
- After the battery was recharged, the phone was unable to boot past the Lineageos "bubble on a string" animation. The animation simply continues forever.
- The phone can boot to TWRP, fasboot, download mode, etc.
Attempts to fix:
- Tried renaming /sdcard/Android to /sdcard/Android.old but this had no effect.
- Tried clearing cache and dalvik cache but this had no effect
- (NEW) Tried attaching to computer and launching "adb logcat" during animation. Device is never found. If I remember correctly, "USB debugging" was off when the device died. (ADB does work in TWRP.)
- (NEW) Tried creating a custom 4-core (2 core for boot) boot image using the instructions here https://forum.xda-developers.com/t/...tom-x-cores-boot-image-ilapo-tempfix.3718389/ and used "fastboot flash boot boot.img" to flash it. This doesn't seem to work.
-- If I reboot into TWRP after a long period of waiting for the lineageos splash screen, I get a CPU temperature of 46 C. I don't know what temperature was generated in the same situation the modified boot image was installed.
Most of the info on ILAPO suggests that phones with it can't get past the LG logo. That is not the case here. Is this ILAPO or something different? Does anyone have ideas as to what might be an appropriate fix?
Is it possible to retrieve boot logs using TWRP in order to figure out when/where/why the boot hangs?

electricfield said:
I'm trying to understand whether a particular G4 (H815) has ILAPO. Its been sneezing, has a sore throat, and now can't taste anything^H^H oops, I mean:
- Previously, the phone would get hot during use.
- The phone has been UsUed.
- The battery was accidentally allowed to discharge to zero.
- After the battery was recharged, the phone was unable to boot past the Lineageos "bubble on a string" animation. The animation simply continues forever.
- The phone can boot to TWRP, fasboot, download mode, etc.
Attempts to fix:
- Tried renaming /sdcard/Android to /sdcard/Android.old but this had no effect.
- Tried clearing cache and dalvik cache but this had no effect
- (NEW) Tried attaching to computer and launching "adb logcat" during animation. Device is never found. If I remember correctly, "USB debugging" was off when the device died. (ADB does work in TWRP.)
- (NEW) Tried creating a custom 4-core (2 core for boot) boot image using the instructions here https://forum.xda-developers.com/t/...tom-x-cores-boot-image-ilapo-tempfix.3718389/ and used "fastboot flash boot boot.img" to flash it. This doesn't seem to work.
-- If I reboot into TWRP after a long period of waiting for the lineageos splash screen, I get a CPU temperature of 46 C. I don't know what temperature was generated in the same situation the modified boot image was installed.
Most of the info on ILAPO suggests that phones with it can't get past the LG logo. That is not the case here. Is this ILAPO or something different? Does anyone have ideas as to what might be an appropriate fix?
Is it possible to retrieve boot logs using TWRP in order to figure out when/where/why the boot hangs?
Click to expand...
Click to collapse
Sounds like the ilapo. Is the battery charged now? I don't know which LOS version you have installed but if you use mine:
follow FAQ #7 of my LOS thread

steadfasterX said:
Sounds like the ilapo. Is the battery charged now? I don't know which LOS version you have installed but if you use mine:
follow FAQ #7 of my LOS thread
Click to expand...
Click to collapse
Thank you for your reply. You seem to know more about G4 issues than anyone. I really appreciate your help.
The battery is charged now.
Unfortunately, I am using the microg version of LOS 14.1, rather than your 16.0.
I tried following the instructions in your FAQ #7, but I can't do step 1 (boot android). The only way for me to exit the bootloop is by removing the battery. There is no "debug" in /cache after I mount cache in TWRP.
I also looked at FAQ #1. ADB never finishes waiting for the device. In fact "lsusb" doesn't show the phone during OS boot (ADB is fine when TWRP is loaded).
Any other ideas?

electricfield said:
Thank you for your reply. You seem to know more about G4 issues than anyone. I really appreciate your help.
The battery is charged now.
Unfortunately, I am using the microg version of LOS 14.1, rather than your 16.0.
I tried following the instructions in your FAQ #7, but I can't do step 1 (boot android). The only way for me to exit the bootloop is by removing the battery. There is no "debug" in /cache after I mount cache in TWRP.
I also looked at FAQ #1. ADB never finishes waiting for the device. In fact "lsusb" doesn't show the phone during OS boot (ADB is fine when TWRP is loaded).
Any other ideas?
Click to expand...
Click to collapse
As written in my mentioned FAQ taken battery out is needed in your case. Step 2 iirc.
If you dont use my LOS then no way. The cache/debug is something I've added and no one else has.
Option1:
You can just flash my LOS 16 or /e/ ROM (take a full backup before in TWRP) and use that for debugging your current issue. Why using microg btw? /e/ is great
Option2:
The other option would be pulling the boot img of your current LOS (in TWRP: adb pull /dev/block/bootdevice/by-name/boot ) and rebuilding it as insecure (i.e. usb debug on and adb root ) but if you never did that before it it will be hard i guess. AiK might work here or using mAid which includes bootimgtool.
Option3:
Also you can attach that boot img here and if i ever find the time i can do option2 for you but don't expext that this happens soon .

Thank you again for your help.
I'm a little afraid that installing a new & different ROM will increase the level of complexity. I'll do it if I must, though.
I started looking at option #2. Retrieving the boot image was fine, but unpacking presents a problem.
$ ./unpack-bootimg.sh boot.img.original
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.
Is there a guide anywhere?

electricfield said:
Thank you again for your help.
I'm a little afraid that installing a new & different ROM will increase the level of complexity. I'll do it if I must, though.
I started looking at option #2. Retrieving the boot image was fine, but unpacking presents a problem.
$ ./unpack-bootimg.sh boot.img.original
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.
Is there a guide anywhere?
Click to expand...
Click to collapse
thousands.. But the problem is that our device is sensitive when it comes to packaging the boot.img again. Bootimgtool is working in 9 of 10 times though.
Boot mAid . Open a terminal. Type bootimgtool --help .important is to use "-v qcom". Then extract the ramdisk with gzip and cpio, then modding the default.prop to make it insecure , then using gzip and cpio again to rebuild the ramdisk, finally using bootimgtool to construct the boot.img again. Sounds harder than it is but i have no access to my pc until monday so i cannot give all the needed cmds atm. There are plenty of guides out there and tools ofc which allow unpack,repack etc. That's why i mentioned AIK which does exactly the above but it fails sometimes to build a correct working boot.img.
So my suggestion is try your luck with one of the tools or wait until I've access to my pc. Consider joining my TG group then for easier support (see my sig)

steadfasterX said:
thousands.. But the problem is that our device is sensitive when it comes to packaging the boot.img again. Bootimgtool is working in 9 of 10 times though.
Boot mAid . Open a terminal. Type bootimgtool --help .important is to use "-v qcom". Then extract the ramdisk with gzip and cpio, then modding the default.prop to make it insecure , then using gzip and cpio again to rebuild the ramdisk, finally using bootimgtool to construct the boot.img again. Sounds harder than it is but i have no access to my pc until monday so i cannot give all the needed cmds atm. There are plenty of guides out there and tools ofc which allow unpack,repack etc. That's why i mentioned AIK which does exactly the above but it fails sometimes to build a correct working boot.img.
So my suggestion is try your luck with one of the tools or wait until I've access to my pc. Consider joining my TG group then for easier support (see my sig)
Click to expand...
Click to collapse
Thank you once again. I'm really impressed by how much help you have been able to give so far.
Unfortunately, I have no phone with which to join the Telegram group.
I made the modified boot image, but adb is still unable to speak to the phone during boot. I note that lsusb does not show the phone during boot -- maybe the system hangs before USB is activated. However, I could have made the boot image incorrectly.
Here is what I did:
[[email protected] extract]$ bootimgtool -i boot
Image size: 41943040
Page size: 4096
Kernel size: 22456976
Ramdisk size: 1672742
Second stage size: 0
Device tree size: 0
Kernel load address: 0x00008000
Ramdisk load address: 0x01000000
Second stage load address: 0x00f00000
Device tree load address: 0x00000000
Tags load address: 0x00000100
Product name:
Command line: maxcpus=4 boot_cpus=0-1 console=ttyHSL0,115200,n8 androidboot.console=ttyHSL0 androidboot.hardware=qcom user_debug=31 ehci-hcd.park=3 lpm_levels.sleep_disabled=1 msm_rtb.filter=0x37 boot_cpus=0-1 buildvariant=userdebug
[[email protected] extract]$ bootimgtool -x boot -v qcom
[[email protected] extract]$ gunzip ramdisk
[[email protected] ex]$ cpio -i < ../ramdisk
In default.prop, I changed:
ro.adb.secure=0
ro.secure=0
security.perf_harden=0
ro.debuggable=0
persist.sys.usb.config=mtp,adb
In default.prop, I added:
persist.service.adb.enable=1
persist.service.debuggable=1
[[email protected] ex]$ find > /tmp/filelist
[[email protected] ex]$ cpio -o < /tmp/filelist > ../ramdisk.modified
This produces
-rw-r--r-- 1 android users 4166400 Jan 2 17:29 ramdisk.gunzip.original
-rw-r--r-- 1 android users 4162048 Jan 2 17:31 ramdisk.modified
-rw-r--r-- 1 android users 1672742 Jan 2 17:16 ramdisk.img.original
I don't understand why the "modified" gunzipped file is slightly smaller than the original.
[[email protected] extract]$ mv ramdisk.modified.gz ramdisk.img
[[email protected] extract]$ cp boot boot.original
[[email protected] extract]$ bootimgtool -v qcom -c boot
Overwrite 'boot'? [y/N] y
-rw-r--r-- 1 android users 25370624 Jan 2 17:38 boot
-rw-r--r-- 1 android users 41943040 Jan 2 17:37 boot.original
I am wary because I don't understand why the new file is so much smaller than the original. However, I decided to proceed. Uploaded modified boot to /sdcard/boot.modified
Inside adb:
/dev/block/platform/soc.0/f9824900.sdhci/by-name # ls -al boot
lrwxrwxrwx 1 root root 21 Jan 1 04:16 boot -> /dev/block/mmcblk0p38
/dev/block/platform/soc.0/f9824900.sdhci/by-name # cp /sdcard/boot.modified /dev/block/mmcblk0p38
Plugged in device. On computer "adb wait-for-device". Reboot device.
Unfortunately, no action from adb.

electricfield said:
Thank you once again. I'm really impressed by how much help you have been able to give so far.
Unfortunately, I have no phone with which to join the Telegram group.
I made the modified boot image, but adb is still unable to speak to the phone during boot. I note that lsusb does not show the phone during boot -- maybe the system hangs before USB is activated. However, I could have made the boot image incorrectly.
Here is what I did:
[[email protected] extract]$ bootimgtool -i boot
Image size: 41943040
Page size: 4096
Kernel size: 22456976
Ramdisk size: 1672742
Second stage size: 0
Device tree size: 0
Kernel load address: 0x00008000
Ramdisk load address: 0x01000000
Second stage load address: 0x00f00000
Device tree load address: 0x00000000
Tags load address: 0x00000100
Product name:
Command line: maxcpus=4 boot_cpus=0-1 console=ttyHSL0,115200,n8 androidboot.console=ttyHSL0 androidboot.hardware=qcom user_debug=31 ehci-hcd.park=3 lpm_levels.sleep_disabled=1 msm_rtb.filter=0x37 boot_cpus=0-1 buildvariant=userdebug
[[email protected] extract]$ bootimgtool -x boot -v qcom
[[email protected] extract]$ gunzip ramdisk
[[email protected] ex]$ cpio -i < ../ramdisk
In default.prop, I changed:
ro.adb.secure=0
ro.secure=0
security.perf_harden=0
ro.debuggable=0
persist.sys.usb.config=mtp,adb
In default.prop, I added:
persist.service.adb.enable=1
persist.service.debuggable=1
[[email protected] ex]$ find > /tmp/filelist
[[email protected] ex]$ cpio -o < /tmp/filelist > ../ramdisk.modified
This produces
-rw-r--r-- 1 android users 4166400 Jan 2 17:29 ramdisk.gunzip.original
-rw-r--r-- 1 android users 4162048 Jan 2 17:31 ramdisk.modified
-rw-r--r-- 1 android users 1672742 Jan 2 17:16 ramdisk.img.original
I don't understand why the "modified" gunzipped file is slightly smaller than the original.
[[email protected] extract]$ mv ramdisk.modified.gz ramdisk.img
[[email protected] extract]$ cp boot boot.original
[[email protected] extract]$ bootimgtool -v qcom -c boot
Overwrite 'boot'? [y/N] y
-rw-r--r-- 1 android users 25370624 Jan 2 17:38 boot
-rw-r--r-- 1 android users 41943040 Jan 2 17:37 boot.original
I am wary because I don't understand why the new file is so much smaller than the original. However, I decided to proceed. Uploaded modified boot to /sdcard/boot.modified
Inside adb:
/dev/block/platform/soc.0/f9824900.sdhci/by-name # ls -al boot
lrwxrwxrwx 1 root root 21 Jan 1 04:16 boot -> /dev/block/mmcblk0p38
/dev/block/platform/soc.0/f9824900.sdhci/by-name # cp /sdcard/boot.modified /dev/block/mmcblk0p38
Plugged in device. On computer "adb wait-for-device". Reboot device.
Unfortunately, no action from adb.
Click to expand...
Click to collapse
Ok i haven't followed every step bc I'm in half sleep mode already but you did one step wrong : you cant use cp like you did to copy the boot img. Either use the IMG button within TWRP flash menu or use fastboot flash boot boot.img to actually flash the modded boot img

Thank you, once again.
I think that something must be wrong with the boot image.
After "fastboot flash boot boot.modified", I get a blue light. The screen is blank with a cursor in the upper-left hand corner.
"fastboot flash boot boot.original" restores it to its previous state. i.e., it gets to the first lineageos splash screen bubble.
I'm suspicious of the difference between the file sizes of the original and modified boot images.

electricfield said:
Thank you, once again.
I think that something must be wrong with the boot image.
After "fastboot flash boot boot.modified", I get a blue light. The screen is blank with a cursor in the upper-left hand corner.
"fastboot flash boot boot.original" restores it to its previous state. i.e., it gets to the first lineageos splash screen bubble.
I'm suspicious of the difference between the file sizes of the original and modified boot images.
Click to expand...
Click to collapse
Ignore the size diff. That's bc of diff compressing tools but does not matter. Your cpio cmd is unusual . Cpio has switches to create directories and that is not used in yours above . Thats likely the reason why it does not boot at all. Again sorry that i can't help better atm but without my pc..

Thanks.
I changed the ramdisk extraction command to:
gzip -dc ../ramdisk.img | cpio -imd
and the creation command to:
find . ! -name . | LC_ALL=C sort | cpio -o -H newc -R root:root | gzip > ../new-boot.img-ramdisk.gz
Bootimgtool then produced a boot image that booted. After fastboot flash, the device is in the same state as before (splash screen).
Unfortunately, "adb wait-for-device" produces nothing. "lsusb" does not show the phone.
Can you confirm the lines to change in default.prop?
In default.prop, I changed:
ro.adb.secure=0
ro.secure=0
security.perf_harden=0
ro.debuggable=0
persist.sys.usb.config=mtp,adb
I added:
persist.service.adb.enable=1
persist.service.debuggable=1

electricfield said:
Thanks.
I changed the ramdisk extraction command to:
gzip -dc ../ramdisk.img | cpio -imd
and the creation command to:
find . ! -name . | LC_ALL=C sort | cpio -o -H newc -R root:root | gzip > ../new-boot.img-ramdisk.gz
Bootimgtool then produced a boot image that booted. After fastboot flash, the device is in the same state as before (splash screen).
Unfortunately, "adb wait-for-device" produces nothing. "lsusb" does not show the phone.
Can you confirm the lines to change in default.prop?
In default.prop, I changed:
ro.adb.secure=0
ro.secure=0
security.perf_harden=0
ro.debuggable=0
persist.sys.usb.config=mtp,adb
I added:
persist.service.adb.enable=1
persist.service.debuggable=1
Click to expand...
Click to collapse
ro.debuggable=1 is better (allows adb root)
security.perf_harden shouldn't be added (or.changed if it was there)
Rest looks ok. At least as long as you really changed these values directly or added them at the top (ro. values can be set only once)
Otherwise you should wait until tomorrow then i can share a 100% working way

electricfield said:
Thanks.
I changed the ramdisk extraction command to:
gzip -dc ../ramdisk.img | cpio -imd
and the creation command to:
find . ! -name . | LC_ALL=C sort | cpio -o -H newc -R root:root | gzip > ../new-boot.img-ramdisk.gz
Bootimgtool then produced a boot image that booted. After fastboot flash, the device is in the same state as before (splash screen).
Unfortunately, "adb wait-for-device" produces nothing. "lsusb" does not show the phone.
Can you confirm the lines to change in default.prop?
In default.prop, I changed:
ro.adb.secure=0
ro.secure=0
security.perf_harden=0
ro.debuggable=0
persist.sys.usb.config=mtp,adb
I added:
persist.service.adb.enable=1
persist.service.debuggable=1
Click to expand...
Click to collapse
Oh wait! Pls share the bootimgtool command you are using to create the new boot.img

Thank you, again.
The bootimgtool command is the same one as I used before (no change). Before running it, I renamed the new ramdisk to ramdisk.img.
bootimgtool -v qcom -c boot.modified3
Followed by bringing the phone into fastboot mode and running
fastboot flash boot boot.modified3
The phone boots to the lineageos splash screen but no response to "adb wait-for-device".
I'll try ro.debuggable=1 and get rid of security.perf_harden in a few minutes, but I wonder if they are unlikely to change anything given that the device does not show up in (linux) lsusb.

electricfield said:
Thank you, again.
The bootimgtool command is the same one as I used before (no change). Before running it, I renamed the new ramdisk to ramdisk.img.
bootimgtool -v qcom -c boot.modified3
Followed by bringing the phone into fastboot mode and running
fastboot flash boot boot.modified3
The phone boots to the lineageos splash screen but no response to "adb wait-for-device".
I'll try ro.debuggable=1 and get rid of security.perf_harden in a few minutes, but I wonder if they are unlikely to change anything given that the device does not show up in (linux) lsusb.
Click to expand...
Click to collapse
That wont change anything if adb does not come up. Just for completeness.
Ok so if you renamed it to ramdisk.img then all.good that was the thing i had in mind (that you didn't and not.used the -r switch). Well ok then without my pc the only thing i can think of might be the USB cable but thats very unlikely

Thanks again for your help.
The boot image that was flashed is definitely the correct one. I extracted it to another folder and checked it before flashing.
I re-made the boot image, but the result is the same (no adb, no device in lsusb).
What "-r switch" are you referring to in your previous message?
The USB cable works fine for ADB in TWRP, so I doubt it is the problem.

electricfield said:
Thanks again for your help.
The boot image that was flashed is definitely the correct one. I extracted it to another folder and checked it before flashing.
I re-made the boot image, but the result is the same (no adb, no device in lsusb).
What "-r switch" are you referring to in your previous message?
The USB cable works fine for ADB in TWRP, so I doubt it is the problem.
Click to expand...
Click to collapse
The -r (iirc) switch was related to bootimgtool. That way you can choose your newly created ramdisk.img but when you renamed it to ramdisk.img it works without.

Thanks.
I would deeply appreciate if you were able to guide me in making the boot image correctly when you have your computer on Monday.
On the other hand, if this method won't work, its best if I know that so that I can try the next thing....

electricfield said:
Thanks.
I would deeply appreciate if you were able to guide me in making the boot image correctly when you have your computer on Monday.
On the other hand, if this method won't work, its best if I know that so that I can try the next thing....
Click to expand...
Click to collapse
ok here you go, this must be added /changed in default.prop:
Code:
ro.adb.secure=0
ro.secure=0
ro.debuggable=1
persist.service.adb.enable=1
persist.service.debuggable=1
persist.sys.usb.config=adb
thumbs pressed

Thank you.
I rebuilt the boot image with these entries, but "adb wait-for-device" still does not work during boot.
Any other ideas?

Related

Why don't my boot.img files boot?

Ok so I customized a boot.img (init.rc file) and repacked it using mkbootfs and mkbootimg. For the life of me, I can't get these boot imgs to boot. Any ideas why? The same exact stuff worked fine on my Hero.
chuckhriczko said:
Ok so I customized a boot.img (init.rc file) and repacked it using mkbootfs and mkbootimg. For the life of me, I can't get these boot imgs to boot. Any ideas why? The same exact stuff worked fine on my Hero.
Click to expand...
Click to collapse
well some more detail would be really helpful in troubleshooting. hopefully you're able to get something ... im still new to the style HTC uses for their kernels.
is the kernel booting and not loading the init.rc properly (possible adb output?) or is the kernel not even loading properly? how far along with the boot screens do you get?
are you using --cmdline and --base?
Good call. I should probably post the commands I used. lol
Ok so I did change my init.rc but for testing purposes I just unpacked the stock boot.img and immediately repacked it. the commands are as follows:
Code:
$ mkbootfs boot.img-ramdisk | gzip > ramdisk-boot
$ mkbootimg --kernel boot.img-kernel --ramdisk ramdisk-boot --cmdline "no_console_suspend=1 console=null" -o newBoot.img --base 0x19200000
Then generates a boot.img file successfully but it still does not boot. Any ideas?
Edit: And of course I renamed newBoot.img to boot.img and included it in an update.zip which all flashed with no errors. Just never gets past the first HTC Evo 4G boot screen
chuckhriczko said:
Edit: And of course I renamed newBoot.img to boot.img and included it in an update.zip which all flashed with no errors.
Click to expand...
Click to collapse
im still beginning in building boot.img files for HTC android phones. my experience is with building a straight zImage kernel file with an initramfs compiled into the zImage kernel file for a Samsung android phone.
hopefully somebody can comment with some better insight, on mkbootfs, etc as I'm also very curious what the best command is for our EVO.
my only comment is a side note to the flashing process and hopefully this method will speed up testing for you and everybody else. i wrote the commands ROM and recovery/normal android mode independent. this is how i would quickly test kernels on my samsung android based phone, assuming it works the same on HTC?
adb push boot.img /sdcard/boot.img
adb push flash_image /sdcard/flash_image (only have to do once)
cat /sdcard/flash_image > /data/flash_image (only have to do once)
chmod 755 /data/flash_image (only have to do once)
/data/flash_image boot /sdcard/boot.img
reboot the phone to test ... hopefully that simplifies the kernel testing process!
thanks for posting up all your detail, its insightful and helpful!
--base 0x20000000 <~ change to
btw moving thread to q&a
toastcfh said:
--base 0x20000000 <~ change to
btw moving thread to q&a
Click to expand...
Click to collapse
Worked perfectly. Thanks Toast.

[Bootloader] U-boot for the multi-boot support

Hi!
As with Galaxy S2, I have ported the u-boot bootloader to the Galaxy Nexus. It can be chainloaded from samsung bootloader (loaded instead of linux kernel) safely.
It could be useful to have multiple ROMs on one device or test other OS like Ubuntu or Genode.
Detailed installation guide is available at Ksys Labs LLC wiki http://ksyslabs.org/doku.php?id=gnex_uboot .I'll just copy-paste it here
Happy hacking and don't forget to visit our wiki at http://ksyslabs.org !
===== Rationale ======
There were a couple reasons to port u-boot to Galaxy Nexus
* Security: we cannot trust the proprietary samsung bootloader
* Implementing dual-boot for original and custom firmware
* Booting Genode operating system
===== Demo =====
===== Compilation from source =====
Source code is in https://github.com/Ksys-labs/uboot-tuna
There exist two branches of interest
* master - contains the official stable releases. may be force-pushed and rebased, beware
* tuna-fosdem-hacks contains the u-boot that was used for FOSDEM 2013 to demo booting Genode
To compile, you need to have the ARM cross-compiler. I recommend codesourcery 2010q1-188 because that's what I'm using and some users reported that newer compilers produce broken binaries.
There are two ways to use the u-boot. One is flashing it instead of the Samsung SBL bootloader. The other one is chainloading it from the SBL.
Flashing instead of SBL has the following advantages
* Faster boot time than chainloading
* Ability to use the standard partitioning layout
There is a number of issues and therefore we do not recommend flashing it instead of SBL
* No Fastboot support (preliminary USB RNDIS and DHCP BOOTP support is available), you'll have to use OMAPFlash to restore the device if you flash a non-working kernel
* No display initialization. You'll have to disable the "Check for Bootloader initialization" option in kernel config
By default, the chainloaded version is compiled. It is loaded (by the SBL) to the address **0x81808000**.
If you want to build the SBL replacement version, edit the **include/configs/omap4_tuna.h** file and uncomment the **#define TUNA_SPL_BUILD** line. X-loader loads the bootloader to the address **0xa0208000**.
Code:
export PATH=/home/alexander/handhelds/armv6/codesourcery/bin:$PATH
export ARCH=arm
export CROSS_COMPILE=arm-none-eabi-
U_BOARD=omap4_tuna
make clean
make distclean
make ${U_BOARD}_config
make -j8 ${U_BOARD}
mkbootimg --kernel u-boot.bin --ramdisk /dev/null -o u-boot.aimg
===== Installation =====
==== Chainloaded Mode ====
You'll need the root access to your device.
You can take the prebuilt u-boot here. http://ksyslabs.org/lib/exe/fetch.php?media=gnex-uboot-chainloaded.img
The u-boot has the support for android boot images. When flashed instead of the SBL, it boots the kernel off the "Boot" partition. When chainloaded, it looks for the kernel in **/system/boot/vmlinux.uimg** . Additionally, it first looks for the **/system/boot/boot.scr.uimg** so you can put custom commands there and override the kernel image.
It also supports booting custom images from **/sdcard/boot/vmlinux.uimg** and **/sdcard/boot/boot.scr.uimg**
If you need larger images, I suggest that you use the **tuna-fosdem-hacks** branch, format the cache partition to ext2 and put the files to **/cache/media/boot/**
push the files to your device via adb
Code:
adb push gnex-uboot-chainloaded.img /sdcard/
adb hell
now, in the device shell, do the following
Code:
su
cat /dev/block/platform/omap/omap_hsmmc.0/by-name/boot > /sdcard/vmlinux.uimg
mount -o remount,rw /system
mkdir /system/boot
cp /sdcard/vmlinux.uimg /system/boot/
cat /sdcard/gnex-uboot-chainloaded.img > /dev/block/platform/omap/omap_hsmmc.0/by-name/boot
sync
reboot
Instead of installing gnex-uboot-chainloaded.img via dd, you can use fastboot
Code:
fastboot flash:raw boot u-boot.img
===== Replacing samsung bootloader =====
OMAP4 devices cannot be bricked completely because the CPU has a firmware loader in the OTP (one-time programmable) memory. When the device is powered, it tries booting from USB.
Make sure to have an old version of x-loader (PRIMEKK14) because newer ones have the security hole which allowed booting unsigned bootloaders fixed. The installation procedure is roughly the same, but use **sbl** partition. And also install xloader from http://ksyslabs.org/lib/exe/fetch.php?media=gnex-xloader-working.img
Code:
adb push gnex-xloader-working.img /sdcard/
Code:
cat /sdcard/gnex-xloader-working.img > /dev/block/platform/omap/omap_hsmmc.0/by-name/xloader
There exists a Samsung recovery tool which can unbrick the devices with corrupted xloader/SBL. You will need a computer running Windows XP.
Search the internet for the archive named "OMAPFlash_tuna.zip" which has md5 "ddbf07a1d36b044c40af5788a83b5395". We cannot upload it here because of the unclear license status.
===== Making images =====
You can either use Android's mkbootimg to produce ANDROID! type images (not recommended) or u-boot's mkimage (in the u-boot tools directory) to make boot images. Using ANDROID! format is discouraged because the loader code in the u-boot is buggy and may fail in some corner cases such as large images.
==== making a custom boot image ====
Code:
mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 -n linux -d zImage vmlinux.uimg
#alternatively, just do that when compiling linux
#do not forget to add mkimage to your PATH variable
make uImage
==== making a custom boot script ====
Code:
mkimage -A arm -O linux -T script -C none -a 0x84000000 -e 0x84000000 -n android -d boot.scr boot.scr.uimg
===== Booting Modes =====
The bootloader supports several boot modes. Each boot mode is indicated by the color of the LED and activated by a combination of hardware buttons. It also supports the Android "reboot to recovery" and "reboot to bootloader" features
* Normal Boot -> no keys are pressed, cyan LED
* Recovery Boot -> Volume Up key pressed, green LED
* Custom Boot -> Volume Down key pressed, blue LED
* USB RNDIS mode -> both Volume keys pressed, purple LED
===== Pitfalls =====
* No Fastboot or DFU (RNDIS BOOTP is untested) -> not a big deal if you're chainloading, right?
* Serial number is always 0123456789abcdef or sth like that. Anyone to fix that?
* UART support is quirky. The device will likely hang if booted with the UART cable. Workaround: boot without the UART cable and plug right after the purple LED flashes.
===== A sample boot script for android =====
Make a boot.scr.uimg from it and push it to the correct location.
Code:
setenv bootargs "mem=1G vmalloc=768M omap_wdt.timer_margin=30 mms_ts.panel_id=18
no_console_suspend console=ttyFIQ0";
setenv loaddaddr 0x82000000;
setenv devtype mmc;
setenv devnum 0;
setenv kernel_part 0xc;
setenv kernel_name /media/boot/vmlinux.uimg;
echo Load Address: ${loaddaddr};
echo cmdline:${bootargs};
if ext4load ${devtype} ${devnum}:${kernel_part} ${loaddaddr} ${kernel_name}; then
bootm ${loaddaddr};
exit 0;
elif ext2load ${devtype} ${devnum}:${kernel_part} ${loaddaddr} ${kernel_name}; then
bootm ${loaddaddr};
exit 0;
else
echo failed to boot custom image;
fi
Nice!
Before there actually wasn't any dual boot stuff for Nexus but now there is really much....
I will laugh if someone ports still another dual boot loader to Nexus, E.g BootiQi dual boot loader or what it is..., (for Jét it is JétQi) but I don't remember the original dual boot files names...
Any toro support?
Sent from my Galaxy Nexus using xda app-developers app
saber.srod said:
Any toro support?
Sent from my Galaxy Nexus using xda app-developers app
Click to expand...
Click to collapse
You may try it out. It is flashed instead of kernel, not overwriting the bootloader, so should be safe. As we don't have any Toro devices, we're not particularly interested in providing support for them unless someone steps up with a patch
Also, make sure to have an old version of x-loader (PRIMEKK14) because newer ones have the security hole which allowed booting unsigned bootloaders fixed.
Click to expand...
Click to collapse
do you have PRIMEKK14 file?
cause I couldn't find it on this thread:
http://forum.xda-developers.com/showthread.php?t=1587498
or this one is PRIMEKK14?
http://ksyslabs.org/lib/exe/fetch.php?media=gnex-xloader-working.img
any enlightenment please?
savantist said:
do you have PRIMEKK14 file?
cause I couldn't find it on this thread:
http://forum.xda-developers.com/showthread.php?t=1587498
or this one is PRIMEKK14?
http://ksyslabs.org/lib/exe/fetch.php?media=gnex-xloader-working.img
any enlightenment please?
Click to expand...
Click to collapse
The latter one is the one I'm using on my phone so it should work.
sp3dev said:
The latter one is the one I'm using on my phone so it should work.
Click to expand...
Click to collapse
I wanna use the chainloaded method, so first thing I should do is fastboot-ing that .img just like another bootloader file? then chainload the u-boot file?
but it looks like I'm replacing samsung SBL (replacing SBL method) if I do that, doesn't it?
savantist said:
I wanna use the chainloaded method, so first thing I should do is fastboot-ing that .img just like another bootloader file? then chainload the u-boot file?
but it looks like I'm replacing samsung SBL (replacing SBL method) if I do that, doesn't it?
Click to expand...
Click to collapse
Yes, you can actually fastboot it via
"fastboot flash:raw boot u-boot.img"
and no, you don't need to mess with xloader for chainloading
sp3dev said:
Yes, you can actually fastboot it via
"fastboot flash:raw boot u-boot.img"
and no, you don't need to mess with xloader for chainloading
Click to expand...
Click to collapse
so it's ok to do chainloading in PRIMELC03 bootloader? If yes, I'm success...
finally "The Great Sp3dev"
nice work like always,
playing with it now,let's see where it goes
Sent from my Galaxy Nexus using xda premium
sp3dev said:
The latter one is the one I'm using on my phone so it should work.
Click to expand...
Click to collapse
ah, I bricked my phone with your gnex-xloader-working using following script... It is only 128K. Is that right?
Code:
cat /sdcard/gnex-xloader-working.img > /dev/block/platform/omap/omap_hsmmc.0/by-name/xloader
Is PRIMEKK14 bootloader the only one to work since we only have http://forum.xda-developers.com/showthread.php?t=1587498 this thread for bootloader and there's no flashable version of PRIMEKK14?
I use OMAPFlash to save it having PRIMEKK15 bootloader and I do not have the courage to do it again...
dlhxr said:
ah, I bricked my phone with your gnex-xloader-working using following script... It is only 128K. Is that right?
Code:
cat /sdcard/gnex-xloader-working.img > /dev/block/platform/omap/omap_hsmmc.0/by-name/xloader
Is PRIMEKK14 bootloader the only one to work since we only have http://forum.xda-developers.com/showthread.php?t=1587498 this thread for bootloader and there's no flashable version of PRIMEKK14?
I use OMAPFlash to save it having PRIMEKK15 bootloader and I do not have the courage to do it again...
Click to expand...
Click to collapse
Oh well, I specially edited the post so that chainloaded users don't flash loader. You only need the xloaded if you flash u-boot instead of SBL. Otherwise, treat u-boot just as linux kernel.
As for replacing bootloader, I guess PRIMEKK15 should also work, I just didn't notice when the security check was introduced. Yeah, use OMAPFlash to recover anyway. And note that you cannot use my precompiled u-boot to replace SBL. As written in the beginning of the post, you need to change a define in config and recompile because the load address and partition layout are different for chainloading and direct booting cases.
Very nice! Keep the good work up! :good:
sp3dev said:
Oh well, I specially edited the post so that chainloaded users don't flash loader. You only need the xloaded if you flash u-boot instead of SBL. Otherwise, treat u-boot just as linux kernel.
As for replacing bootloader, I guess PRIMEKK15 should also work, I just didn't notice when the security check was introduced. Yeah, use OMAPFlash to recover anyway. And note that you cannot use my precompiled u-boot to replace SBL. As written in the beginning of the post, you need to change a define in config and recompile because the load address and partition layout are different for chainloading and direct booting cases.
Click to expand...
Click to collapse
Some feedback here. I flashed u-boot to boot partition and save the original boot image to /system/boot/vmlinux.uimg.
Without any key pressed it shows
Code:
Wrong Image Format for boot command
Error: can't get kernel image!
Not booting xxxxxxxxx
Fail to boot
The characters on the screen does not show well and some of them can't be recognized....
When I press the volume up, it boot into recovery.
When I press the volume down, it shows
Code:
File not found /media/boot/vmlinux.uimg
Unrecognized filesystem type
Fail to boot
Something is wrong with my procedure?
Another small question. I want to make a zip to flash the U-boot, but always failed. I have to use fastboot command to flash gnex-uboot-chainloaded.img to boot.img.
What is in my updater-script.
Code:
mount("ext4", "EMMC", "/dev/block/platform/omap/omap_hsmmc.0/by-name/system", "/system");
package_extract_file("gnex-uboot-chainloaded.img", "/tmp/gnex-uboot-chainloaded.img");
package_extract_file("META-INF/com/google/android/switch_boot.sh", "/tmp/switch_boot.sh");
set_perm(0, 0, 0777, "/tmp/switch_boot.sh");
run_program("/tmp/switch_boot.sh");
set_perm(0, 0, 0777, "/system/boot/vmlinux.uimg");
unmount("/system");
What is in my switch_boot.sh
Code:
#!/sbin/sh
cat /dev/block/platform/omap/omap_hsmmc.0/by-name/boot > /tmp/vmlinux.uimg
mkdir /system/boot
cp /tmp/vmlinux.uimg /system/boot/
cat /tmp/gnex-uboot-chainloaded.img /dev/block/platform/omap/omap_hsmmc.0/by-name/boot
It seems the last line doesn't work...
Code:
cat /tmp/gnex-uboot-chainloaded.img /dev/block/platform/omap/omap_hsmmc.0/by-name/boot
If I use the following command in updater-script,
Code:
package_extract_file("gnex-uboot-chainloaded.img", "/dev/block/platform/omap/omap_hsmmc.0/by-name/boot");
The device enters bootloader directly showing no boot image after reboot....
dlhxr said:
If I use the following command in updater-script,
Code:
package_extract_file("gnex-uboot-chainloaded.img", "/dev/block/platform/omap/omap_hsmmc.0/by-name/boot");
The device enters bootloader directly showing no boot image after reboot....
Click to expand...
Click to collapse
That's because SBL expects the boot partition to contain the image in ANDROID! format. It creates the image itself when you flash via fastboot with the ":raw" suffix.
Try that
Code:
mkbootimg --kernel gnex-uboot-chainloaded.img --ramdisk /dev/null -o u-boot.aimg
Not sure why the original boot image didn't work for you. Are you copying the boot.img to vmlinux.uimg or the raw zImage? you should do the former, the u-boot expects either the "ANDROID!" image or the one made with mkimage.
If anything, you could try repacking the boot image yourself or try mine to see if it boots (it's for jb 4.1.1 though)
http://rghost.ru/44686398
chainloading method, in fact it works on PRIMELC03 too...
btw,
if I flash the xloader (replacing bootloader method), then how am I gonna back to original samsung bootloader/PRIMELC03 since there isn't fastboot support in your u-boot bootloader?
using odin? or omapflash? :crying:
thanks.
savantist said:
chainloading method, in fact it works on PRIMELC03 too...
Click to expand...
Click to collapse
ok, I probably didn't make it clear enough. chainloading works with any bootloader and is safe.
savantist said:
btw,
if I flash the xloader (replacing bootloader method), then how am I gonna back to original samsung bootloader/PRIMELC03 since there isn't fastboot support in your u-boot bootloader?
using odin? or omapflash? :crying:
thanks.
Click to expand...
Click to collapse
if you can boot android or recovery, thenuse dd it to /dev/block/blah-blah-blah, otherwise - omapflash.
sp3dev said:
ok, I probably didn't make it clear enough. chainloading works with any bootloader and is safe.
if you can boot android or recovery, thenuse dd it to /dev/block/blah-blah-blah, otherwise - omapflash.
Click to expand...
Click to collapse
you wrote it on wrong part on first page yesterday, makes me little bit confused, but it's corrected now...
but to do "replacing bootloader method", one should flash PRIMEKK14 or PRIMEKK15 bootloader before, right?
wow... omapflash...
savantist said:
you wrote it on wrong part on first page yesterday, makes me little bit confused, but it's corrected now...
but to do "replacing bootloader method", one should flash PRIMEKK14 or PRIMEKK15 bootloader before, right?
wow... omapflash...
Click to expand...
Click to collapse
well, some bootloaders after PRIMEKK may work, but I have not tested and we had some new phones with the recent firmware versions from stock, and u-boot failed to work there until xloader was downgraded

[Info] mmcblk* partitons reference of the P6 B107

Located in /dev/block, may be useful
Code:
mmcblk0p1 -> /xloader
mmcblk0p2 -> /round (-empty-)
mmcblk0p3 -> /nvme
mmcblk0p4 -> /misc
mmcblk0p5 -> /splash (-empty-)
mmcblk0p6 -> /oeminfo
mmcblk0p7 -> /reserved1 (-empty-)
mmcblk0p8 -> /reserved2 (-empty-)
mmcblk0p9 -> /splash2
mmcblk0p10 -> /recovery2 (-empty-)
mmcblk0p11 -> /recovery
mmcblk0p12 -> /boot
mmcblk0p13 -> /modemimage
mmcblk0p14 -> /modemnvm
mmcblk0p15 -> /modemnvm2
mmcblk0p16 -> /system
mmcblk0p17 -> /cache
mmcblk0p18 -> /cust
mmcblk0p19 -> /userdata
I took this info opening the direct accesses in /dev/block/platform/hi_mci.1/by-name
To extract the boot or recovery img with dd:
Code:
adb shell
su
dd if=/dev/block/mmcblk0p11 of=/sdcard/recovery.img
dd if=/dev/block/mmcblk0p12 of=/sdcard/boot.img
TheProd said:
To extract the boot or recovery img with dd:
Code:
adb shell
su
dd if=/dev/block/mmcblk0p11 of=/sdcard/recovery.img
dd if=/dev/block/mmcblk0p12 of=/sdcard/boot.img
Click to expand...
Click to collapse
I already extracted recovery.img But i can't unpack it, i use unyaffs.exe but i get "broken image file" D:
Same with the other *.img files
Code:
BOARD_KERNEL_CMDLINE vmalloc=512M k3v2_pmem=1 mmcparts=mmcblk0:p1(xloader),p3(n
me),p4(misc),p5(splash),p6(oeminfo),p7(reserved1),p8(reserved2),p9(splash2),p10
recovery2),p11(recovery),p12(boot),p13(modemimage),p14(modemnvm1),p15(modemnvm2
,p16(system),p17(cache),p18(cust),p19(userdata);mmcblk1:p1(ext_sdcard)
BOARD_KERNEL_BASE 00000000
BOARD_PAGE_SIZE 2048
BOARD_RAMDISK_ADDR 01400000
Unpacking ramdisk to "/ramdisk/" . . .
Compression used: gzip
2085 blocks
Done!
Boot.img unpacked, K3V2 uses ARMv7 Instruction Set. Let's see if we can't get something cooking already
I unpacked recovery and boot too
Sent from my HUAWEI P6-U06 using xda app-developers app
Good show, unless your planning on beginning work on a Custom Recovery what are you going to gain by unpacking the recovery.img?
I see your working on a CM port, so wish you all the best on that. I'll be porting MIUIv5 for the Ascend P6 as I did for a few other devices, also going to have another crack at porting Flyme OS since I already ported 90% to my previous device.
Best Regards,
s89
I unpacked boot and recovery to get info for BoardConfig.mk
Ty
Sent from my HUAWEI P6-U06 using xda app-developers app
If you've already got a build environment setup you may aswel build CWM from CM sources, we have more then enough information here to proceed. Even more convenient considering you have the recovery.img unpacked. Google "Build CWM Cyanogenmod" for more info. Failing that i'll setup a build environment and do so myself tomorrow evening.
Best Regards,
s89
I'm setting up the enviroment to build CWM, i hope to get it done in a few hours, anyways, i got bad news. My laptop screen broke today, and i send it to repair tomorrow and i don't know how much time will take :/
S34Qu4K3 said:
I'm setting up the enviroment to build CWM, i hope to get it done in a few hours, anyways, i got bad news. My laptop screen broke today, and i send it to repair tomorrow and i don't know how much time will take :/
Click to expand...
Click to collapse
Aww man that's unfortunate, wishing a speedy recovery for said laptop aha. Are you continuing the build on another machine or using an external monitor for the meantime?
Best Regards,
s89
Stickman89 said:
Aww man that's unfortunate, wishing a speedy recovery for said laptop aha. Are you continuing the build on another machine or using an external monitor for the meantime?
Best Regards,
s89
Click to expand...
Click to collapse
I got an small laptop and a pc, i have to install linux and will continue working (i think) i expect to be at least 1 week without my laptop (maybe i got it with screen broken ultil i wait the new screen)
Dam git sync, so ****ing long
Just a question, if i have in my .fstabfile the partition routes this way:
Code:
/dev/block/platform/hi_mci.1/by-name/sdcard
I have to change it to
Code:
/dev/block/mcblk....
In BoardConfig.mk or can i let it original? Looks the same for me, /dev/block/platform/hi_mci.1/by-name/ points the mcblk, i want to be sure
S34Qu4K3 said:
Just a question, if i have in my .fstabfile the partition routes this way:
Code:
/dev/block/platform/hi_mci.1/by-name/sdcard
I have to change it to
Code:
/dev/block/mcblk....
In BoardConfig.mk or can i let it original? Looks the same for me, /dev/block/platform/hi_mci.1/by-name/ points the mcblk, i want to be sure
Click to expand...
Click to collapse
EXT SDCard Mounts at:
Code:
/dev/block/mmcblk1p1
so your recovery.fstab should be setup like...
Code:
/sdcard vfat /dev/block/mmcblk1p1
So yup it needs to be changed to the second option.
I'm still syncing too... -.- ...zZzZzZzZz tired
Best Regards,
s89​
Stickman89 said:
EXT SDCard Mounts at:
Code:
/dev/block/mmcblk1p1
so your recovery.fstab should be setup like...
Code:
/sdcard vfat /dev/block/mmcblk1p1
So yup it needs to be changed to the second option.
I'm still syncing too... -.- ...zZzZzZzZz tired
Best Regards,
s89​
Click to expand...
Click to collapse
But /dev/block/platform/hi_mci.1/by-name/sdcard points to /dev/block/mmcblk1p1, so it shouldn't be necessary (i'll use /dev/block/mmcblk1p1 style, to be sure anyway)
In 4 hours, i leave my lapton in the shop, in another hour, i got it repaired (115€ D
I've built CWM from CM sources. Haven't tried it as of yet though.
Flash at your OWN risk. I will not take responsibility for any actions taken by the user in combination with the provided file... By downloading this image your accepting full liability for any issues that should arise as a result of undergoing ANY flashing/modding on YOUR device.
Removed for the time being! Do not use...
Best Regards,
s89
Stickman89 said:
I've built CWM from CM sources. Haven't tried it as of yet though.
Flash at your OWN risk. I will not take responsibility for any actions taken by the user in combination with the provided file... By downloading this image your accepting full liability for any issues that should arise as a result of undergoing ANY flashing/modding of your device.
Best Regards,
s89
Click to expand...
Click to collapse
My repo still 93% ;___;
Why you don't make a thread posting it??
Good job bro
We can try recoverys without flash using fastboot? Like the kernel?
S34Qu4K3 said:
My repo still 93% ;___;
Why you don't make a thread posting it??
Good job bro
We can try recoverys without flash using fastboot? Like the kernel?
Click to expand...
Click to collapse
I've tried "fastboot boot recovery.img" to no avail. The output is as follows...
Output:
Code:
downloading 'boot.img'...
OKAY [ 0.193s]
booting...
FAILED (remote: invalid command)
finished. total time: 0.194s
As you can see... It's expecting a boot.img so this command is only available for booting ramdisk & kernel.
Stickman89 said:
I've tried "fastboot boot recovery.img" to no avail. The output is as follows...
Output:
Code:
downloading 'boot.img'...
OKAY [ 0.193s]
booting...
FAILED (remote: invalid command)
finished. total time: 0.194s
As you can see... It's expecting a boot.img so this command is only available for booting ramdisk & kernel.
Click to expand...
Click to collapse
So, we have to flash it... Bad bad...D:
I tried fastboot boot recovery recovery.img but i get:
Code:
fastboot boot recovery recovery.img
cannot load 'recovery'
I don't think that command is applicable until post flash as according to cyanogenmod documentation:
Code:
Installing recovery using fastboot
You can use fastboot to install your recovery image to the device.
Installing ClockworkMod Recovery on the device
Connect the device to the computer via USB.
Make sure the fastboot binary is in your PATH or that you place the downloaded image in the same directory as fastboot.
Open a terminal on your PC and reboot the device into fastboot mode by typing adb reboot bootloader or by using the hardware key combination.
Once the device is in fastboot mode, verify your PC sees the device by typing fastboot devices
If you don't see your device serial number, and instead see "<waiting for device>", fastboot is not configured properly on your machine. See fastboot documentation for more info.
Flash ClockworkMod Recovery onto your device by entering the following command: fastboot flash recovery your_recovery_image.img where the latter part is the name of the file you downloaded.
Once the flash completes successfully, reboot the device into recovery to verify the installation. This can be done by typing fastboot boot your_recovery_image.img.
Note: Some ROMs overwrite recovery at boot time so if you do not plan to immediately boot into recovery to install CyanogenMod, please be aware that this may overwrite your custom recovery with the stock one.

[Guides & Links] how to root ASUS ZenPad 3 8.0 (Z581KL)

This procedure supplements what was posted on 2ch.
this procedure is for firmware v3.3.18 or less.
If your firmware is v3.3.20, you may be able to downgrade to v3.3.18 with the procedure described at the end of this post.
for necessary files, download from the follwoing URL.
hZtZtpsZ://wZwZwZ.axfc.net/u/3777377
Z←remove
(PASS Z581KL) (差分=Difference,キーワード=KEYWORD,ダウンロード=Download,こちら=HERE,cacheに置くもの=Things to put in the cache)
1.extract boot image
turn on debug mode.
then, reboot recovery mode.
Code:
$ adb reboot recovery
after that, mount the system using the terminal volume button and the power button.
Code:
$ adb push dirtycow /tmp/
$ adb push run-as /tmp/
$ adb shell
[email protected]_1:/ $ cd /tmp
[email protected]_1:/tmp $ chmod 777 dirtycow
[email protected]_1:/tmp $ chmod 777 run-as
[email protected]_1:/tmp $ ./dirtycow ./run-as /system/bin/run-as
[email protected]_1:/tmp $ run-as
[email protected]_1:/tmp # dd if=/dev/block/mmcblk0p41 of=/tmp/boot.img
[email protected]_1:/tmp # chmod 777 /tmp/boot.img
[email protected]_1:/tmp # exit
[email protected]_1:/tmp $ exit
transfer boot.img to PC.
Code:
$ adb pull /tmp/boot.img ./
2.unpacking the boot.img
"mkbootimg_tools-master" is useful because it outputs log of ramdisk size.
(However, binary "mkbootfs" and "mkbootimg" are 32-bit versions.
if your environment is 64-bit, you need to bring 64-bit binaries from CarlivImageKitchen64 etc)
for example, using mkbootimg_tools-master looks like this:
Code:
$ ./mkboot bootimg_source/boot.img bootimg_output
Unpack & decompress bootimg_source/boot.img to bootimg_output
kernel : kernel
ramdisk : ramdisk
page size : 2048
kernel size : 29041019
[COLOR="Red"]ramdisk size : 2924316 <- refer to this value later[/COLOR]
base : 0x80000000
kernel offset : 0x00008000
ramdisk offset : 0x01000000
tags offset : 0x00000100
cmd line : console=ttyHSL0,115200,n8 androidboot.console=ttyHSL0 androidboot.hardware=qcom msm_rtb.filter=0x237 ehci-hcd.park=3 androidboot.bootdevice=7824900.sdhci lpm_levels.sleep_disabled=1 earlyprintk vmalloc=256M build_version=3
ramdisk is gzip format.
Unpack completed.
directories after unpacking boot.img looks like this:
bootimg_output
|--ramdisk
|--kernel
`--others(img_info,ramdisk.packed,etc)
3.install SuperSU manually
overwrite the contents of "initrd差分.7z" under directory "ramdisk".
("su" is an empty directory, but also to put it under "ramdisk")
(for "sbin", you only need to add launch_daemon.sh without deleting the existing files)
(permissions on files/directories should be the same as original or other file/directories)
4.repacking the boot.img
for example, using mkbootimg_tools-master looks like this:
Code:
$ ./mkboot bootimg_output boot_patched.img
mkbootimg from bootimg_output/img_info.
kernel : kernel
ramdisk : new_ramdisk
page size : 2048
kernel size : 29041019
ramdisk size : 2924316
base : 0x80000000
kernel offset : 0x00008000
ramdisk offset : 0x01000000
tags offset : 0x00000100
cmd line : console=ttyHSL0,115200,n8 androidboot.console=ttyHSL0 androidboot.hardware=qcom msm_rtb.filter=0x237 ehci-hcd.park=3 androidboot.bootdevice=7824900.sdhci lpm_levels.sleep_disabled=1 earlyprintk vmalloc=256M build_version=3
ramdisk is gzip format.
Repack image utility by [email protected]
Check and add the kernel
Check and add the ramdisk
Build the new image
'boot_patched.img' successfully repacked
Kernel size: 29041019, [COLOR="Magenta"][COLOR="Red"]new ramdisk size: 2924316[/COLOR][/COLOR], test_patched.img: 31969280.
test_patched.img has been created.
...
at this time, it is necessary to adjust so that the value of "new ramdisk size" becomes
the same value as "ramdisk size" when unpack.
if the size of "ramdisk" is different from when unpacked, Z581KL will not start.
therefore, deleting unnnecessary files stored under ramdisk/res/images/charger and adding dummy files.
(the difference of about several bytes seems to be no problem)
(once wrong boot.img is written, Z581KL will no start until you write the original boot.img)
however, the size of the original boot.img and the modified boot.img can be different.
(in my environment, the original boot.img was about 67MB, while the modifyed boot.img was
about 32MB)
5.insert modified boot.img
using dirtycow, adb push, and dd, insert the modified boot.img into the /dev/block/mmcblk0p41
also, put "su.img" and "SuperSU.apk" in /cache
then,reboot Z581KL.
"Verification Error" is always displayed when starting up, but if you wait for a while
it will start normally.
that's all.
**********************
Firmware downgrade procedure
1. your firmware is v3.3.20.0
2. download firmware from asus's support page. (UL-P008-WW-3.3.18.0-user.zip)
3. rename the zip file ( UL-P008-WW-3.3.18.0-user.zip -> UL-P008-WW-5.3.9.0-user.zip )
4. Place the zip file in an arbitrary directory on the SD card and insert this SD card into Z581KL
5. The update dialog is displayed as it is ( or it is displayed when restarted )
If the firmware is v 5 or higher (currently v 5.3.9.0 is published),
this procedure may indicate an error and the downgrade may fail.
In that case, for now I have no choice but to give up ...
I am sorry if my comment sounds unprofessional. Can you express steps 2-5 in a vulgar manner. Is mkbootimg a tool? ttps://forum.xda-developers.com/android/software-hacking/development-mkbootimg-tools-t2895954
I am experiencing permission denied while performing: adb pull /tmp/boot.img ./
i.imgur.com/TSO0v1g.png
About mkbootimg it is right.
Download all files with ZIP from GitHub's "Clone or download" button described in that URL.
About "adb pull" command, sorry.
Before doing it, you need to change the permissions of boot.img to 777.
[email protected]_1:/tmp # dd if=/dev/block/mmcblk0p41 of=/tmp/boot.img
[email protected]_1:/tmp # chmod 777 /tmp/boot.img
[email protected]_1:/tmp # exit
[email protected]_1:/tmp $ exit
By the way, I would like you to tell me.
Is there a procedure like this that you successfully downgraded the firmware?
1. your firmware is v3.3.20.0
2. download firmware from asus's support page. (UL-P008-WW-3.3.18.0-user.zip)
3. rename the zip file ( UL-P008-WW-3.3.18.0-user.zip -> UL-P008-WW-5.3.9.0-user.zip )
4. Place the zip file in an arbitrary directory on the SD card and insert this SD card into Z581KL
5. The update dialog is displayed as it is ( or is it displayed when restarted? )
yamada_2501 said:
By the way, I would like you to tell me.
Is there a procedure like this that you successfully downgraded the firmware?
1. your firmware is v3.3.20.0
2. download firmware from asus's support page. (UL-P008-WW-3.3.18.0-user.zip)
3. rename the zip file ( UL-P008-WW-3.3.18.0-user.zip -> UL-P008-WW-5.3.9.0-user.zip )
4. Place the zip file in an arbitrary directory on the SD card and insert this SD card into Z581KL
5. The update dialog is displayed as it is ( or is it displayed when restarted? )
Click to expand...
Click to collapse
Correct. This is exactly what I've done. My factory firmware was v3.3.20.0. I downloaded the 3.3.18.0 firmware from ASUS website and rename it to the 5.3.9.0 firmware. I was able to downgrade the system using the standard procedures.
---------- Post added at 04:11 AM ---------- Previous post was at 03:55 AM ----------
yamada_2501 said:
About mkbootimg it is right.
Download all files with ZIP from GitHub's "Clone or download" button described in that URL.
About "adb pull" command, sorry.
Before doing it, you need to change the permissions of boot.img to 777.
[email protected]_1:/tmp # dd if=/dev/block/mmcblk0p41 of=/tmp/boot.img
[email protected]_1:/tmp # chmod 777 /tmp/boot.img
[email protected]_1:/tmp # exit
[email protected]_1:/tmp $ exit
Click to expand...
Click to collapse
Thank you. I was able to successfully pull that boot.img. However, is there any mkbootimg alternative for windows. It seems like a linux system tool.
---------- Post added at 04:20 AM ---------- Previous post was at 04:11 AM ----------
yamada_2501 said:
About mkbootimg it is right.
Download all files with ZIP from GitHub's "Clone or download" button described in that URL.
About "adb pull" command, sorry.
Before doing it, you need to change the permissions of boot.img to 777.
[email protected]_1:/tmp # dd if=/dev/block/mmcblk0p41 of=/tmp/boot.img
[email protected]_1:/tmp # chmod 777 /tmp/boot.img
[email protected]_1:/tmp # exit
[email protected]_1:/tmp $ exit
Click to expand...
Click to collapse
I was able to find this post (ttps://forum.xda-developers.com/redmi-1s/general/guide-unpack-repack-kernel-t2908458). I am not sure if it work. Would you please verify and please post the steps. When I use this tool, I am getting a intrid folder instead of ramdisk folder as describe in your post. The link below is what I have. The red boxed files are the original files. Green arrowed file is the original boot.img
i.imgur.com/8d05Zis.png
Also, would you please provide the codes you used in step 5.
Update:
I was somehow able to push boot.img and the other two files in by modifying step 1's code. However, I think the boot.img I created has an error. Perhaps because of sizing error. I am not able to start the machine. Now, is stuck at fastboot options menu. How can I get back to the recovery menu and perhaps push the original boot.img back.
If you connect to the PC with the fastboot menu activated,
and execute the " fastboot reboot recovery " command on the PC,
will not you get to the recovery menu?
yamada_2501 said:
If you connect to the PC with the fastboot menu activated,
and execute the " fastboot reboot recovery " command on the PC,
will not you get to the recovery menu?
Click to expand...
Click to collapse
No, when I execute that command, it shows me a bunch of options as shown in the screenshot below.
i.imgur.com/ZJsh5Ub.png
Sorry, I can only think about this as other means....
1.Power off your device
2.pressing and holding Volume Down and Power Button at the same time
3.Boot in recovery mode
1.Power off your device
2.pressing and holding Volume Up and Power Button at the same time
3.Boot in Fast boot options menu
4.select "USB debug mode"
1.Boot in Fast boot options menu
2.Use fastboot command from PC to start Z581KL from original boot.img on PC
-> fastboot boot ./boot.img
yamada_2501 said:
Sorry, I can only think about this as other means....
1.Power off your device
2.pressing and holding Volume Down and Power Button at the same time
3.Boot in recovery mode
1.Power off your device
2.pressing and holding Volume Up and Power Button at the same time
3.Boot in Fast boot options menu
4.select "USB debug mode"
1.Boot in Fast boot options menu
2.Use fastboot command from PC to start Z581KL from original boot.img on PC
-> fastboot boot ./boot.img
Click to expand...
Click to collapse
The combination button will not get me to the recovery mode. USB debugging mode requires a OS system. I've been trying to flash/boot the original boot.img from my computer but it has some permission error.
i.imgur.com/rmK65Z9.png
Is it possible to get this permission error fix and flash or boot the original boot.img?
I already upgraded to Nougat 5.3.9.0. Could I downgrade to 3.3.18 without bricking it?
I could get blueborne to work on JP_V5.5.0_220170616.
But shell whose uid=bluetooth is seemingly useless for rooting...
Does anyone know how to get root from bluetooth shell?
is there any guide to flash a ww rom over operator rom?
thanks
How to insert the modified boot.img into the /dev/block/mmcblk0p41 by using dirtycow, adb push, and dd?
tomo_ward said:
How to insert the modified boot.img into the /dev/block/mmcblk0p41 by using dirtycow, adb push, and dd?
Click to expand...
Click to collapse
His original instruction left out commands to acquire permission to access boot.img. Read the reply threads between yamada and me. He addressed the instruction to acquire the permission. In order to insert the modified boot.img, you re-execute step 1, but instead of doing an adb pull on the last command of step 1, do an adb push.
However, the issue of this guide is the fact that you need to push the boot.img out, unpack and repack it. The risk of this is that the chance of you getting wrong modified size boot.img. There is no way to re-acquire permission to replace the wrong boot.img with the original one once you can't boot into the system; therefore, you end up with a Z581Kl that just do not boot. I had to send mine Z581KL back to factory in order to fix the effect.
If you are willing to take the risk and does success, please provide the boot.img you have successfully modified. That will definitely be a gospel.
thank you.
I'll try to get Root my Z581KL
Should I change file permission of patched_boot.img before run "dd" command?
[email protected]_1:/tmp # chmod 777 /tmp/patched_boot.img #Do I need?
[email protected]_1:/tmp # dd if=/tmp/patched_boot.img of=/dev/block/mmcblk0p41
Was anyone able to get a boot.img that works?
Cannot download the needed ZIP file.
Any backup?
Uqbar said:
Cannot download the needed ZIP file.
Any backup?
Click to expand...
Click to collapse
None has it any more?

[HowTO] Get rid of annoying "Kernel is not seandroid enforcing" message....

Hi,
I started to play with kernel hacking/configuration and I found the annoying red message
After a lot of research i found that we can get rid of it by adding at the end of boot.img file the SEANDROIDENFORCE text string, as following
echo SEANDROIDENFORCE >> boot.img
Best regards,
Marc
serdeliuk said:
Hi,
I started to play with kernel hacking/configuration and I found the annoying red message
After a lot of research i found that we can get rid of it by adding at the end of boot.img file the SEANDROIDENFORCE text string, as following
echo SEANDROIDENFORCE >> boot.img
Best regards,
Marc
Click to expand...
Click to collapse
Thanks.. Work bro..
diphons said:
Thanks.. Work bro..
Click to expand...
Click to collapse
Yeah, I'd like recommend to find a solution to get also rid of "set warranty bit kernel/recovery", the yellow warning is really annoying!
I was able to append the boot.img file with SEANDROIDENFORCE text string.
But how do you exactly write it back?
I'm on samsung note 4.
Code:
adb reboot recovery
adb shell
dd if=/dev/block/bootdevice/by-name/BOOT of=/sdcard/boot.img
echo SEANDROIDENFORCE >> /sdcard/boot.img
If i try to switch if and of path, I get an error
Code:
dd if=/sdcard/boot.img of=/dev/block/bootdevice/by-name/BOOT
dd: writing '/dev/block/bootdevice/by-name/BOOT': No space left on device
UnknownPlanet said:
I was able to append the boot.img file with SEANDROIDENFORCE text string.
But how do you exactly write it back?
Code:
adb reboot recovery
adb shell
dd if=/dev/block/bootdevice/by-name/BOOT of=/sdcard/boot.img
echo SEANDROIDENFORCE >> /sdcard/boot.img
If i try to switch if and of path, I get an error
Code:
dd if=/sdcard/boot.img of=/dev/block/bootdevice/by-name/BOOT
dd: writing '/dev/block/bootdevice/by-name/BOOT': No space left on device
Click to expand...
Click to collapse
In order to write the boot.img you need to use fastboot/bootloader mode of your device, adb reboot bootloader, then use `fastboot flash boot boot.img`
Alternatively, you can put the boot.img on your /sdcard boot to twrp then `cat boot.img > /dev/your/boot/partition`
The no space left on the device means that your file is bigger than the destination which is unusual if you built that boot img, from your example it seems that you save your partition and do not use a built boot.img
serdeliuk said:
In order to write the boot.img you need to use fastboot/bootloader mode of your device, adb reboot bootloader, then use `fastboot flash boot boot.img`
Alternatively, you can put the boot.img on your /sdcard boot to twrp then `cat boot.img > /dev/your/boot/partition`
Click to expand...
Click to collapse
It doesn't work, I'm on samsung note 4. I also have latest TWRP installed.
fastboot device keep saying:
< waiting for any device >
UnknownPlanet said:
It doesn't work, I'm on samsung note 4. I also have latest TWRP installed.
fastboot device keep saying:
< waiting for any device >
Click to expand...
Click to collapse
you need to find how to boot your device in bootloader mode, usually volDOWN+power together
serdeliuk said:
Alternatively, you can put the boot.img on your /sdcard boot to twrp then `cat boot.img > /dev/your/boot/partition`
Click to expand...
Click to collapse
Still error
Code:
~ # cat /sdcard/boot.img > /dev/block/bootdevice/by-name/BOOT
cat: write error: No space left on device
serdeliuk said:
The no space left on the device means that your file is bigger than the destination which is unusual if you built that boot img, from your example it seems that you save your partition and do not use a built boot.img
Click to expand...
Click to collapse
I use Custom ROM of Hani Base v1.01 here:
[ROM][6.0.1][TW][N910C/H/U] Hani Base v1.01 [18-04-2016][Deodexed][PreRooted]
Welcome to Hani Base ROM thread! Samsung Galaxy Note 4 SM-N910C N910CXXU2DPCB TW 6.0.1 THREAD INDEX: I. INTRODUCTION II. FEATURES III. DOWNLOADS IV. HOW TO FLASH #_____________________________# #include ...
forum.xda-developers.com
I have succcessfuly get and edit the boot.img but I don't know how to flash it back. Forking to make another whole custom ROM is not an option. I won't learn anything.
It's just a tiny append why so difficult.
serdeliuk said:
you need to find how to boot your device in bootloader mode, usually volDOWN+power together
Click to expand...
Click to collapse
There's no bootloader in my samsung note 4, adb reboot bootloader goes to system instead.
Home+Power+VolumeDown enters the download mode, but even then fastboot device still doesn't respond.
Do I need to use Odin or what?
You may need to ask questions about your boot options on the dedicated channel for your device, i do not own such device, but download mode is the fastboot mode as far as can remember, "fastboot devices" should show your device listed when in download mode.
Your steps to flash the boot.img fail because the file is bigger than your boot partition, does not fit there, you may need to seek for help form the img developers to see what to do. You can try to flash the boot.img on recovery partitions which is usually bigger and reboot to recovery, but pay attention, if you don't know how to go back to fastboot mode you are stuck with a bricked device
I was able to flash it without any change in the boot partition size by editing it manually using hex editor.
These are my steps
Code:
adb reboot recovery
adb shell "dd if=/dev/block/bootdevice/by-name/BOOT of=/sdcard/boot.img"
adb pull /sdcard/boot.img
I use Frhed hex editor to edit the last 16 bytes of boot.img into SEANDROIDENFORCE
Code:
adb push boot.img /sdcard/boot.img
adb shell "dd if=/sdcard/boot.img of=/dev/block/bootdevice/by-name/BOOT"
The problem right now is that, the red text is still there. What should be my next step?
UnknownPlanet said:
I was able to flash it without any change in the boot partition size by editing it manually using hex editor.
These are my steps
Code:
adb reboot recovery
adb shell "dd if=/dev/block/bootdevice/by-name/BOOT of=/sdcard/boot.img"
adb pull /sdcard/boot.img
I use Frhed hex editor to edit the last 16 bytes of boot.img into SEANDROIDENFORCE
Code:
adb push boot.img /sdcard/boot.img
adb shell "dd if=/sdcard/boot.img of=/dev/block/bootdevice/by-name/BOOT"
The problem right now is that, the red text is still there. What should be my next step?
Click to expand...
Click to collapse
I don't know if editing the boot.img works, probably should do, however, i found this solution poking around with third party device trees and worked for my samsung galaxy tab, if do not work on your phone then you may need to dig a bit deeper, however, if you use a third party image maybe you ask them why you have that on your screen, maybe they have another fix. Probably a bit of more info can be found here https://github.com/osm0sis/dhtbsign but i didn't spent time to read it. You can ask the developer about more info.
Your solution of device tree / dhtb is impressive on it's own, that's another big learning curve.
But I think I know the problem, because the Custom ROM Hani Base above is using H-Vitamin Kernal which is SELinux Permissive. No matter how I edit the boot.img file the red text message will always appears, unless I flash it with another kernel which is SELinux Enforcing.
UPDATE
This is even weirder.
By updating SuperSU into the latest version, the red text is missing from system mode. It still persist in recovery mode tough, because, well twrp need full access to begin with.
No Magisk here, it was an old custom ROM.
All official app from playstore is now gone but the official xda thread still remain:
[STABLE][2017.05.27] SuperSU v2.82
*** Urgent Update Notice *** We are deeply sorry about the installation errors and failures happened in v2.80. The new update v2.81 has rolled out on XDA and Play Store to fix the problem occured in v2.80. Chainfire has also...
forum.xda-developers.com
From reading the last pages of the thread, I got the official site of chainfire to download it.
SuperSU Download
The file name is
sr5-supersu-v2.82-sr5-20171001224502.zip
Just flash it with latest TWRP and you're done.
I still don't understand how could updating SuperSU could fix the problem.
But what a long journey, thank you so much @serdiluk , I learn so much things.

Categories

Resources