Magisk General Support / Discussion

[dl200010]

Finally, I don't see why Magisk should be uninstalled before OTA on these A/B devices.

The reason to restore the images is to make sure the soon to be inactive slot is stock for the next OTA update.

 

[zgfg]

The reason to restore the images is to make sure the soon to be inactive slot is stock for the next OTA update.

I know that VERY well - I said that you disk-dump the boot img manually ti restore stock

If you didn't install custom recovery, it is already stock (if not, flash/disk-dump the stock back)

SAR on A11/A12 is R E A D - O N L Y (Magisk makes makes only systemlessly changes!!!), hence complete SAR (System, Vendor, etc) is untouched by your previously installed Magisk

Magisk modules, db etc are on /data/adb and hence not part of OTA matters

I said, if you understand how these things work (particularly about the Systemless rooting mechanism), you don't need to Uninstall Magisk but instead to pinpoint what is necessary (hints above) manually.
If not, then go by the book...

I would personally kill myself
if I would have to reinstall and reconfigure everything, every time (lot of troubles with some of them to make them work or to properly configure), Viper4Android, Hide My Applist, etc

Therefore I ALWAYS just manually restore the Boot (and Recovery if needed), update the system, patch/flash the new Boot, and happily continue using the Magisk with all my previous modules and everything

But ok, if you are afraid of and/or unexperienced, go by the book

 

[BillGoss]

@dl200010
FYI, on the OnePlus 8T on OOS 11 there used to be two ways of updating:
1. Let the System Update download and install the OTA.
2. Manually download the OTA and then do a manual install in System Updater.
Using the first method your could not use Magisk Install to inactive. That always led to problems.
But the with second method, Magisk Install to inactive worked like a charm.
Now on OOS 12 there are still two options:
1. System update downloads and installs
2. Manually download the update and use a OnePlus apk that lets you do a manual install.
And these two options behave the same way as the OOS 11 versions.

It seems that the update_engine used by the two methods are different and behave differently.

I've written up the various options for rooting and keeping root with OTAs for the 8T. You might want to have a look at it and see if you can get ideas on what you can do for your OnePlus 9.

[GUIDE] Root and keeping root options

Update 240316: TWRP and OF work on OOS 14 A. First time rooting This process is common across all options A.1 Flashing Magisk patched boot image There are two ways to sourcing a copy of the stock boot image (other than using TWRP - See A.2)...

xdaforums.com

 

[pndwal]

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.*

F2fs loopback fixes were around in 2017... Huawei and Motorola were slow to fix kernel bug and seems loopback module and other fixes were needed for devices produced till late 2018... I believe Pixel fixed this in their kernels earlier...

I doubt very much this bug has made it into late OnePlus kernels.

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

No; Uninstall Magisk, Complete Uninstall does this, but Restore Images doesn't touch Magisk configuration files... It does:

make sure the soon to be inactive slot is stock for the next OTA update

by 'restoring partitions modified by Magisk back to stock from backups made at install in order to pass pre-OTA block verifications' however...

/data/avb configuration remains available till next Magisk installation and won't be rebuilt either...

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.

Basically because 1) delta OTA won't start if pre-OTA block verifications fail, and 2) boot (and other?) partition(s) has/have been altered by Magisk, so this will bork incremental update even on A/B since inactive slot patching is generated as a function of original active slot data and updated bytes from OTA...

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

And this is also the case with what he been doing! - Uninstall, Restore Images also leaves all this intact...

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)

I think you should be able to use Install to Inactive Slot to 'preserve Magisk after installation' on your A/B Xiaomi whenever an OTA arrives... There are clearly some anomalies w/ OnePlus, but generally the method is not restricted to Pixels. PW

 

[huskydg]

I tried data/ADB/magisk/ ./magisk32 --remove-modules, but that just caused the device to reboot, and didn't change the bootloop.

Duplicated of topjohnwu/Magisk#5788

 

[J.Michael]

The reason to restore the images is to make sure the soon to be inactive slot is stock for the next OTA update.

Maybe I'm misunderstanding your frame of reference, but if "next OTA update" means a future update, after the one you are trying to accept now, then I think the state of the currently-active-soon-to-be-inactive slot will be ignored in that not yet released future OTA update.

If by "next OTA update" you meant the update you are currently trying to accept, then excuse the ring.

 

[dl200010]

Maybe I'm misunderstanding your frame of reference, but if "next OTA update" means a future update, after the one you are trying to accept now, then I think the state of the currently-active-soon-to-be-inactive slot will be ignored in that not yet released future OTA update.

If by "next OTA update" you meant the update you are currently trying to accept, then excuse the ring.

You taking the current update depends on if you "restore images" the last time you updated. Because the inactive slot is the one taking the update. Not the current active one.

 

[J.Michael]

You taking the current update depends on if you "restore images" the last time you updated. Because the inactive slot is the one taking the update. Not the current active one.

Yes, the inactive slot will receive the update. But what it receives is a combination of the active slot and the OTA update. That's why its so important that you return the active slot to the state expected by the people who issued the update. cf. @pndwal's notes.

If you can download a file-set containing a full image of the updated ROM, then you can burn that to either slot. The only problem would be if the official update installer refuses to run unless it is satisfied with the "current" state.

In the case of an incremental update, which consists of records like "replace bytes 17 to 42 with these 92 new bytes", you can't even make sense of the update without the right starting state.

My quibble was with the word "next": if you are currently running v3, and are about to take v4, when you referred to being ready for the "next OTA update", did "next" mean v4 or v5?

 

[dl200010]

Yes, the inactive slot will receive the update. But what it receives is a combination of the active slot and the OTA update. That's why its so important that you return the active slot to the state expected by the people who issued the update. cf. @pndwal's notes.

If you can download a file-set containing a full image of the updated ROM, then you can burn that to either slot. The only problem would be if the official update installer refuses to run unless it is satisfied with the "current" state.

In the case of an incremental update, which consists of records like "replace bytes 17 to 42 with these 92 new bytes", you can't even make sense of the update without the right starting state.

My quibble was with the word "next": if you are currently running v3, and are about to take v4, when you referred to being ready for the "next OTA update", did "next" mean v4 or v5?

Yes, by "next" I meant v5.

If you are taking the v4, then currently active is v3 and inactive is v2. You need to restore v3 before installing v4, because when you take v5 v3 will be in inactive with a modified boot and that will fail checks and not install. Unless I am messing something.

 

[pndwal]

Maybe I'm misunderstanding your frame of reference, but if "next OTA update" means a future update, after the one you are trying to accept now, then I think the state of the currently-active-soon-to-be-inactive slot will be ignored in that not yet released future OTA update.

If by "next OTA update" you meant the update you are currently trying to accept, then excuse the ring.

Good catch!... John says 'The reason to restore the images' is as a prerequisite for available ('next') OTA...

When an OTA is available, first go to (Magisk app → Uninstall → Restore Images)...
This will restore partitions modified by Magisk back to stock from backups made at install in order to pass pre-OTA block verifications. This step is required before doing any of the following steps written below!

https://github.com/topjohnwu/Magisk/blob/master/docs/ota.md#prerequisites

You taking the current update depends on if you "restore images" the last time you updated. Because the inactive slot is the one taking the update. Not the current active one.

Yes, by "next" I meant v5.

If you are taking the v4, then currently active is v3 and inactive is v2. You need to restore v3 before installing v4, because when you take v5 v3 will be in inactive with a modified boot and that will fail checks and not install. Unless I am messing something.

But you are confusing ('messing') things a bit... v3 (inactive with a modified boot) will NOT fail the checks and cause a v5 OTA not to install! - The whole inactive 'slot' can in fact be blank and the OTA will succeed...

The active slot is NOT updated to accommodate a future OTA... Rather, data from active slot is used to generate images to be written to inactive slot in combination with data (binary patches) from the newly available OTA as has been explained... So the active slot is updated to accommodate the current/available OTA...

Of course, Restore Images simply restores current (active) slot to pre-magisk* images using image(s) from /data/magisk_backup_xxxxxxx*, but this is essential for current OTA...

Later OTA's will likewise rely on whatever slot is active at the time, NOT on the inactive slot being updated... In fact, this can be empty / blank / completely erased or corrupt and OTA will still succeed!

Details:

A/B system updates use a background daemon called update_engine to prepare the system to boot into a new, updated version. This daemon can perform the following actions:
• Read from the current slot A/B partitions and write any data to the unused slot A/B partitions as instructed by the OTA package.
• Call the boot_control interface...
• Run a post-install program from the new partition...

https://source.android.com/devices/tech/ota/ab#update-engine

An incremental update is an OTA package that contains binary patches to data already on the device. Packages with incremental updates are typically smaller as they don't need to include unchanged files. In addition, as changed files are often very similar to their previous versions, the package only needs to include an encoding of the differences between the two files.

https://source.android.com/devices/tech/ota/tools#incremental-updates

As mentioned, A/B update engine builds images for inactive slot using original block-verified images from active slot.

During incremental or delta updates, the binary data from the current slot is used to generate the data in the new slot.

https://source.android.com/devices/tech/ota/ab/ab_implement#configuration

*Nb. This further caveat from John is worth noting:

you HAVE to make sure you haven't modified an read-only partitons yourself (such as /system or /vendor) in any way. Even remounting the partition to rw will tamper block verification!!

https://github.com/topjohnwu/Magisk/blob/master/docs/ota.md#ota-upgrade-guides

PW

 

[dl200010]

Good catch!... John says 'The reason to restore the images' is as a prerequisite for available ('next') OTA...

https://github.com/topjohnwu/Magisk/blob/master/docs/ota.md#prerequisites



But you are confusing ('messing') things a bit... v3 (inactive with a modified boot) will NOT fail the checks and cause a v5 OTA not to install! - The whole inactive 'slot' can in fact be blank and the OTA will succeed...

The active slot is NOT updated to accommodate a future OTA... Rather, data from active slot is used to generate images to be written to inactive slot in combination with data (binary patches) from the newly available OTA as has been explained... So the active slot is updated to accommodate the current/available OTA...

Of course, Restore Images simply restores current (active) slot to pre-magisk* images using image(s) from /data/magisk_backup_xxxxxxx*, but this is essential for current OTA...

Later OTA's will likewise rely on whatever slot is active at the time, NOT on the inactive slot being updated... In fact, this can be empty / blank / completely erased or corrupt and OTA will still succeed!

Details:

https://source.android.com/devices/tech/ota/ab#update-engine


https://source.android.com/devices/tech/ota/tools#incremental-updates

As mentioned, A/B update engine builds images for inactive slot using original block-verified images from active slot.

https://source.android.com/devices/tech/ota/ab/ab_implement#configuration

*Nb. This further caveat from John is worth noting:

https://github.com/topjohnwu/Magisk/blob/master/docs/ota.md#ota-upgrade-guides

PW

So I was missing things. Thanks!

 

[m0han]

... you are confusing ('messing') things...

... I was missing things....

missing; not messing

 

[dl200010]

missing; not messing

Dyslexia, man.

 

[pndwal]

Dyslexia, man.

Pobody's nerfect... MԀ

 

[dl200010]

Pobody's nerfect... MԀ

I most definitely do not claim to be nor think I am. LOL. Strangely enough I have a BS from uni in Comp Sci, even though I have dyslexia.

 

[m0han]

I get the feeling this discussion has veered off course because of my comment made in jest (notice the wink). All I meant to opine was @dl200010 did not mess things, but missed things, leading to the confusion that @pndwal was alluding to.

 

[Néocray]

Hey there.
I have a Samsung S9 under Alexis Rom (based on OneUI 2.5).
When trying to update to Magisk 25.1, the direct install method leads to an error "unsupported boot image extra".
So I tried the patch images method. However, there was no “Patch vbmeta in boot image” option as described. So I let Magisk patch the original boot.img and flashed it.
It ended up to boot on a locked screen saying that the device is encrypted, which is not true. Moreover, the /data partition is readable in TWRP.

What have I done wrong?

EDIT: solved the issue with a backup of /data, then formatting it, then restoring the backup.
However, flashing again the 25.1 patched boot image resulted in bootloop: back to 24.3.

 

[rodken]

I'm stuck in a bootloop due to a module I installed (foxyboot?). I can boot normally with the stock boot.img and another boot image that gives me ADB root access.

I tried

adb wait-for-device shell magisk --remove-modules

but the device never established an ADB connection. So then I used the boot image that gives me ADB root, and I deleted /data/ADB/modules and modules_update. That didn't help. I tried data/ADB/magisk/ ./magisk32 --remove-modules, but that just caused the device to reboot, and didn't change the bootloop.

I can't install zips via TWRP currently.

Is it possible for me to just remove all the ADB files on the device eMMC and reinstall magisk manager? Where else is magisk storing files other than /data/ADB ?

For future reference:
-- Always take a working version of the latest Magisk and patch your boot.img
-- This ensures that you can flash and resort back in the event of a catastrophic event
-- Consider investing in installation of the Bootloop Saver.
-- Look into what the 'Magisk Manager for Recovery Mode' can do for you [if you have a working version of TWRP installed].

​

 

[sharpknight]

I just installed Magisk v25.1 on my LG V20 H990DS with stock oreo, and success without having kernel issues. But i can't opened the app itself (stuck on logo), but when downgrading the app to v23.0. It can be opened.

I am experiencing the same issue on my LG G7 ThinQ. I am able to install the Magisk v25.1 app but after the app install, the Magisk v25.1 app does not open. I just see the Magisk mask/face logo. I upgraded from v24.3. I'm able to downgrade back to Magisk v24.3 without problems.

 

[rodken]

I am experiencing the same issue on my LG G7 ThinQ. I am able to install the Magisk v25.1 app but after the app install, the Magisk v25.1 app does not open. I just see the Magisk mask/face logo. I upgraded from v24.3. I'm able to downgrade back to Magisk v24.3 without problems.

If Magisk is stuck on the splash screen:
-- Uninstall Magisk app and repatch your boot image.
-- If that doesn't work - Reflash your boot image and then patch the new boot image.