search

chenxiaolong / DualBootPatcher

Patches Android ROMs for dual boot support
https://dbp.noobdev.io
Other
527 stars 470 forks source link

Bootloop after updating ramdisk and enabling BootUI #1383

Open klorinczi opened 5 years ago

klorinczi commented 5 years ago

I updated to DBP v9.3.0.r952, updated ramdisk for all ROMs and enabled BootUI. I got bootloop right after restarting the phone.

Unfortunately, flashing older boot.img does not help this time. Now my phone is unusable.

Using DBP v9.3.0.r952, Samsung Galaxy Note 3 N9505. ROMs:

klorinczi commented 5 years ago

@chenxiaolong: attaching logs. 19701007.032850.tar.gz

d3d43 commented 5 years ago

Do you have twrp? Flash any rom to clear the phone and at least get a working os

klorinczi commented 5 years ago

If I flash a new os, I will lose the current setup. There are was nothing wrong with my setup, just wanted to test the new DBP release. But I got bootloop.

chenxiaolong commented 5 years ago

@klorinczi Can you reboot into recovery and either with adb or the TWRP terminal, run:

e2fsck -fy /dev/block/platform/msm_sdcc.1/by-name/system

to repair the filesystem?

Looks like DBP can't mount the partition as read-write:

1738 <3>[    6.173914] [2014-09-10T22:47:33.130664000+00:00][1:1][E] m/b/mount_fstab: /raw/system: Failed to chmod: Read-only file system
klorinczi commented 5 years ago

Here is the log. 19701008.121631.tar.gz

chenxiaolong commented 5 years ago

OK, looks like it got past the /system mounting issue this time, but now the kernel doesn't detect the SD card at all:

<3>[   11.589464] [2014-10-07T08:38:23.882767000+00:00][1:1][D] mbtool/mount_fstab: Matching devices against pattern: /devices/msm_sdcc.3/mmc_host/mmc*
<3>[   11.589653] [2014-10-07T08:38:23.882953000+00:00][1:1][E] mbtool/mount_fstab: No external SD patterns were matched after 10 attempts

Is TWRP able to mount the sdcard?

Also, could you upload the boot.img and boot.img.before-ramdisk-update.img from /sdcard/MultiBoot?

klorinczi commented 5 years ago

Well, I can see/read external sdcard from TWRP/Install.

klorinczi commented 5 years ago

Should I upload all subdirectories of /sdcard/MultiBoot? I have following entries in /sdcard/MultiBoot:

chenxiaolong commented 5 years ago

The extsd-slot-rr585 directory should be good enough.

klorinczi commented 5 years ago

19701008.124428.tar.gz 19701008.125612.tar.gz 2019-02-08c_boot-img.zip

klorinczi commented 5 years ago

Same error:

<3>[   11.529830] [2014-10-08T09:21:19.854272000+00:00][1:1][D] mbtool/mount_fstab: Matching devices against pattern: /devices/msm_sdcc.3/mmc_host/mmc*
<3>[   11.530020] [2014-10-08T09:21:19.854460000+00:00][1:1][E] mbtool/mount_fstab: No external SD patterns were matched after 10 attempts
<3>[   11.530158] [2014-10-08T09:21:19.854604000+00:00][1:1][E] mbtool/mount_fstab: Failed to mount /raw/extsd
<3>[   11.530301] [2014-10-08T09:21:19.854748000+00:00][1:1][E] mbtool/init: Failed to mount fstab
chenxiaolong commented 5 years ago

Yeah. I see this too:

when booted into recovery (recovery/dmesg.log):

<3>[    1.857359] mmc2: id 3
<6>[    1.858473] mmc2: no vmmc regulator found
<7>[    1.859511] Registered led device: mmc2::
<6>[    1.860595] mmc2: SDHCI controller on msm_sdcc.3 [msm_sdcc.3] using ADMA
<6>[    2.204061] mmc2: new high speed SDXC card at address 0001
<6>[    2.204250] mmcblk1: mmc2:0001 ED4QT 119 GiB

when booting into extsd-slot-rr585:

<3>[    1.095677] mmc2: id 3
<6>[    1.096842] mmc2: no vmmc regulator found
<6>[    1.098936] mmc2: SDHCI controller on msm_sdcc.3 [msm_sdcc.3] using ADMA

That's 1 second into the boot process--way before any DBP stuff loads. I have no idea why the kernel is failing to detect the SD card.

19701008.124428.tar.gz 19701008.125612.tar.gz 2019-02-08c_boot-img.zip

It looks like the boot.img.before-ramdisk-update.img and boot.img are identical for some reason. That would explain why restoring it didn't work.

[2019-02-08c_boot-img] /stuff/Android/DualBootPatcher/build_linux_x86_64/examples/bootimg_compare boot.img boot.img.before-ramdisk-update.img
[2019-02-08c_boot-img] echo $?
0

The kernel might need to be repatched and reflashed. If you have a link to the ROM's zip, I can make a zip containing just the kernel.

By the way, does data-slot-rr583 boot? If not, can you post the logs after trying to boot into it? That would at least rule out SD card issues.

klorinczi commented 5 years ago

I will try to boot into data-slot-rr583. However I will have to stop further debugging, because it is 02:30AM here, and tomorrow I'm traveling, so I have to go to the bed.

Do you remember, there was an external sdcard bug, you already fixed earlier? Can not be a similar problem?

Might be DBP interact with Magisk (using v17.1 currently)? I had strange experience (RR booted, but got slow, did strange things) after patching with Magisk v18.0.

I test data-slot before I go to sleep, will post result soon.

klorinczi commented 5 years ago

Note: to read from the external sdcard, I pull out the card and read it with USB 3.0 reader. It shows the card perfectly, I can read it. So the card should be ok.

Also I used the card since several months, so a code change or an external lib update might be causing the problem.

klorinczi commented 5 years ago

After switching to data-slot-rr583 the phone booted into Download mode.

chenxiaolong commented 5 years ago

I could be wrong, but I wouldn't think it's a DBP bug because the issue happens before DBP loads. The only thing I could think of that would break the boot so early is if the kernel or DTB parts of boot.img got corrupted. I'll have to do a diff with the original ROM to know if that happened.

After switching to data-slot-rr583 the phone booted into Download mode.

That's weird. DBP doesn't have any code for rebooting to download mode.

klorinczi commented 5 years ago

Download mode screen had an error, saying could not boot normally, thus the Download mode.

klorinczi commented 5 years ago

I will upload the data-slot-rr583 dir soon.

klorinczi commented 5 years ago

data-slot-rr583.zip

chenxiaolong commented 5 years ago

Is the RR ROM one of these? https://androidfilehost.com/?w=files&flid=185591

klorinczi commented 5 years ago

My older backup boot.img files in extsd-slot-rr585: extsd-slot-rr585_other_imgs.zip

klorinczi commented 5 years ago

As I remember it is: RR-N-v5.8.5-20180313-hlte-Official-vidwhal.zip

klorinczi commented 5 years ago

Going to sleep. See you later.

chenxiaolong commented 5 years ago

I have no idea what might be wrong. The kernel and device tree both before and after the ramdisk update match the original ROM.

[temp] md5sum boot.img-kernel /tmp/logs/**/boot.img-kernel                                                                                                                                                                                  21:08:18  ☁  aosp-boot-ui ☂ ✖ ⚡ ✭
7c53107ed561b1ebdec9b1be982b6e2c  boot.img-kernel
7c53107ed561b1ebdec9b1be982b6e2c  /tmp/logs/2019-02-08c_boot-img/after/boot.img-kernel
7c53107ed561b1ebdec9b1be982b6e2c  /tmp/logs/2019-02-08c_boot-img/before/boot.img-kernel
[temp] md5sum boot.img-dt /tmp/logs/**/boot.img-dt                                                                                                                                                                                          21:08:45  ☁  aosp-boot-ui ☂ ✖ ⚡ ✭
ef2c66c0619e59def8af656d8724d417  boot.img-dt
ef2c66c0619e59def8af656d8724d417  /tmp/logs/2019-02-08c_boot-img/after/boot.img-dt
ef2c66c0619e59def8af656d8724d417  /tmp/logs/2019-02-08c_boot-img/before/boot.img-dt

Inside the ramdisk, I noticed that one of Magisk's files are wrong. .backup/init should be a binary, not a symlink. I don't think this would cause the booting issues though.

[temp] diff -u <(bsdtar -tvf boot.img-ramdisk) <(bsdtar -tvf /tmp/logs/2019-02-08c_boot-img/after/boot.img-ramdisk) | head                                                                                                                  21:13:21  ☁  aosp-boot-ui ☂ ✖ ⚡ ✭
--- /proc/self/fd/12    2019-02-07 21:13:24.749824615 -0500
+++ /proc/self/fd/14    2019-02-07 21:13:24.750824624 -0500
@@ -1,18 +1,24 @@
+d---------  1 0      0           0 Dec 31  1969 .backup
+----------  1 0      0          41 Dec 31  1969 .backup/.magisk
+----------  1 0      0          41 Dec 31  1969 .backup/.sha1
+lrwxrwxrwx  1 0      0           7 Dec 31  1969 .backup/init -> /mbtool
 drwxr-xr-x  1 0      0           0 Dec 31  1969 acct
-lrw-r--r--  1 0      0          50 Dec 31  1969 bugreports -> /data/user_de/0/com.android.shell/files/bugreports
+lrwxrwxrwx  1 0      0          50 Dec 31  1969 bugreports -> /data/user_de/0/com.android.shell/files/bugreports

In any case, it might be worth trying to reflash the kernel (without magisk). Here is RR-N-v5.8.5-20180313-hlte-Official-vidwhal.zip with everything except for boot.img removed.

RR-N-v5.8.5-20180313-hlte-Official-vidwhal_KERNEL_ONLY.zip

klorinczi commented 5 years ago

After flashing the kernel only ZIP, reboot, but the boot screen is displayed forever, without any further reboot.

klorinczi commented 5 years ago

I flashed the kernel only ZIP, but after reboot, it shows the booting screen continously. No reboot at all.

klorinczi commented 5 years ago

Here are the logs after flashing: RR-N-v5.8.5-20180313-hlte-Official-vidwhal_KERNEL_ONLY.zip

19701008.184108.tar.gz 19701009.082557.tar.gz

klorinczi commented 5 years ago

I found these lines in bootui/exec.log:

[2014-10-07T01:28:15.793762000+00:00][265:265][V] m/main: Loading graphics system...
failed to mmap framebuffer: Invalid argument
fbdev: Initialization failed
Failed to load any backend
fb0 reports (possibly inaccurate):
  vi.bits_per_pixel = 32
  vi.red.offset   =  24   .length =   8
  vi.green.offset =  16   .length =   8
  vi.blue.offset  =   8   .length =   8
[2014-10-07T01:28:15.794628000+00:00][265:265][E] m/main: Failed to load graphics system
[1970-10-07T01:42:28.348074000+00:00][262:262][V] m/main: ----------------------------------------
[1970-10-07T01:42:28.348549000+00:00][262:262][V] m/main: Launching mbbootui (version 9.3.0.r952.g7bb9ef34) 
...
[1970-10-07T01:42:29.300782000+00:00][262:262][I] m/g/pages: PageManager::LoadFileToBuffer loading filename: '/mbbootui/theme/ui.xml' directly
[1970-10-07T01:42:29.301150000+00:00][262:262][I] m/g/pages: Checking resolution...
[1970-10-07T01:42:29.301199000+00:00][262:262][I] m/g/pages: Loading resources...
[1970-10-07T01:42:29.411351000+00:00][262:262][I] m/g/resources: Failed to load image from indeterminate013, error -1 
...
[1970-10-06T20:42:29.002593000-05:00][262:266][I] m/g/action: operation_start: 'autoboot'
Welcome to DualBootPatcher
BootUI version: 9.3.0.r952.g7bb9ef34
mbtool version: 9.3.0.r952.g7bb9ef34
Autobooting to extsd-slot-rr574
Booting in 5 seconds...
[1970-10-06T20:42:29.004681000-05:00][262:262][I] [%s] %s: ARMAssembler
Booting in 4 seconds...
Booting in 3 seconds...
Booting in 2 seconds...
Booting in 1 seconds...
Booting now...

I have not seen BootUI to appear at all since v9.3.0.r952 was installed.

Might cause the boot screen hanging?

klorinczi commented 5 years ago

Also in multiboot/MultiBoot.log:

[2019-02-06T16:39:22.837046000+01:00][12052:12052][D] m/r/installer_util: /multiboot/boot.img: Copying entry directly
[2019-02-06T16:39:24.767807000+01:00][12052:12052][E] m/u/romconfig: /raw/data/media/0/MultiBoot/extsd-slot-lineage141/config.json: Failed to open for reading: No such file or directory
[2019-02-06T16:39:24.767953000+01:00][12052:12052][W] m/r/installer: /raw/data/media/0/MultiBoot/extsd-slot-lineage141/config.json: Failed to load config
chenxiaolong commented 5 years ago

I noticed the latest logs say:

<3>[    2.255844] [2014-10-08T09:21:10.580121000+00:00][1:1][V] mbtool/init: Booting up with version 9.3.0.r463.g1fc7bbd0 (v9.3.0-463-g1fc7bbd0)

Every version between 9.3.0.r412.ga0d7059c and 9.3.0.r765.ga8e154db had a bug where the boot image could get corrupted during flashing depending on what was already on the boot partition.

chenxiaolong commented 5 years ago

I have not seen BootUI to appear at all since v9.3.0.r952 was installed.

Might cause the boot screen hanging?

That's possible. Does it help if you rename /cache/multiboot/bootui from TWRP to disable the boot UI?

klorinczi commented 5 years ago
  1. I had been thinking about how to disable bootui from TWRP. Thanks for the idea!

I turned off bootui by renaming /cache/multiboot/bootui to /cache/multiboot/bootui.unused. Unfortunately it did not solve the booting problem.

BTW: Could be possible to implement the feature to turn off BootUI from TWRP with DBP utility? It might be useful in such cases.

  1. How to decide, which rom boot.img uses mbtool version 9.3.0.r463? The current booted one? If so, this may cause the problems I have.
klorinczi commented 5 years ago

How can I decide if a boot.img has patched mbtool code and which version? Would be fine to have a feature in TWRP DBP utility, where I can select a file (or much better a folder) and display the mbtool version of the *.img files. It might be helpful in debugging tasks.

chenxiaolong commented 5 years ago

Could be possible to implement the feature to turn off BootUI from TWRP with DBP utility?

That's a great idea. Yeah, I can add something for that.

How to decide, which rom boot.img uses mbtool version 9.3.0.r463? The current booted one?

Yep, it's the currently booted one.

Would be fine to have a feature in TWRP DBP utility, where I can select a file (or much better a folder) and display the mbtool version of the *.img files.

Also a good idea. I'll see if I can do that.

klorinczi commented 5 years ago

This is the boot screen after flashing data-slot-rr583/boot.img

20190209_052739

chenxiaolong commented 5 years ago

Was data-slot-rr583 patched with a recent version of DBP? (one that doesn't corrupt boot images)

klorinczi commented 5 years ago

Not likely. I didn't use data-slot-rr583 since a long time.

chenxiaolong commented 5 years ago

If that's the case, I'd suggest patching and lfashing the kernel for it again. If the boot.img was originally corrupted (but still booted), the ramdisk update might have corrupted it further.

klorinczi commented 5 years ago

Just an idea.

If I could

  1. Patch a selected boot.img from TWRP,
  2. Change the target rom slot of a selected boot.img from TWRP,

then all the current problems could be easily fixed.

klorinczi commented 5 years ago

I will try to to patch an original boot.img of rr585 on Windows with DBP utility for windows.

klorinczi commented 5 years ago

I made a data-slot-rr583 zip file: RR-N-v5.8.5-20180313-hlte-Official-vidwhal_KERNEL_ONLY_dbp9.3.0.r952_data-slot-rr583.zip

But finally I ended with a tar file to flash with ODIN (sorry, zipped because can not upload tar here): RR-N-v5.8.5-20180313-hlte-Official-vidwhal_KERNEL_ONLY_dbp9.3.0.r952_data-slot-rr583.tar.zip

The result log after booting (booting hangs on booting screen): 19701009.173451.tar.gz

chenxiaolong commented 5 years ago

Can you try flashing this via TWRP? I patched the first file you uploaded for hlte and data-slot-rr583. The boot image actually gets modified during installation, so flashing boot.img via Odin will give you the original unpatched boot image.

RR-N-v5.8.5-20180313-hlte-Official-vidwhal_KERNEL_ONLY_dbp9.3.0.r952_data-slot-rr583.zip

klorinczi commented 5 years ago

Executed on sdcard from TWRP: e2fsck -fy /dev/block/mmcblk0p26

Had a lot errors, which was fixed.

klorinczi commented 5 years ago

Here are the 2 latest logs:

After e2fsck executed on partitions: 19701009.182659.tar.gz

After flashing RR-N-v5.8.5-20180313-hlte-Official-vidwhal_KERNEL_ONLY_dbp9.3.0.r952_data-slot-rr583.zip, which failed. Then flashed boot.img.dbp9.3.0.r952_data-slot-rr583.img directly from TWRP: 19701009.185033.tar.gz But still hangs on boot screen.

klorinczi commented 5 years ago

I will try this patch. RR-N-v5.8.3-20170612-hlte-Unofficial-vidwhal_KERNEL_ONLY_dbp9.3.0.r952_data-slot-rr583.zip

klorinczi commented 5 years ago

I think e2fsck repair deleted all the /raw content and the free space on internal storage increased from about 700 Mb to 14700 Mb.

I lost all my DBP installations :-(

blackpencil2019 commented 5 years ago

Almost the same situation.