Hi guys,
All is in the question, i'm currently ussing doomkernel but i'm a bit bored of the splash 1. That's why i'd like to know if it' possible ( i guess yes of course ) and how can i do that ?
thank's
the first splash from the kernel the second from the rom at "/system/media/bootanimation.zip"
I am talking about splash 1 (bootanimation is not a problem), is there a way to change it via fastboot like for my htc or do I have to modify .img (and how?)
thi3um said:
I am talking about splash 1 (bootanimation is not a problem), is there a way to change it via fastboot like for my htc or do I have to modify .img (and how?)
Click to expand...
Click to collapse
you have to change the kernel see [Tut] Building your own Xperia Play Kernel
paxChristos said:
16) Getting the ramdisk
F1) Download a working copy of FXP's kernel (either through my zips or fxp zips)
F2) Goto here: http://forum.xda-developers.com/showthread.php?t=1477845, download the xperiaboottools.zip that's attached.
F3) Now what I did (you don't have to) is chmod 755 mkbootimg & split_bootimg.pl & (sudo) cp to /bin for easy calling.
F4) Navagiate in terminal to where you downloaded fxp kernel
F5) mkdir <working_folder>
F6) cp <fxp_kernel> <working_folder>
F7) cd <working folder>
F8) split_bootimg.pl <fxp_kernel>
F9) mkdir ramdisk
F10) cd ramdisk
F11) gzip -dc ../<fxp_kernel>.img-ramdisk.gz | cpio -i
F12) Now you have the ramdisk, let's futz with it.
F13) First (easiest step) is to goto default.prop & change ro.secure=1 to ro.secure=0
F14) That's mainly what we want to do with it, if you want to change the boot image, go here: http://forum.xda-developers.com/showthread.php?t=1494076 for how to do it manually, or here: http://forum.xda-developers.com/showthread.php?t=1513146 for the automatic way.
F15) now that we're done with the ramdisk, we'll go back to terminal
F16) find . | cpio -o -H newc | gzip > ../ramdisk.img
F17) cd ../
Click to expand...
Click to collapse
I'm trying to make insecure boot.img for U9200 for my firmware version (V100R001C185B104). Unpacking original boot.img and ramdisk goes OK. After making changes to defult.prop I do the following:
mkbootfs ./ramdisk | gzip > ramdisk-new.gz
mkbootimg --kernel boot.img-kernel --ramdisk ramdisk-new.gz --base 0x80000000 --cmdline "console=ttyGS2,115200n8 mem=1G vmalloc=768M omap_wdt.timer_margin=30 mmcparts=mmcblk015(splash)" --board omap4 -o tools/flash/boot.img
New boot.img is successfuly created but doesn't boot (fastboot boot boot.img). What am I doing wrong?
I've got parameters using bootimg.exe and I think they are OK. There's nothing about them on the net
EDIT:
I made it using other mkbootimg.exe. This one accept more input parameters. This time I use bootimg.exe for upacking bootimg and unpacking and packing ramdisk. I did:
>bootimg.exe --unpack-bootimg
>bootimg.exe --unpack-ramdisk
Do changes at default.prop.
>bootimg.exe --repack-ramdisk
>mkdir flash\
>mkbootimg --kernel kernel --ramdisk ramdisk.cpio.gz --cmdline "console=ttyGS2,115200n8 mem=1G vmalloc=768M omap_wdt.timer_margin=30 mmcparts=mmcblk015(splash)" --board omap4 --base 0x80000000 --pagesize 2048 -o flash\boot.img
Reboot to bootloader:
>adb reboot bootloader
Test if you have good drivers installed:
>fastboot devices
If OK, test your new boot.img without flashing it:
>fastboot boot boot.img
If device boots and you want to have this image permanant flash it with:
>fastboot flash boot.img.
I've attached the tools that worked for me. I'm coplete noob in Android cooking, this is my first steps. There are lot about editing boot.img on the internet but nothing about my device so I decided to start a new topic if someone is also interested in.
also cracking my U9500. Have you done with your problems?
i use bootimg.exe to unpack & repack the img file, using same parameters and nothing modified to the extracted files,
but,
the new & old boot.img(should be same) are not same using binary compare.
according to a file that describes how boot.img is structured, i found that some key parameters are different in these two img file.
I don't know why ....
so if you have succeeded, PLZ tell me ..
contact me qq 6777711 if you're Chinese. or mail me: 6777711 AT qq.com
Nice one. I'll take a look at this aswell.
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?
SOLVED: I was using the G980F boot.img instead of G985F image. THANKS everyone
The device won't reboot if I unpack and repack the boot.img on S20
Did someone else here succeed in flashing a new boot.img ? THANKS
Code:
[email protected]:~/GS20_kernel_build$ unpackbootimg -i boot.img
BOARD_KERNEL_CMDLINE androidboot.hardware=exynos990
BOARD_KERNEL_BASE 10000000
BOARD_PAGE_SIZE 2048
[email protected]:~/GS20_kernel_build$ mkbootimg --kernel boot.img-zImage --ramdisk boot.img-ramdisk.gz -o boot_repacked.img
[email protected]:~/GS20_kernel_build$ heimdall flash --BOOT ./boot_repacked.img
[...]
Downloading device's PIT file...
PIT file download successful.
Uploading BOOT
100%
BOOT upload successful
Ending session...
Rebooting device...
modem__ said:
The device won't reboot if I unpack and repack the boot.img on S20
Did someone else here succeed in flashing a new boot.img ? THANKS
Code:
[email protected]:~/GS20_kernel_build$ unpackbootimg -i boot.img
BOARD_KERNEL_CMDLINE androidboot.hardware=exynos990
BOARD_KERNEL_BASE 10000000
BOARD_PAGE_SIZE 2048
[email protected]:~/GS20_kernel_build$ mkbootimg --kernel boot.img-zImage --ramdisk boot.img-ramdisk.gz -o boot_repacked.img
[email protected]:~/GS20_kernel_build$ heimdall flash --BOOT ./boot_repacked.img
[...]
Downloading device's PIT file...
PIT file download successful.
Uploading BOOT
100%
BOOT upload successful
Ending session...
Rebooting device...
Click to expand...
Click to collapse
You need to make a tar file containing the img and flash it with odin. You need a Windows computer for that. Linux won't do sadly
If you don't feel like making a flashable zip file you can just use dd to install it from within TWRP (via terminal on console or ADB) if you have that installed:
dd if=boot_repacked.img of=/dev/block/by-name/boot
No Windows/Odin required.
sjevtic said:
If you don't feel like making a flashable zip file you can just use dd to install it from within TWRP (via terminal on console or ADB) if you have that installed:
dd if=boot_repacked.img of=/dev/block/by-name/boot
No Windows/Odin required.
Click to expand...
Click to collapse
dd always scares me lol.
You sure this works with S20? Even Fastboot fllashing doesn't work so I doubt this will
JanBoyGamer23 said:
dd always scares me lol.
You sure this works with S20? Even Fastboot fllashing doesn't work so I doubt this will
Click to expand...
Click to collapse
My phone wouldn't boot last night after I tried flashing my own boot image and this was how I put the previous one back. It booted right up.