yashsingh1/xdaforums huggingface dataset:
[Magisk] dl200010:
I used to use a custom kernel, but haven't since going to the OnePlus 9. Otherwise I only install Magisk. I do not ever mount any partition as read/write except boot to install Magisk.

Yes, I forgot that step. I reboot from within Magisk.

I installed 25.1 App from within 24.3, and than direct install 25.1 into boot. I did not get any errors. So, should I restore image and direct install from 25.1 and reboot before OTA?

Last time I tried OTA and got a boot loop only 24.3 was out. I am asking questions before I go to update now, but I do have 25.1 installed. App and Boot. Since 25+ came with the fstab change, I doubt that was the issue before.
[Magisk] DiamondJohn:
OT But, one of the methods I use when using computer assisted translations, is to translate it to the other language (say French as my primary to English as my secondary) and then put that 2nd Language translation back into the translator, and translate it back into my original language, and see what is lost or broken in the translation. Then adjust my primary language text until both ways result in the exact same text ie nothing is lost or confused with the translator.
[Magisk] pndwal:
Bit further... It may be to do with OnePlus upgrade itself...

I notice Pixel 6 users report that Patching the Inactive slot after an OTA Update and rebooting results in a Bootloop currently:

Bootloop after OTA #5959

https://github.com/topjohnwu/Magisk/issues/5959

Perhaps your late OnePlus device is affected by an upgraded method too...

This issue is marked as wontfix, but vv comments:

https://github.com/topjohnwu/Magisk/issues/5959#issuecomment-1152869296

👀 PW
[Magisk] m0han:
or, one can use the 'switch' switch
[Magisk] dl200010:
I do not think this is the issue. I cannot flash any boot image and get it to boot again. I have to factory reset from recovery. It used to not be an issue, because full OTA update zips where available for the OnePlus 9, but now Oxygen Updater is telling me I have to do the incremental ones.
[Magisk] doniedogawa:
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.
[Magisk] pndwal:
You don't restore images for Direct install generally, although I hadn't considered "restore image(s) and direct install" before reboot... Is the option still there after Restore Images?... If so it may be useful if simply taking Direct Install fails...

I'd personally be giving Install to Inactive Slot from 25.1 another shot too...

Yes, my bad... Originally assumed Install to Inactive Slot was from 25.1 since you hadn't specified, and I hadn't caught up... PW
[Magisk] dl200010:
Yes, I know you do not generally restore the images for direct install, and I didn't do that when doing 24.3 -> 25.1. Maybe the failed install was caused by 25.0 not 25.1. I was thinking about that because that would flash stock boot and than install 25.1. This is all before doing the OTA incremental update.

But because I did not have any issue direct installing 25.1, I do not see how this would effect install to inactive slot anyways. Also, again I have had this issue before 25+ Magisk builds. When I had issue with it before I did grab the full update, used payload dumper to get all the IMG files, and flash all of them without factory reset. I still could not boot until I factory reset the device from recovery.
[Magisk] pndwal:
It's a current issue for Install to Inactive Slot... It's not an OTA issue per se.

You seem to be confusing the issue a bit...

The Install to Inactive Slot will work for both full and Delta OTA types; the difference is that Delta OTA's always require Restore Images step... Previously (if OnePlus actually delivered full ROM OTA package) this step may actually have been superfluous as the OTA can update the images without requiring the previous images to pass pre-OTA block verifications. The verification is needed as the A/B update engine combines expected binary from the active slot with Delta update (contains only changed bytes, not complete files) using a complex algorithm to generate images flashed concurrently to the inactive slot...

Further, generally custom ROMs use full package, and stock use Delta... PW
[Magisk] pndwal:
Since we got single-package Magisk (22+), Magisk (mask) is flashed from App package installed... If you had 25.1 App, 25.1 binary is flashed, not 25.0...

The issue for Pixel 6 I gave should make you think then... no issue direct installing 25.1, but Install to Inactive Slot is broken!... 🙃

So seems you faced / may be facing other (multiple) issues... PW
[Magisk] dl200010:
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.
[Magisk] pndwal:
Then I don't understand "Maybe the failed install was caused by 25.0 not 25.1"... 🤔

and AFAIK, Pixel always used Delta...

Are you talking about need for full data wipe needed in order to install Magisk after an OTA?... IIRC, late Pixels had this issue for a long while... If you're still facing this to boot w/ Magisk 25.1+ after OTA, please say...

Restore images, take incremental OTA, download full ROM matching OTA, extract boot image, patch/flash boot image should work without data wipes generally... PW
[Magisk] shoey63:
25.1 should work. If you are hesitant, then change to latest canary. Took an OTA incremental update with it the other day on Pixel 6. Android 13 beta 2 > beta 3.

Forget about your experience with 24.3. Didn't work for Pixels either, but there has many fixes since then.
[Magisk] dl200010:
It wasn't just 24.3, though, and not just android 12. I am going to do the update. I just don't like the hassle of going back to straight stock and incremental updating to latest than restoring all my apps. Neo Backup for the win! I will make sure to backup and sync everything to my PC before I do anything.
[Magisk] zgfg:
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)
[Magisk] dl200010:
The reason to restore the images is to make sure the soon to be inactive slot is stock for the next OTA update.
[Magisk] zgfg:
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
[Magisk] 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 240721: TWRP and Orange Fox do NOT work properly on stock OOS 14. See the discussion starting at https://xdaforums.com/t/guide-root-and-keeping-root-options.4387977/post-89610238 A. First time rooting This process is common across all...

xdaforums.com
[Magisk] pndwal:
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.

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

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

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

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

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
[Magisk] huskydg:
Duplicated of topjohnwu/Magisk#5788
[Magisk] J.Michael:
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.
[Magisk] dl200010:
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.
[Magisk] J.Michael:
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?
[Magisk] dl200010:
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.
[Magisk] pndwal:
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
[Magisk] dl200010:
So I was missing things. Thanks!
[Magisk] m0han:
missing; not messing ;)
[Magisk] dl200010:
Dyslexia, man.
[Magisk] pndwal:
Pobody's nerfect... 🙃 MԀ
[Magisk] dl200010:
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.
[Magisk] 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.
[Magisk] 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.
[Magisk] rodken:
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].

​
[Magisk] sharpknight:
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.
[Magisk] rodken:
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.
[Magisk] zgfg:
It's absolutely strange that Magisk APP is stuck, but do you have any ground that reinstalling Magisk (patch and flash the image) would help to the Magisk app?!

(It could be that something is wrong with Magisk db or so, and repatching and reflashing Magisk would not fix at all)
[Magisk] zgfg:
Magisk app is only like a UI Manager (remember it's previous name Manager?)

Magisk can work without the app - did you test if Magisk works?

Root: If you previously granted root to an app, does that app still works with root grants (it wouldn't if Magisk is not running)

Modules: Do you have any modules installed, then test if those modules still work

Command Line Interface: From terminal type magisk and read the help (man pages).

With the magisk command + options (all from Terminal), youu can investigate which version of Magisk is running, if Zygisk is active or not, etc (you can even manage DenyList and modules - not just check their status)

If you really did not make some mistake on your side, it would be more than worth to report as an issue to the Magisk GitHub. You would need Magisk Debug 25101 and its logs....

PS: When you say you install Magisk 25.1 and downgrade to 24.3, are you referring really to upgrading and downgrading Magisk (service/mask) or you only install Magisk app v25.1 and then back Magisk app v24.3?

And in that case, what is your procedure of upgrading and downgrading Magisk (I'm not asking about the app) - please describe
[Magisk] sharpknight:
I reverted to Magisk 24.3 and it appears to work. I have root access (my other root apps work).

Yes, all my root apps that previously had been granted root access work.

with terminal command: magisk -c

i get: 24.3MAGISK (24300)

with terminal command: magisk -v

i get: 24.3MAGISK

therefore it appears that i have Magisk 24.3

When I said I installed Magisk 25.1, I downloaded and installed the Magisk Manager 25.1 app. I obtained the app via the Magisk manager, but i also tried the apk from the Github. Both yield the same result where upon opening the Magisk Manager 25.1 app, I see the Magisk mask/face logo. Nothing else. I waited several minutes. SO technically? i was unable to install Magisk 25.1.

I was going to install Magisk 25.1 via the Magisk 25.1 by clicking "Install" and selecting the "Direct Install (Recommended)" option.
[Magisk] ipdev:
I missed the one that shows Zygisk status.

Can you nudge me in the direction of the command to check Zygisk. 👀

Cheers. :cowboy:
[Magisk] pndwal:
Sounds like your device has a separate vbmeta partition...

So have you tried with the optional step to disable verity/verification?:

(Optional) If your device has a separate vbmeta partition, you can patch the vbmeta partition with command:

fastboot flash vbmeta --disable-verity --disable-verification vbmeta.img

Note: pre 25.0 Magisk used to strip avb_key and avb verification flags for partitions in 2SI devices, but 25+ no longer does this since refactoring 2SI MagiskInit injection...

🤠 PW
[Magisk] pndwal:
Could be worth trying Canary apk or Debug...

User here reports that Stable 25.1 (frozen) behaviour is different, and Debug works... That should mean Canary will work also:

https://github.com/topjohnwu/Magisk/issues/6026#issuecomment-1165267294

Issue was closed and I can't confirm anything there... Hope it provides clues

Since user also reports differences in builds file structure (anomaly?), I'm guessing it could also (possibly) relate to this issue:

www.twitter.com/topjohnwu/status/1543440351460962305

... PW
[Magisk] zgfg:
You're right. I missed that currently even checking the Zygisk status is not supported through CLI

Feature request: Extend CLI to show Zygisk status · Issue #6064 · topjohnwu/Magisk

CLI supports a lot, eg (partially) managing modules and DenyList but seems that even Zygisk status Yes or No cannot be checked through CLI Even better, it would be good to additionally have the opt...

github.com
[Magisk] J.Michael:
It is going to be challenging to repatch the boot image after uninstalling the Magisk app.
[Magisk] zgfg:
It was recently shown/discussed in this thread how to use:

/data/adb/magisk/boot_patch.sh

to manually patch the (given) boot.ing
[Magisk] dohanin:
Hi, I suddenly found that while using a root explorer (Total Commander), there were only two folders and a link in /data/data, but in the past I could see all apps' data folders. Then I realised I recently had re-installed Magisk and just left the Mount Namesapce Mode as default (i.e. Inherit). After I changed it to Global, everything back to normal.

I just wanna ask, is this option only affecting the behaviour of those apps granted superuser access? Would it in any way affect root hiding?
[Magisk] BlekBomor:
Whenever i open magisk, it just gets stuck on its logo at the start. I have tried deleting and reinstalling it and even wiped chache and dalvik but it still didnt work. Please someone help me
[Magisk] zgfg:
Did you see the yesterday's post, just a single page back (an answer to the two reports like yours):

https://xdaforums.com/t/magisk-general-support-discussion.3432382/post-87114215