Bootloop - Samsung S9

[alexcheveau]

Device: Samsung S9 (G9600)
Android version: 10
Magisk version name: v26.1 (debug)
Magisk version code: ee34f77 (26105)

Followed exactly all the steps in https://topjohnwu.github.io/Magisk/install.html#samsung-devices
After flashing the patched AP I got bootloop.

magisk_install_log_2023-08-24T15.06.10.log
mounts.txt
last_kmsg.txt

[XDABlackMesa123]

By looking at the kernel logs seems like the kernel panic is caused by RKP blocking magiskinit (https://github.com/droidian-starqlte/android_kernel_samsung_sdm845/blob/8fde28b4cdfb0c1ed2501c559cb7e593879a978d/fs/exec.c#L1355), I also noticed in the install logs I can't see the RKP disable patch being applied in the kernel image:

Magisk/scripts/boot_patch.sh

Lines 223 to 227 in 0c28a91

	# Remove Samsung RKP
	./magiskboot hexpatch kernel \
	49010054011440B93FA00F71E9000054010840B93FA00F7189000054001840B91FA00F7188010054 \
	A1020054011440B93FA00F7140020054010840B93FA00F71E0010054001840B91FA00F7181010054 \
	&& PATCHEDKERNEL=true

[alexcheveau]

Retried all steps with the new version (26.2 - debug) same result: bootloop
last_kmsg.txt
magisk_install_log_2023-08-28T11.17.06.log

[osm0sis]

Is there a newer version of RKP that needs to be patched out then? Is there source available for this device? Clearly the old patch doesn't work for it.

[alexcheveau]

I don't think it's a new version because this device don't receive new updates anymore, only security patches.
The version that I'm running is https://samfrew.com/download/Galaxy__S9__/rcut/MXO/G9600ZHU9FWC3/G9600OWO9FVF2

[osm0sis]

Fact is the existing RKP patch didn't find a match in your kernel. Is there source for this device kernel?

[alexcheveau]

Fact is the existing RKP patch didn't find a match in your kernel. Is there source for this device kernel?

I think it's this: https://github.com/droidian-devices/linux-android-samsung-starqlte

[osm0sis]

Alright well if you're lucky someone might be able to use that to figure out how to patch it to properly disable RKP on it.

[XDABlackMesa123]

Is there a newer version of RKP that needs to be patched out then? Is there source available for this device? Clearly the old patch doesn't work for it.

Not surprising at all considering this patch is pretty old, iirc it's from Chainfire's SuperSU.

[XDABlackMesa123]

I found more info in issue #3485: #3485 (comment)
The patch might've been broken since quite a few time and didn't cause any issue on recent devices.

[TurfJakkals]

Having the same problem on S9+
Android 12
NOBLEROM2.9F-4.191

Whilst in a bootloop, accessing TWRP -> Advance -> Fix Context and reboot, solves bootloop temporarily. When trying to upgrade Magisk in-app, after reboot, bootloops again.

Zygisk is disabled.

[pndwal]

Having the same problem on S9+ Android 12 NOBLEROM2.9F-4.191

This may or may not account for the whole issue (I haven't diagnosed this properly) but I just saw your screenshot...

However the erroneous detection issue you seem to have did begin with 26105 build OP here is using...

With Ramdisk = No, clearly this is another older legacy ramdisk boot-type ('type I') device being wrongly detected as a legacy SAR 'type III' device...

Further, as the Recovery Mode check box is erroneously appearing in these cases (it's only for A-only devices launched with Android 9 as these 2018, 2019 devices were the only type III devices made) and is checked by default, users are generally leaving it checked (as they don't know better) and Magisk is then patching ramdisk in /recovery partition when taking Direct Install, and recovery.img in Samsung AP binaries when patching these...

Taking Reboot will also cause many devices to boot via recovery (as it's trying to boot system with magiskinit in recovery ramdisk) where Recovery Mode is left checked...

If you/others here tried updating, you likely have both Magisk-patched boot.img and recovery.img now...

This issue should already be fixed with:
Fix device detection scripts and logic
and
Always check mounts to detect legacy SAR on bootmode
in 26202 (Canary), but you should patch and flash fresh stock AP binary to replace recovery.img erroneously patched...

Any who have used 26105 - 26201 builds and had this issue should start fresh with AP binary or restore stock recovery.img to correct erroneous patching before installing 26202+

Hope this helps. 🙂

[osm0sis]

Just in case, try 26203?

[TurfJakkals]

Simply unchecking the Recovery Mode whilst repeating the update in-app solved the problem. Thank you for the help! 🤘🏻

[pndwal]

Simply unchecking the Recovery Mode whilst repeating the update in-app solved the problem. Thank you for the help! 🤘🏻

Thanks for confirming that...

Please say, did Recovery mode option in Install menu still appear in 26202+ Magisk app(s)?... And did it disappear for good after updating Magisk (core/mask)?...

[osm0sis]

Might not be the same problem... We need @alexcheveau to confirm if the same holds true on the S9.

[XDABlackMesa123]

Might not be the same problem... We need @alexcheveau to confirm if the same holds true on the S9.

Doubt it’s the same issue as @TurfJakkals… Magisk should apply the kernel hex patches as well in recovery mode, it’s probably because the current RKP patch applies correctly in his kernel image

[alexcheveau]

I'll do further testing with latest canary in 1-2 days (working issue)
But by the commits and you guys comments I think the problem will persist bc of the mismatch in finding the correct hex in kernel source to patch.

[pndwal]

Might not be the same problem... We need @alexcheveau to confirm if the same holds true on the S9.

I know... All could have multiple issues... But sounded like Recovery mode still appeared in a later build until unchecked, but maybe @TurfJakkals still had 26.2... I just wanted confirmation as other non legacy SAR device users seem to be having this occur after 26202 also...

[XDABlackMesa123]

@alexcheveau could you please try this boot.img and see if it boots correctly? Flash the .tar package with Odin, latest Canary debug apk is required (https://github.com/topjohnwu/magisk-files/raw/canary/app-debug.apk). Send a last_kmsg log file if boot fails.

magisk.zip

[alexcheveau]

@alexcheveau could you please try this boot.img and see if it boots correctly? Flash the .tar package with Odin, latest Canary debug apk is required (https://github.com/topjohnwu/magisk-files/raw/canary/app-debug.apk). Send a last_kmsg log file if boot fails.

magisk.zip

Just did the test, bootloop
last_kmsg attached
last_kmsg.txt

[XDABlackMesa123]

I basically applied a new set of patches (https://github.com/BlackMesa123/Magisk/commit/97ebae78919c67dd157181848f57be054e404b72) basing on the infos I found around (Chainfire blog, #3485 (comment)):

./magiskboot hexpatch kernel \
290E0054011440B93FA00F71C90D0054010840B93FA00F71690D0054001840B91FA00F71090D0054 \
41030054011440B93FA00F71E0020054010840B93FA00F7180020054001840B91FA00F7120020054 \
&& PATCHEDKERNEL=true

@cw2k would you kindly give a look at this? I'm not an expert with hex patches and such

[cw2k]

No can't help ya here.
Hexpatch must be seen in the context.
If it doesn't matches to the target this context is missing.
Well if it matches to an old target but not to the new one then there is a chance to understand and learn how it is meant function in the old target.
Then maybe you are able to locate the place in the new target and see what has changed.
... and finally fix this problem. Change the hexstring to make it work.

However as you see that means a lot of work an time.

[alexcheveau]

@blackmesa123 I was analysing the last_kmsg and I didn't find the same error that was panicking the kernel:
Superblock Mismatch #/data/magiskinit#
Maybe the device is bootlooping bc of a dif problem?

[XDABlackMesa123]

@blackmesa123 I was analysing the last_kmsg and I didn't find the same error that was panicking the kernel: Superblock Mismatch #/data/magiskinit# Maybe the device is bootlooping bc of a dif problem?

I think this time it's caused by the hex patch not working correctly.

[XDABlackMesa123]

No can't help ya here. Hexpatch must be seen in the context. If it doesn't matches to the target this context is missing. Well if it matches to an old target but not to the new one then there is a chance to understand and learn how it is meant function in the old target. Then maybe you are able to locate the place in the new target and see what has changed. ... and finally fix this problem. Change the hexstring to make it work.

However as you see that means a lot of work an time.

Basing on the info in your post (#3485 (comment)) I started to look why the Chainfire patch wouldn't apply in this kernel. The code where the patch is applied is almost unchanged:

• (Qualcomm S9) https://github.com/droidian-starqlte/android_kernel_samsung_sdm845/blob/8fde28b4cdfb0c1ed2501c559cb7e593879a978d/fs/exec.c#L1314-L1325
• (Exynos S9) https://github.com/exynos-linux-stable/starlte/blob/e74e8cdc8d788054c493132327cbeb969a6c95cd/fs/exec.c#L1309-L1320

So I compared both stock kernel images and found that the instructions in the Qualcomm kernel are slightly different:

Exynos:
49010054    b.ls #0x7a430
011440B9    ldr w1, [x0, #0x14]
3FA00F71    cmp w1, #0x3e8
E9000054    b.ls #0x7a430
010840B9    ldr w1, [x0, #8]
3FA00F71    cmp w1, #0x3e8
89000054    b.ls #0x7a430
001840B9    ldr w0, [x0, #0x18]
1FA00F71    cmp w0, #0x3e8
88010054    b.hi #0x7a45c

Qualcomm:
290E0054    b.ls #0x7a5cc
011440B9    ldr w1, [x0, #0x14]
3FA00F71    cmp w1, #0x3e8
C90D0054    b.ls #0x7a5cc
010840B9    ldr w1, [x0, #8]
3FA00F71    cmp w1, #0x3e8
690D0054    b.ls #0x7a5cc
001840B9    ldr w0, [x0, #0x18]
1FA00F71    cmp w0, #0x3e8
090D0054    b.ls #0x7a5cc

I've then created an hex patch similar to the one currently in use:

Exynos:
A1020054    b.ne #0x7a45c
011440B9    ldr w1, [x0, #0x14]
3FA00F71    cmp w1, #0x3e8
40020054    b.eq #0x7a45c
010840B9    ldr w1, [x0, #8]
3FA00F71    cmp w1, #0x3e8
E0010054    b.eq #0x7a45c
001840B9    ldr w0, [x0, #0x18]
1FA00F71    cmp w0, #0x3e8
81010054    b.ne #0x7a45c

Qualcomm:
41030054    b.ne #0x7a470
011440B9    ldr w1, [x0, #0x14]
3FA00F71    cmp w1, #0x3e8
E0020054    b.eq #0x7a470
010840B9    ldr w1, [x0, #8]
3FA00F71    cmp w1, #0x3e8
80020054    b.eq #0x7a470
001840B9    ldr w0, [x0, #0x18]
1FA00F71    cmp w0, #0x3e8
20020054    b.eq #0x7a470

Issue is the kernel is not booting, so I wonder if I did something wrong in the patch, my main concern is the last instruction as I didn't made it match exactly due to it being different in stock as well.

[siilike]

You should also check dm-verity. My bootloop on S9 was caused by it getting toggled after updating Magisk. Somehow managed to enable/disable it again via recovery.

cat /proc/last_kmsg will show you the last boot log where you can check what the issue was.

[siilike]

In case of dm-verity getting toggled it clearly states that it is the issue, which does not seem to be the case here.

[hektordaniel]

Hi all

I have found the same issue in Samsung S9 plus qualcomm with patched image, i have followed the procedure ( https://topjohnwu.github.io/Magisk/install.html ) four times. I have generate the patched image, after reboot I make the wipe as suggested, reboot and starts the bootloop.

mounts.txt
magisk_install_log_2024-01-14T22.20.53.log
magisk_log_2024-01-14T22.21.20.log

I have made multiple things and my conclusion is that patched image has something to be fixed. I have the phone to test, if you have any workaround or need some help to fix it just let me know. For the moment I put again the stock firmware.

thanks in advance

[wonkxin]

Device: Samsung Galaxy M51 (SM-M515F)
Android version: 12
Magisk version name: v26.1
Zygisk and Ramdisk: yes

Magisk v26.1 is the last version working on my device. v26.3, v26.4, v27 and DEBUG.APKs cause bootloops - direct flash as well as patched boot.img via Odin;

Log 1:
kmsg.log

Log 2:
kmsg.log

Log 3:
kmsg.log

[pewterbrass]

I want to tackle this issue.
I have a Samsung A12 (MTK6765), with the latest firmware (Android 12, patch level December 12, and binary 4 boot), which bootloops when flashing a custom vbmeta image.
There is a briefly text about vbmeta being invalid before rebooting.

When this happens, it's impossible to even boot into recovery, but Odin download mode works fine.
The device slips into KG state prenormal until flashing stock firmware and signing in to my Google account again.

Since it's not possible to extract latest_kmsg I'm sort of flying blind, but I think what happens is that the bootloader doesn't honor the bootloader unlocked state and refuses to boot neither boot nor recovery.

My question is, would it be possible to boot without flashing vbmeta or would the modified boot.img refuse to be booted? Otherwise I believe the non-patched vbmeta could be handled with kernel patches instead.

My goal right now is to extract and reverse the preloaded and the lk boot images to see what's going on, and if there is any way to bypass the vbmeta from there. Especially I believe the lk is responsible for the boot loop.

Does anyone else have any input or advice for me as I start on my journey?

[pewterbrass]

Some new information, testing on Samsung A12 (SM-A125F / MTK6765).

Apparently the LK step refuses to load a modified boot even when the bootloader is unlocked.
Neither erasing the vbmeta partition or stripping the AVB signature from boot.img makes any difference.

I tried patching the LK and flashing with mtkclient. It still boots when removing the AVB signature, however changing anything in the actual content of the lk-verified.img will cause the preloader to refuse to boot it.

It seems there is another place that image signatures are stored that doesn't use AVB / vbmeta, and it seems that place is a a partition called "btd".

I've been comparing the LK between a binary 1 and binary 4 SM-A125F, and sizewise there is quite a difference. I haven't seen any differences in most of the code that handles AVB verification. There seems to be some newer version of openssl, or some parts of openssl that wasn't included in the old LK, which could explain the increase in size.

Since the boot kernel is never started, it's not possible to get the logs, which makes this much harder to debug.

I'm hoping there is some way to get mtkclient to boot the preloader and LK in UART logging mode and get the printk messages that are written at early boot.

[pewterbrass]

I actually just spotted a difference in the check_secure_boot function.

I'll update this issue with more information when I've analyzed what the differences are.

[pewterbrass]

It was just a move of a parameter to the authinfo struct. So far no vital changes found.

[pewterbrass]

Well, finally found what probably causes the error.

In the U4 version of the bootloader (LK to be precise), a new function call has been added in check_secure_boot. If the image signature that is last in the partition, directly after SEANDROIDENFORCE, but before the avb footer, is incorrect, or as is the case for the Magisk patched boot.img, empty, the function is called. It will then call the secure world with five SMC calls, and logs something failing to set OEM flags if not successful. My guess is something goes wrong in the TEE, or it just decides to fail the boot.

There is no way around this, it will not be possible to boot a modified boot.img on an A12 with U4 firmware.

Unless the S9 is also a Mediatek device, I doubt that the A12 issues that led me here are actually duplicates.

[pewterbrass]

So I finally managed to get Magisk to work on a Samsung A12 (SM-A125F) with U4 binary level.

Sort of.

It needs to be started tethered using mtkclient, but then it's all good until the next reboot.

I've patched LK to accept any partition that has been modified. Flashing it with mtkclient (requires disassembly and reassemble of the phone one time).

Also flash your Magisk patched boot.img using mtkclient.
Also extract the preloader, or pull it from the firmware (the latter method requires some cut and paste in a hex editor though).

Once the LK partition has been flashed the phone will appear bricked when trying to start it. It will, however, fall back to BROM mode, which means the test point is no longer needed to run mtkclient, so the phone can be safely reassembled again.

There is a small bug in mtkclient that needs to be corrected (offsets in the patch below may be off):

@@ -508,7 +511,7 @@ class Main(metaclass=LogBase):

             if mtk.config.preloader_filename is not None:
                 self.info("Using custom preloader : " + mtk.config.preloader_filename)
-                mtk.preloader.setreg_disablewatchdogtimer(mtk.config.hwcode)
+                mtk.preloader.setreg_disablewatchdogtimer(mtk.config.hwcode, mtk.config.hwver)

To start the rooted device, simply run the following command:
python mtk plstage --preloader preloader_a12.bin --payload mtkclient/payloads/mt6765_payload.bin

So simple. :)

I can provide a bspatch for lk-verified.img if anyone is interested. You'll need it to succeed.

To conclude. There is something wrong in the TEE software responsible for booting the boot.img kernel (or at least allow booting of the kernel) after LK is done setting everything up. Even if the device is bootloader unlocked, the TEE will refuse to continue, and reboots the device.

It's not possible to fix this by software, so non-semi-tethered boot won't work.

You might as well close this issue as unfixable and put the details of why in a sticky or similar to avoid more bug reports.

[AToska21]

So I finally managed to get Magisk to work on a Samsung A12 (SM-A125F) with U4 binary level.

Sort of.

It needs to be started tethered using mtkclient, but then it's all good until the next reboot.

I've patched LK to accept any partition that has been modified. Flashing it with mtkclient (requires disassembly and reassemble of the phone one time).

Also flash your Magisk patched boot.img using mtkclient. Also extract the preloader, or pull it from the firmware (the latter method requires some cut and paste in a hex editor though).

Once the LK partition has been flashed the phone will appear bricked when trying to start it. It will, however, fall back to BROM mode, which means the test point is no longer needed to run mtkclient, so the phone can be safely reassembled again.

There is a small bug in mtkclient that needs to be corrected (offsets in the patch below may be off):

@@ -508,7 +511,7 @@ class Main(metaclass=LogBase):

             if mtk.config.preloader_filename is not None:
                 self.info("Using custom preloader : " + mtk.config.preloader_filename)
-                mtk.preloader.setreg_disablewatchdogtimer(mtk.config.hwcode)
+                mtk.preloader.setreg_disablewatchdogtimer(mtk.config.hwcode, mtk.config.hwver)

To start the rooted device, simply run the following command: python mtk plstage --preloader preloader_a12.bin --payload mtkclient/payloads/mt6765_payload.bin

So simple. :)

I can provide a bspatch for lk-verified.img if anyone is interested. You'll need it to succeed.

To conclude. There is something wrong in the TEE software responsible for booting the boot.img kernel (or at least allow booting of the kernel) after LK is done setting everything up. Even if the device is bootloader unlocked, the TEE will refuse to continue, and reboots the device.

It's not possible to fix this by software, so non-semi-tethered boot won't work.

You might as well close this issue as unfixable and put the details of why in a sticky or similar to avoid more bug reports.

yo, sorry to bother you but i want to do this on my A12 as it's the only device I can use for testing my custom ROMs and allat. can you provide the bspatch for lk-verified? (also how to apply it because i'm new to this :P)
thx in advance!

[yujincheng08]

#7665 only partially fixed. reopen.

[pewterbrass]

So I finally managed to get Magisk to work on a Samsung A12 (SM-A125F) with U4 binary level.

Sort of.

It needs to be started tethered using mtkclient, but then it's all good until the next reboot.

I've patched LK to accept any partition that has been modified. Flashing it with mtkclient (requires disassembly and reassemble of the phone one time).

Also flash your Magisk patched boot.img using mtkclient. Also extract the preloader, or pull it from the firmware (the latter method requires some cut and paste in a hex editor though).

Once the LK partition has been flashed the phone will appear bricked when trying to start it. It will, however, fall back to BROM mode, which means the test point is no longer needed to run mtkclient, so the phone can be safely reassembled again.

There is a small bug in mtkclient that needs to be corrected (offsets in the patch below may be off):

@@ -508,7 +511,7 @@ class Main(metaclass=LogBase):

         if mtk.config.preloader_filename is not None:

             self.info("Using custom preloader : " + mtk.config.preloader_filename)

•            mtk.preloader.setreg_disablewatchdogtimer(mtk.config.hwcode)
  

•            mtk.preloader.setreg_disablewatchdogtimer(mtk.config.hwcode, mtk.config.hwver)
  

To start the rooted device, simply run the following command: python mtk plstage --preloader preloader_a12.bin --payload mtkclient/payloads/mt6765_payload.bin

So simple. :)

I can provide a bspatch for lk-verified.img if anyone is interested. You'll need it to succeed.

To conclude. There is something wrong in the TEE software responsible for booting the boot.img kernel (or at least allow booting of the kernel) after LK is done setting everything up. Even if the device is bootloader unlocked, the TEE will refuse to continue, and reboots the device.

It's not possible to fix this by software, so non-semi-tethered boot won't work.

You might as well close this issue as unfixable and put the details of why in a sticky or similar to avoid more bug reports.

yo, sorry to bother you but i want to do this on my A12 as it's the only device I can use for testing my custom ROMs and allat. can you provide the bspatch for lk-verified? (also how to apply it because i'm new to this :P)

thx in advance!

I would strongly advise against doing this if you don't know precisely what you're doing.

Also, the patch will only work on a particular version (build) of the LK, and it's very likely not the one you are using on your device. You'd have to flash a specific A12 firmware to be sure.

[hmcdat]

any solution for this situation? The problem is still not fixed yet

[pewterbrass]

any solution for this situation? The problem is still not fixed yet

I don't think it can be fixed. There are unimplemented or unhandled SMC calls in the TEE that are triggered by LK as soon as it detects an invalid partition signature on boot, regardless of bootloader lock status.

[latuh]

Hmm... I've managed to "patch" on SM-A127F (not sure if fully) the boot.img by using Magisk v25.2 as v27 didn't work after many tries. Maybe Magisk is in the middle of all of this? Based on previous issue comments I've seen other people do it with similar versions up to v26.1, hence my question.

[latuh]

Upon further testing on my device (SM-A127F/DSN), the latest version of Magisk that manages to "patch" the boot.img is v26.3. Using v26.4+ results in bootloop. Flashed all the images with fastbootd thanks to ratcoded/fastboot-patcher to see if it made any change but everything remains the same as the Samsung method advised on the Magisk website.

[pewterbrass]

The 125 and 127 has different chipsets, and it seems your device might be affected by some change made to how magisk patches boot and vbmeta. I would use the GitHub interface and see what diff is between releases 26.3 and 26.4.

For 125 the execution never goes past LK (third bootloader stage).

[latuh]

If it is like that, all SM-A127F should have the same fix. About diffs in between 26.3 and 26.4, sure I know how to code and can understand the code to some degree, but I still don't comprehend it, I'm just some guy messing with his phone. If any developer needs something to fix this issue I'm willing to provide it.

By the way, should I make a new issue to address the SM-A127F error?

[pewterbrass]

By the way, should I make a new issue to address the SM-A127F error?

I'm not a Magisk developer, but I would assume you shouldn't open a new issue, as they've closed boot loop issues for many different Samsung devices and point to this issue.

By the way, the only thing I see that could affect the boot between 26.3 and 26.4 is this commit:

0243610

[latuh]

I'll compile a version w/o that change and see if it works, thanks for answering, I expected any answer would take several days.

[latuh]

Expanding on what I commented before, I can install Magisk with v26.3 using a patched boot.img, flash it through Odin or fastboot and works just fine, patching a boot.img with v26.3+ doesn't work and leaves the device on bootloop. After installing with Magisk v26.3 I can update the app to v27 and direct install Magisk, and it works just fine. So I'm guessing the error must be the commit that pewterbress linked before or related, as it is related to boot.img patching.