Restore images flashes an init_boot backup to the boot partition

[osm0sis]

Device: Pixel 8 Pro Android version: 14 (Stock) Magisk version name: b38ab2a7 Magisk version code: 27004

Steps to reproduce: 1) Ensure a fresh stock backup by deleting /data/magisk_backup, manually restoring stock init_boot, Direct Install 27004 then reboot. 2) See that there is indeed a new /data/magisk_backup directory with boot.img.gz. 3) Press Uninstall Magisk then Restore Images to see it fail with "Stock backup does not exist!"

Log excerpt:

07-14 00:35:33.024  9741  9741 I AppCompatDelegate: The Activity's LayoutInflater already has a Factory installed so we can not install AppCompat's
07-14 00:35:33.098  9741  9741 W TextView: onProvideContentCaptureStructure(): calling assumeLayout()
07-14 00:35:36.139  9741  9741 W WindowOnBackDispatcher: sendCancelIfRunning: isInProgress=falsecallback=android.view.ViewRootImpl$$ExternalSyntheticLambda11@3f11883
07-14 00:35:36.144  9741 11748 D HWUI    : endAllActiveAnimators on 0xb4000070f4697b20 (RippleDrawable) with handle 0xb4000072646d3d80
07-14 00:35:36.183  9741  9741 W WindowOnBackDispatcher: sendCancelIfRunning: isInProgress=falsecallback=android.view.ViewRootImpl$$ExternalSyntheticLambda11@1492c4d

Edit: Some progress was made with e6bd2ff but now the issue is that it shows "Restoration done!" but the image was never actually restored.

See https://github.com/topjohnwu/Magisk/issues/8211#issuecomment-2312285621

[osm0sis]

The rooted init_boot partition's .backup/.magisk contains:

KEEPVERITY=true
KEEPFORCEENCRYPT=true
RECOVERYMODE=false
PREINITDEVICE=sda10
SHA1=78100e19359f3debfbe35fa4c1f403d1c90191e6

And the backup is at /data/magisk_backup_78100e19359f3debfbe35fa4c1f403d1c90191e6/boot.img.gz

So those matching correctly should hopefully narrow the location of the fault down a bit.

[pixincreate]

I, for a moment, thought this to be GrapheneOS specific issue until I tumbled up on this and was debugging exactly that on my bluejay.

This issue persists from 27003 or even before that (I observed it back then).

$MAGISKTMP/.magisk/config contains:

KEEPVERITY=true
KEEPFORCEENCRYPT=true
RECOVERYMODE=false
PREINITDEVICE=sda8
SHA1=38490e1215550ba6b1dab02daf009400e32bcbce

and yes, SHA1 matches with the SHA1 of stock_boot.img

[osm0sis]

It was definitely working for me on 27002. I didn't test really with 27003 since it couldn't Direct Install while the app was hidden.

Edit: I quickly rolled back to 27003 unhidden to test and it restored images without issue, so this is confirmed a new regression as of 27004, at least on my devices.

[pixincreate]

Oh, I forgot to mention that I had created multiple tags between 27003 and 27004 in my version of Magisk, so might be one among them.

[Bennett-69]

It was definitely working for me on 27002. I didn't test really with 27003 since it couldn't Direct Install while the app was hidden.

Edit: I quickly rolled back to 27003 unhidden to test and it restored images without issue, so this is confirmed a new regression as of 27004, at least on my devices.

Still present in 27006, apparently. Glad I found this issue report before struggling any further, I just migrated from Kitsune-27003 to Magisk (Canary) 27006, and thought I'd screwed up the stock backup in the process. Hopefully this regression gets fixed at some point, or OTA updates are going to be a bit more of a PITA.

[OdinZhang]

any solution? seems doesn't affect OTA. my pixel 6 and 7 just updated to Android 15 beta 4.2 and I install magisk to another slot and it works

[Bennett-69]

any solution? seems doesn't affect OTA. my pixel 6 and 7 just updated to Android 15 beta 4.2 and I install magisk to another slot and it works

For whatever reason, my Pixel 8 Pro never even recognizes an OTA update is available for download until I (temporarily) uninstall Magisk by restoring images before checking, which is what's currently broken in 27004-27006.

[osm0sis]

any solution? seems doesn't affect OTA. my pixel 6 and 7 just updated to Android 15 beta 4.2 and I install magisk to another slot and it works

For whatever reason, my Pixel 8 Pro never even recognizes an OTA update is available for download until I (temporarily) uninstall Magisk by restoring images before checking, which is what's currently broken in 27004-27006.

That part is expected behavior. But yeah, no way to restore images right now except manually from these app regressions, which is frustrating.

[MikeBishop]

Any chance of a release to make this fix available?

[osm0sis]

I think he's edging closer to one. All the Pull Requests are cleared out as of today.

[RuofengX]

Same issue in 27007, is there a way to manually "mock" a backup file (I have my phone's stock init_boot.img file)?

[Bennett-69]

Same issue in 27007, is there a way to manually "mock" a backup file (I have my phone's stock init_boot.img file)?

If I remember correctly, simply (re-)installing Magisk using the Select and Patch a File method, should back up your stock init_boot.img file before patching it. If all you need is the backup, you can toss the patched file when you're done.

[osm0sis]

Same issue in 27007, is there a way to manually "mock" a backup file (I have my phone's stock init_boot.img file)?

No, it's confirmed resolved in 27007. You just likely actually don't have a stock backup present.

[osm0sis]

Oh wait, nope, now it'll show "Restoration done!" but next doing a Direct Install still shows "Magisk patched boot image detected", meaning the restore didn't actually happen. 🤔

@topjohnwu

[topjohnwu]

@osm0sis I tested the feature on my own device and it's working properly

[osm0sis]

I'll try again in the new Canary, but it's definitely not doing anything in 27007. It reports "Restoration done!" but doesn't actually restore.

[osm0sis]

Managed to brick my Pixel 8 Pro doing rapid fire Restore Images and Direct Installs, not sure exactly why/how, but anyway, seemed pretty clear that it was still broken exactly as I described 3 weeks ago, even with a fresh init_boot backup from the Magisk app: https://github.com/topjohnwu/Magisk/issues/8211#issuecomment-2312285621

Anyway, hopefully someone else can confirm the issue is ongoing, since I'll be out of commission for a while.

[Bennett-69]

Managed to brick my Pixel 8 Pro doing rapid fire Restore Images and Direct Installs, not sure exactly why/how, but anyway, seemed pretty clear that it was still broken exactly as I described 3 weeks ago, even with a fresh init_boot backup from the Magisk app: #8211 (comment)

Anyway, hopefully someone else can confirm the issue is ongoing, since I'll be out of commission for a while.

Okay, maybe I'm not crazy (regarding this issue, anyway). My experience still exactly parallels yours: Uninstall (Restore Images) claims to work, but subsequent Direct Install detects an already-patched image. And then after updating to 27008 and rebooting, my Pixel 8 Pro was also bricked ("boot failure," etc.) until I downloaded and flashed the latest factory (not OTA) image with no wipe. Like you, even flashing my previously-patched or stock init_boot didn't help, only the full factory image.

I'm back up and running 27008, but sure don't trust messing with its alleged uninstall and direct install yet.

[osm0sis]

Getting off topic, but even worse, I tried to fastboot set_active a while I was stuck in fastboot mode and that somehow hard bricked it to USB Serial Device (COM3) and no other signs of life. Wish I'd done what you did instead. Seems like RMA for repair is my only option now. 🤷‍♂️😢

Either way, sounds like there is in fact something still off with Restore Images, so I'll reopen this, and then perhaps also some investigation is warranted by the developers with either multiple subsequent Direct Installs, or perhaps with 27008 Direct Installed over itself, to see what's getting corrupted that would necessitate a Factory Image flash. If you wouldn't mind soft bricking yours again for science, you should try to see exactly which partition needed to be flashed to fix it, which might shed some light on the matter overall. 🤞

[canyie]

Just to be clear, can anyone confirm whether the bootloop happens only after restoring images? This sounds more than likely to be a new regression at magiskinit level 🤔

[osm0sis]

I definitely had updated 27007 to 27008 and rebooted with all working to that point, before testing out Restore Images and Direct Install led me to the bigger issues. Sounds like @Bennett-69 currently has 27008 running as well.

[canyie]

Ah, can confirm this issue. Restore image then dump /dev/block/by-name/boot and I can see the ramdisk is still magisk patched. After rebooting, magisk is still installed.

[canyie]

Re-checked the image from /data/magisk_backup and it seems the image is correct... Not sure how it fails...

[M-ls]

Maybe it's the same problem. I used magisk27008 version to restore the original image. My init_boot was mistakenly flashed into the boot partition. I downloaded the original package to extract the boot and flashed it manually, and it can boot correctly. He did not modify the init_boot partition. The above problem occurred on Meizu 20 and Meizu 21Pro

[osm0sis]

Something flashed to the wrong partition at some point was my guess for what happened to me, going to see if I can reproduce and confirm it when I get my warranty replacement Pixel 8 Pro. 🧐

[osm0sis]

I can confirm the boot failure after a single Restore Images attempt on my replaced Pixel 8 Pro, and that immediately flashing only the stock boot.img to the boot partition gets it working again. So, must be that Restore Images is sending the init_boot .img in the backup to the boot partition by mistake, and thus leaving init_boot partition rooted as previously noted.

[canyie]

It seems that the issue I faced on a Pixel 6a is different: Restoring image flashes nothing to the boot partition 🤔

[topjohnwu]

I might've used a device that's too old for testing. Let me try one with init_boot instead

[topjohnwu]

I believe the $SLOT variable is missing. In order to avoid any breakage down the line, let's just use the Java implementation for boot image detection

[osm0sis]

How could $SLOT being missing result in flashing to boot instead of init_boot on an A/B init_boot device?

[topjohnwu]

Missing slot will cause find_boot_image to find an incorrect partition name, which will most likely be boot_a

[vvb2060]

1fbd053a420b82ad629c4bed5d8f1a736d85618e