Bootloop after ODIN flash (update) #6230
Comments
I have for the past 3 years with 2 different phones, never a problem. I use a usb flash drive to transfer de patched tar file and then flash with odin, i always check if file is corrupted. I'm using EUX, its the european union version |
This comment was marked as spam.
This comment was marked as spam.
|
I probably have the same problem with my Samsung Galaxy S22. With the current firmware (S901BXXU2AVH9 EUX, security patch level 01.09.2022) I get a bootloop after flashing the patched firmware. I patched the firmware like I always do (transfer AP file via ADB patch on my S22, pull the patched file via ADB and then flash the complete firmware with the patched file instead of AP). I tried with magisk 25200 and 25203. |
|
In case it helps, I'm also using a Galaxy S22 from the same region, and I did a full initial install of Magisk with the same latest firmware (S901BXXU2AVH9 EUX), and did not experience any boot loops. So, if what you're exeriencing is a bug or incompatibility issue with Magisk (and not an incorrect flashing procedure from the user), the problem is likely only related to upgrading the OS for an existing Magisk install. One thing that came to my mind: the Odin release version might affect the results, so could you tell which version did you use, @nemesis03? I did the initial install with Odin v3.14.1 (original/unpatched). When the next official firmware version arrives, I'll be doing the OS upgrade for the first time on my device, and report here about the results. |
|
I flashed patched tar created with magisk manager. then the boot got stuck and tried many times again without success so i flashed twrp to get logs and had to flash stock + wiping all data to boot again and after initial boot I flashed patched tar again for root and now it works but I did lose all my data. |
|
I used an Odin v3.14.4 from somewhere, now I also tried Odin v3.14.1 (original and patched) from xda-developer forum. With these two version also the same result: bootloops with the newest firmware version. |
|
I just tried to update to the recent firmware (S901BXXS2AVHD) with magisk, but again bootloops. |
|
same problem with my Samsung galaxy M31 |
This comment was marked as spam.
This comment was marked as spam.
|
I just tried an update to the latest firmware (S901BXXS2AVI7) and again had bootloops. @RV7PR @Igetin Did you manage to upgrade to newer magisk-patched firmwares without having to wipe the data partition? Does anyone know how to disable KEEPVERITY in magisk without having to manually patch the files? I tried "echo KEEPVERITY=false>>/cache/.magisk" and "echo KEEPVERITY=false>>/data/.magisk", but that did not change anything. Or any other idea why the bootloops happen and how to update to a newer firmware without having bootloops? Maybe @osm0sis has some ideas? |
|
Alright, I have now tried the upgrade for the Magisk-patched firmware, and I was able to successfully boot the new firmware after the flash. I upgraded from version S901BXXU2AVH9 to version S901BXXS2AVHD (EUX region). The user data is intact, and I did not have to perform a full wipe. As described in the documentation, I did the flashing process exactly the same as with my initial install, except for the fact that I used the This is how ODIN looked after the flashing completed. The phone rebooted to the normal "bootloader unlocked" warning screen, after which it went to the Galaxy logo screen, after which it showed "Erasing…" for a while (not sure what that means here) and rebooted again. Then it eventually went from the Galaxy logo screen to the "Optimizing apps…" screen and to the lock screen. The whole startup took a few minutes at most. My Magisk version is 25.2. Looking at your posts, you've used the same ODIN and Magisk version, have the same region model as I do, and also tried the same upgrade path that I did just now (*U2AVH9 → *S2AVHD). Our setup seems to be very similar, so I don't really have an idea why it's not working for you. 🙁 I can only suggest to triple-check the correct file selection in ODIN, but I suppose you have already done that. I hope you are able to find a solution! |
That sounds promising. I will probably do a full back up, then give it another try with the latest firmware (S901BXXU2BVJA, Android 13) and if that does not work wipe all data and restore from backup after upgrading to android 13. Might not be a bad idea to start with a wiped phone on android 13. It still bothers me that there is no real solution to this problem... |
|
Just did the upgrade with success with my Samsung Galaxy A53 (SM-A536B) PS: I'm getting OTA updates from samsung for about 3 months even though my bootloader is unlocked and I'm rooted, you guys get them too? |
|
probably the cause of the problems could be some module, because I really uninstalled all after failing and then it worked. |
|
Well.. I did use Magisk Bootloop Protector with patched boot image so I changed that to "basic function" (without patched boot image) just to be sure and then it worked but I'm not sure if it has anything to do with it. |
|
I finally solved this by wiping all my data. I did an upgrde to S901BXXU2BVJA (Android 13) and had bootloops. I then wiped the data and after that the device booted again. After setting up magisk I was able to upgrade to S901BXXU2BVKB without any issues. Unfortunately I had difficulties to restore my titanium backup, so I decided to downgrade to the last working firmware (S901BXXU2AVG6) and wipe data again. That was a bad decision, because I again was unable to update to a newer firmware. In the end I installed S901BXXS2AVHD and wiped data again, then restored my backups and then upgraded to S901BXXU2BVKB (Android 13) without issues.
|
|
I solved this for my device by only flashing boot.img in AP slot in Odin. Rooted now. |
|
Hi, i'm using a G975 (S10+) and experienced a similar boot loop without installing any update recently. Could this have the same cause as #6136 (that nemesis mentioned also)? Also @Igetin - you mentioned you successfully upgraded, did you ever experience a boot loop? @hyperio546 - you just used the same patched boot.img? |
I patched the boot.img of the new firmware and then flashed stock ap + bl + cp + home_csc and then boot.img separately. |
|
@hyperio546 Thanks for the quick answer! So, just to confirm for dummys like me: So, you
|
Nope, not once on this device. |
I did not have a bootloop. After flashing the stock firmware it seemed to boot and operate just fine. Then I flashed patched boot.img. I patched it on the same device before upgrading. |
It did not boot at all then, failing with the mentioned error message? |
It booted. Flashing patched AP files bootlooped it. |
|
If you haven't flashed a patched vbmeta image after unlocking your bootloader you must format your data partition in recovery mode in order to be able to boot again. |
@blackmesa123 |
It means that you gotta factory reset using the recovery. |
|
Thanks for your answer! But let me clarify: which factor do you see, that makes that necessary? I'm trying to understand, whether thats also the case for me.. |
What actually happens is that the Keymaster TA will fail to verify the data partition encryption key at boot. This is what normally happens: This is what happens when the key verification fails: So the only way to boot again in your device is either by reflashing the stock binaries or formatting the data partition in recovery in order to generate a new data partition encrypt key. |
|
Ah, i see. Thank you so much for your insightful descriptions and the example (kernel?) logs. By the way, to everyone helping android newbies like me (as well as silent watchers), thank you very much, you're the reason projects like this are so appealing to newcomers! |
I highly doubt that's the case, those are system logs since the keymaster service runs in system, not in kernel. |
You actually mean that flashing patched ap caused bootloops because of keymaster on my phone too? |
As I've explained, yes. It's better to call this a boot failure since this is not a bootloop at all. |
Then how did flashing patched boot.img work and I typing this from my rooted phone? |
Your phone probably already has a patched vbmeta image in place, without it you shouldn't even be able to pass the bootloader screen. You don't have to format your data partition every time you flash new stuff, just when switching from a stock vbmeta img to a patched one (according to my tests). |
I believe I am confused. The patched AP also has patched vbmeta and after flashing it I couldn't boot. But after flashing stock vbmeta inside of UNMODFIED AP and then flashing ONLY patched boot.img works. How?? |
This is very strange. Normally the bootloader will refuse to load any image if the hashtree doesn't matches, so a patched vbmeta is required. This is a bootloader log from my phone (Galaxy A52s 5G) with a patched vbmeta: Having some debug logs (last_kmsg) could help us understand why you are still able to boot with the old encrypt key even though you have installed a custom unsigned binary. |
How would I achieve that? |
At the end of the file there should be the current bootloader boot logs with every necessary info. |
Gives me no output! |
|
The output has been printed inside the |
last_kmsg.txt |
Still can't find a reason why the AVB checks pass anyway even though you're using a patched Magisk kernel image. I did download your phone's firmware and tested myself and the check does fail indeed. Stock kernel: ➜ A035F_fw avbtool verify_image --image vbmeta.img --follow_chain_partitions
Verifying image boot.img using embedded public key
vbmeta: Successfully verified footer and SHA256_RSA4096 vbmeta struct in boot.img
boot: Successfully verified sha256 hash of boot.img for image of 24666640 bytesMagisk patched kernel: ➜ A035F_fw avbtool verify_image --image vbmeta.img --follow_chain_partitions
Verifying image boot.img using embedded public key
vbmeta: Successfully verified footer and SHA256_RSA4096 vbmeta struct in boot.img
sha256 digest of boot.img does not match digest in descriptor
/home/mesa/bin/avbtool: Error verifying descriptor.It might just be how libavb is implemented in your SoC's bootloader (not correctly lol), yours is a lucky case. |
Sorry for coming again after so long but I just remembered that this phone was distributed by the government in my state and was loaded with work policies. I wasn't possible to change the wallpaper too. So this phones is not a normal one. |
|
Lines 126 to 127 in fe6b658 Nothing to do with Magisk. |
vvb2060
added
wontfix
Exceptions exist. Not all phones are same. Also this is your problem because I have been hit with the exact same problem too. |
As explained in #6230 (comment) this is normal and has nothing to do with Magisk since it is not a bug. Your case is different because your phone boots normally with AVB enabled even though it shouldn’t, which means there’s a bug in your phone’s bootloader which can be fixed by Samsung anytime. |
|
I also saw too late this was already noted in the install instructions, it may needs to be pointed out even better Line 115 in b9d0a3b |
I don't think that this is a bug. It shouldn't be able to boot into patched AP file because of hardware restrictions deep embedded into knox. As I pointed out before, its loaded with government knox policies. This is intended behaviour. But on the flip side yes its not related to Magisk. |
|
Was same here with updating my S22 Exynos from S901BXXU4CWCG to S901BXXU5CWEA via Odin. After updating I also got this How I fixed bootloop without losing data:
|
and others
Device: Samsung Galaxy A53 (SM-A536B)
Android version: 12
Magisk version name: 38325e7
Magisk version code: 25203
logs.zip
The text was updated successfully, but these errors were encountered: