Mostly I am talking about how the direct install failed. Maybe it was either just the Pixel or 25.0 failing, because of the new init thing. I did not install 25.0, because 25.1 was what popped up for update.
Yeah. Install to inactive slot always worked for Full OTA, but never for incremental.
I am unsure of what other issues could be causing this. Only guess was maybe I have to deactivate the "Systemless Hosts" module that Magisk installed. I am going to try again with OTA incremental and 25.1. Before I would have to restore old stock and factory reset (because of boot loop), than do the OTA before Magisk and setting things up. I just come here to see if anyone else is having this issue.
Your discussion with
@pndwal is getting very interesting.
Sorry if I did not properly catch-up the problem but some thoughts you (both) may think of:
AFAIK, problem with Systemless hosts applies only to (Pixel) devices with f2fs System/SAR - if your System is ext4 filesystem type, no problem.
You can check the filesystem type by eeading (before unrooting) /vendor/etc/fstab.*
Second, Uninstall Magisk (with/without Restore images) would uninstall all modules (incl. Systemless hosts) - wouldn't it?
In that case, manually uninstalling Systemless hosts before that step would not make any difference
Third, if I understand correctly, you are afraid now that due to Delta OTA, you cannot extract the new boot.img to be able to patch.
Also, you say that although you apply Uninstall Magisk (with Restore Images) before OTA but without rebooting, that you are still running root after the Delta OTA
Well, in that case you can disk-dump the Boot from that inactive slot, after the Delta OTA finishes.
For disk-dump you need root - you say you still have it (if I understood properly).
You need to know what's your current slot, hence execute (all from Terminal) and before starting OTA:
getprop ro.boot.slot_suffix
Suppose it returns _b, that means that before OTA, your active slot is B and that your OTA (full or incremental) would apply tothe inactive slot A
After the (incremental) OTA, disk-dump the boot_a.img (ie Boot img from the just OTA updated inactive A slot):
su
dd if=/dev/block/bootdevice/by-name/boot_a of=/sdcard/Download/boot img
You can patch now that boot.img (disk-dumped to Download folder on your Internal memory) by Patch method from the Magisk app
Finally, you need to disk-dump the patched img back to the still inactive slot A:
dd if=/sdcard/Download/<PATCHED IMG> of=/dev/block/bootdevice/by-name/boot_a
And then you are ready to reboot - reboot will switch from the slot B to slot A, that was just OTA updated with Magisk already patched and flashed to it's Boot partiition
---
Finally, I don't see why Magisk should be uninstalled before OTA on these A/B devices.
I know it's safer for many reasons but if you have full control of the situation (understanding how things work, modules you had installed and those potentially incompatible with the OTA), you could instead:
- Restore manually the stock boot.img by disk-dumping before OTA
- Disable only the critical modules before OTA
- After OTA updating and patching/disk-dumping the boot.img (in the still inactive slot) and after rebooting (where the updated slot now becomes active), you will boot and Magisk will be up and running with all (not-disabled) modules, previously granted root, DenyList) - it saves you a lot of time configuring all that once again.
Ie, Magisk database, modules, everything is on /data/adb and therefore it's not affected by OTA
---
Well, suggestions above are not by the Bible (TJW), but we should be able also to think and act out-of-the-box. And generally I like and did experiment a lot with the disk-dumping (I don't have Pixel and incremental OTA but anyway)
PW
MԀ
)
PW
