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.
Extracting the N2 root filesystem and adding rc.local
These instructions assume using a linux console.
The root filesystem lives in a u-boot/PPCboot ramdisk. These instructions tell you how to extract it.
Boot your nt with the "rooted forever" sdcard while connected with usb.
Make a copy of the boot partition. After this you may reboot your nt normally.
$ tar -cf boot.tar boot/
$ tar xvf boot.tar
$ cd boot
Extract the uRamdisk file. first 64 bytes is the u-boot header, we need to skip it.
$ dd if=URamdisk bs=64 skip=1 of=ramdisk.gz
ramdisk.gz now contains the root file system.
Copy ramdisk.gz to a work directory, then extract it:
gunzip -v ramdisk.gz
cpio -iv < ramdisk
The root file system will populate your work dir. Delete the ramdisk file. You can now make changes to the root file system.
The change I'm going to make is a simple one: adding the ability to run an rc.local file at boot.
edit the init.rc file in your work directory, adding at the bottom:
Code:
service rclocal /etc/rc.local
enabled
user root
oneshot
rebuilding the uRamdisk file is simple, once you know how (thanks to JesusFreke for pointing me in the right direction). cd into your working directory, issue these commands:
Code:
find . -regex "./.*"| cpio -ov -H newc | gzip > ../ramdisk.gz
mkimage -A ARM -T RAMDisk -n Image -d ../ramdisk.gz ../uRamdisk
A script with the the commands above is attached. Also attached is a rooted uRamdisk with the rc.local ability already build in. To replace the uRamdisk file, boot with your "Rooted Forever" sdcard, and copy the uRamdisk file to the nook's boot directory.
What's this good for? That's up to you. I'm using it to automatically start dropbear so I can ssh in my Nooks and also use rsync to keep them synced with my ebook library. This is also one of the steps in building a kernel for the Nook ST.
jocala said:
Extracting the N2 root filesystem and adding rc.local
These instructions assume using a linux console.
The root filesystem lives in a u-boot/PPCboot ramdisk. These instructions tell you how to extract it.
Boot your nt with the "rooted forever" sdcard while connected with usb.
Make a copy of the boot partition. After this you may reboot your nt normally.
$ tar -cf boot.tar boot/
$ tar xvf boot.tar
$ cd boot
Extract the uRamdisk file. first 64 bytes is the u-boot header, we need to skip it.
$ dd if=URamdisk bs=64 skip=1 of=ramdisk.gz
ramdisk.gz now contains the root file system.
Copy ramdisk.gz to a work directory, then extract it:
gunzip -v ramdisk.gz
cpio -iv < ramdisk
The root file system will populate your work dir. Delete the ramdisk file. You can now make changes to the root file system.
The change I'm going to make is a simple one: adding the ability to run an rc.local file at boot.
edit the init.rc file in your work directory, adding at the bottom:
Code:
service rclocal /etc/rc.local
enabled
user root
oneshot
rebuilding the uRamdisk file is simple, once you know how (thanks to JesusFreke for pointing me in the right direction). cd into your working directory, issue these commands:
Code:
find . -regex "./.*"| cpio -ov -H newc | gzip > ../ramdisk.gz
mkimage -A ARM -T RAMDisk -n Image -d ../ramdisk.gz ../uRamdisk
A script with the the commands above is attached. Also attached is a rooted uRamdisk with the rc.local ability already build in. To replace the uRamdisk file, boot with your "Rooted Forever" sdcard, and copy the uRamdisk file to the nook's boot directory.
What's this good for? That's up to you. I'm using it to automatically start dropbear so I can ssh in my Nooks and also use rsync to keep them synced with my ebook library. This is also one of the steps in building a kernel for the Nook ST.
Click to expand...
Click to collapse
dd if=URamdisk bs=64 skip=1 of=ramdisk.gz
Click to expand...
Click to collapse
"uRamdisk" instead of "URamdisk"
Thanks again.
Hi all folks,
I have some question about the stock android system in this specific box and the format of the dumped partition.
Try to explain, I'm using rkflashtool to interact with the memory of the RK3188
This is the output of the command
rkflashtool r 0 1 | head -n 11
-------------------------------------------------------------------------------------------------
CMDLINE:console=ttyFIQ0 androidboot.console=ttyFIQ0
init=/init initrd=0x62000000,0x00800000 mtdparts=rk29xxnand:
[email protected](misc),
[email protected](kernel),
[email protected](boot),
[email protected](recovery),
[email protected](backup),
[email protected](cache),
[email protected](userdata),
[email protected](kpanic),
[email protected](system),
[email protected](user)
-------------------------------------------------------------------------------------------------
I guess the boot partition is something linke that:
+-------+ <--- 0x00019fe0
| boot |
+-------+ <----0x00012000
With this command i'm able to dump the entrie boot partition on my linux box in a file named b00t.img :
rkflashtool r 0x12000 0x8000 > b00t.img
Now, i have find out that with the tool rkunpack (or simply with dd) i'm able to unpack this b00t.img. The output are two file:
b00t.img-raw
b00t.img-symbol
The first file is no more than a gzip compressed data file, I'm able to extract the data in a directory with this command:
gunzip < ../b00t.img-raw | sudo cpio -i --make-directories
Now in this dir I have all the files of the / partition. I can modify for example the /init.rc.
I want to repack the entrie b00t.img in order to flash it again on the device.
NB:
In this thread this guys work at something like my problem...
http://www.freaktab.com/showthread....-Tricks-by-Finless&p=4055&viewfull=1#post4055
The difference is that they work on a different partition layout, and the rkunpack of dumped boot.img return they only boot.img-raw.
Obviously I've already tried to repack the modified directory in this two ways:
mkcramfs myboot myboot-temp.img
kcrc myboot-temp.img customboot.img
or
find . ! -name "."| sort | cpio -oa -H newc | gzip -n > ../newboot.gz
kcrc newboot.gz customboot.img
Neither of these leads to obtain a file large enough to fit the boot partition on the deivice, that I want fill with:
rkflashtool w 0x12000 0x8000 < modifiedb00t.img
Has anyone ever worked with rk3188? Any idea?
Thanks in advance.
Anyone?
As the title states this is a stock boot.img with init.d support.
Download >>> https://mega.nz/#!Nwx0BD5T!TZB0ngp3spi3myFAFw7gtx0z8zu7O2BRLv2UC2HTJ4M
XDA:DevDB Information
[BOOT IMAGE] Stock boot with su.d & init.d support, Kernel for the Elephone P9000
Contributors
Jonny
Kernel Special Features:
Version Information
Status: Stable
Stable Release Date: 2016-05-20
Created 2016-05-18
Last Updated 2016-05-20
this cant work . sry
skeleton1911 said:
this cant work . sry
Click to expand...
Click to collapse
Should do, same way I used to fire init.d on other devices (M9). Of course with SuperSU installed init.d is kind of deprecated as su.d is a better solution.
Jonny said:
Should do, same way I used to fire init.d on other devices (M9). Of course with SuperSU installed init.d is kind of deprecated as su.d is a better solution.
Click to expand...
Click to collapse
no sorry i dont work.
look:
in init.rc you wrote that
Code:
service sysinit /system/xbin/busybox run-parts /system/etc/init.d
class main
oneshot
user root
group root
that is going to sysinit . but sysinit service is not present in in system, check it yourself
if you would use this . it would work at boot
Code:
service[COLOR="Red"] userinit[/COLOR] /system/xbin/busybox run-parts /system/etc/init.d
oneshot
class late_start
user root
group root
and users have to install busybox and add the init.d folder into system/etc manual
set permissions to 755 or 777 for the init,d folder and the scripts they want to use
Ah cheers, I forgot to add the sysinit binary. Tbh though I think I'm going to look more into su.d as it seems more reliable in where in the boot process it executes the script :good:
Link updated. New zip flashes and installs busybox and creates the su.d and init.d folders with correct permissions. This one now supports both init.d and su.d (recommended).
Jonny said:
Link updated. New zip flashes and installs busybox and creates the su.d and init.d folders with correct permissions. This one now supports both init.d and su.d (recommended).
Click to expand...
Click to collapse
now it works . great job
Jonny said:
As the title states this is a stock boot.img with init.d support.
Click to expand...
Click to collapse
What tools did you use to repack the kernel and ramdisk ? I've used nearly ten tools with a non working boot image after modifying default.prop only.
Please advise about any tricks to do that.
Thanks.
nmset said:
What tools did you use to repack the kernel and ramdisk ? I've used nearly ten tools with a non working boot image after modifying default.prop only.
Please advise about any tricks to do that.
Thanks.
Click to expand...
Click to collapse
What did you edit in the boot image?
Sent from my Elephone P9000 using XDA Labs
Jonny said:
What did you edit in the boot image?
Click to expand...
Click to collapse
I unpacked the boot image, then the ramdisk, edited default .prop changing ro.adb.secure from 1 to 0.
Repacked the ramdisk with
find . | cpio --owner root:root -ov -H newc | gzip -9 > ../ramdisk.cpio.gz
After repacking the boot image with many tools, no way to get a working one.
nmset said:
I unpacked the boot image, then the ramdisk, edited default .prop changing ro.adb.secure from 1 to 0.
Repacked the ramdisk with
find . | cpio --owner root:root -ov -H newc | gzip -9 > ../ramdisk.cpio.gz
After repacking the boot image with many tools, no way to get a working one.
Click to expand...
Click to collapse
It's editing that line, I've tried it previously myself and it just ends up with a boot image that doesn't work.
Sent from my Elephone P9000 using XDA Labs
Jonny said:
It's editing that line, I've tried it previously myself and it just ends up with a boot image that doesn't work.
Click to expand...
Click to collapse
If I just unpack the original boot image and the ramdisk, and repack everything without any modifications, the resulting boot image is not functional.
If I unpack the original boot image, and do not unpack the ramdisk, then repack the kernel and ramdisk, the resulting boot image works perfectly.
It seems related with the ramdisk format, or its header, or addresses and offsets, or whatever, I wish you could share how you got a working boot image.
Thanks.
nmset said:
If I just unpack the original boot image and the ramdisk, and repack everything without any modifications, the resulting boot image is not functional.
If I unpack the original boot image, and do not unpack the ramdisk, then repack the kernel and ramdisk, the resulting boot image works perfectly.
It seems related with the ramdisk format, or its header, or addresses and offsets, or whatever, I wish you could share how you got a working boot image.
Thanks.
Click to expand...
Click to collapse
I use Android Image Kitchen, but I've still had the same results as you when editing that line
Jonny said:
I use Android Image Kitchen, but I've still had the same results as you when editing that line
Click to expand...
Click to collapse
Code:
find . | cpio -o -a --reproducible -R 0:0 -H newc | gzip -9 > ../ramdisk.cpio.gz
That did the trick.
(As a sidenote, I did not have the expected result, i.e, a root shell with 'adb shell', after 'adb root', one more paranoid regression from Google.)
:crying:
nmset said:
Code:
find . | cpio -o -a --reproducible -R 0:0 -H newc | gzip -9 > ../ramdisk.cpio.gz
That did the trick.
(As a sidenote, I did not have the expected result, i.e, a root shell with 'adb shell', after 'adb root', one more paranoid regression from Google.)
:crying:
Click to expand...
Click to collapse
For a root shell type 'adb shell' the just type 'su' and accept the superuser prompt on your device.
Adb root is needed for doing the adb remount command to push and pull certain files to /system
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?