Magisk General Support / Discussion

[pndwal]

#1 is what I would love to have also, but have been unable to find any information anywhere how to do this. If one could download the OTA and have the standard "Update is available" process allow you to specify the downloaded OTA image, then the process @pndwal referred to at https://github.com/topjohnwu/Magisk/blob/master/docs/ota.md#devices-with-ab-partitions would allow the OTA update be applied with stock images restored, then use Magisk "install to inactive partition" be used *before* rebooting. In fact, my Moto Z3 is running PixelExperience ROM and I get streaming OTA updates on that phone, and follow @pndwal's referenced process without a hitch, each month.

I can't suss out why Google insists on "streaming" OTA updates, and forbid local OTA updates. I suspect the reasoning is based somewhat on they don't want to encourage rooting. Which I suppose is not unreasonable from their view, but if someone has a rooted phone/unlocked bootloader they have already voided their warranty, so IMHO it should be left to the owner of the phone to make these decisions.

Streaming updates are supposed to make for a seamless easy update experience for the user... Update uses little data and images are created on the fly from active partition blocks + any updated block data from delta OTA, and all while user still has access to phone... Reboots should also be very quick it all went well, and if not phone simply boots again to original slot...

There are various uses for full OTA images but these are really outside the purpose of the A/B seamless update engines purpose... PW

 

[tim1aust]

Streaming updates are supposed to make for a seamless easy update experience for the user... Update uses little data and images are created on the fly from active partition blocks + any updated block data from delta OTA, and all while user still has access to phone... Reboots should also be very quick it all went well, and if not phone simply boots again to original slot...

There are various uses for full OTA images but these are really outside the purpose of the A/B seamless update engines purpose... PW

Thanks PW. So I guess the "full" OTA updates that are downloadable from the Google site (and sideloaded) are different from what is served up for the streaming, "seamless update engine". I didn't know that. Still learning...
Tim

 

[badabing2003]

Update:

On a Pixel 5 device, I managed to have both slots bootable.
One slot rooted, and the other not, both on the same 2023-05 firmware.

The process is as follows (which PF will support OOB in the next release)
- Sideload full OTA
- Reboot to bootloader
- Flash patched image.
- reboot to system (observe root)
- Sideload full OTA
- Reboot to System (no patching, observe no root)
- Switch slot (observe root)

With Pixel 5, one is able to make changes to boot after sideload but before reboot.
It still needs to be tested if this works on Pixel 6, 7 * devices

I find flashing full OTA is slower than flashing full factory, but the benefit of having both slots bootable is a big bonus.

 

[Lughnasadh]

Update:

On a Pixel 5 device, I managed to have both slots bootable.
One slot rooted, and the other not, both on the same 2023-05 firmware.

The process is as follows (which PF will support OOB in the next release)
- Sideload full OTA
- Reboot to bootloader
- Flash patched image.
- reboot to system (observe root)
- Sideload full OTA
- Reboot to System (no patching, observe no root)
- Switch slot (observe root)

With Pixel 5, one is able to make changes to boot after sideload but before reboot.
It still needs to be tested if this works on Pixel 6, 7 * devices

I find flashing full OTA is slower than flashing full factory, but the benefit of having both slots bootable is a big bonus.

Okay, did some testing on my Pixel 6 Pro:

Started with:
Platform Tools 33.0.3
A14 Beta 2.1 (installed using flash-all.bat)
Rooted with Canary Magisk 26102
Active slot=b

Sideloaded the A14 Beta 2.1 OTA
Booted up
Not rooted (of course)
Active slot=a
Then rooted with Canary Magisk 26102

Switched slots to b
Did not boot (as expected)
Booted back into bootloader
Set slot back to a
Sideloaded the A14 Beta 2.1 OTA

Booted up
Not rooted
Active slot=b

Then switched slots to a and booted successfully
Slot a still rooted

Then switched slots to b and booted successfully
Slot b still not rooted

Then switched slots again back to a and booted successfully
Slot a still rooted

 

[badabing2003]

Okay, did some testing on my Pixel 6 Pro:

Started with:
Platform Tools 33.0.3
A14 Beta 2.1 (installed using flash-all.bat)
Rooted with Canary Magisk 26102
Active slot=b

Sideloaded the A14 Beta 2.1 OTA
Booted up
Not rooted (of course)
Active slot=a
Then rooted with Canary Magisk 26102

Switched slots to b
Did not boot (as expected)
Booted back into bootloader
Set slot back to a
Sideloaded the A14 Beta 2.1 OTA

Booted up
Not rooted
Active slot=b

Then switched slots to a and booted successfully
Slot a still rooted

Then switched slots to b and booted successfully
Slot b still not rooted

Then switched slots again back to a and booted successfully
Slot a still rooted

Thanks for the test, we can take advantage of this to carry to bootable slots,
I find it interesting that after flashing OTA, factory flashed slot was no longer bootable, that's a bit surprising considering that OTA could not have changed it.

 

[Lughnasadh]

Looks like after years & years of using flash-all.bat to update I'll now be sideloading the OTA instead.

 

[Lughnasadh]

Okay, did some testing on my Pixel 6 Pro:

Started with:
Platform Tools 33.0.3
A14 Beta 2.1 (installed using flash-all.bat)
Rooted with Canary Magisk 26102
Active slot=b

Sideloaded the A14 Beta 2.1 OTA
Booted up
Not rooted (of course)
Active slot=a
Then rooted with Canary Magisk 26102

Switched slots to b
Did not boot (as expected)
Booted back into bootloader
Set slot back to a
Sideloaded the A14 Beta 2.1 OTA

Booted up
Not rooted
Active slot=b

Then switched slots to a and booted successfully
Slot a still rooted

Then switched slots to b and booted successfully
Slot b still not rooted

Then switched slots again back to a and booted successfully
Slot a still rooted

Same test on my Pixel 7 Pro running A13 (May) with same results (this time I did not try to switch slots and boot into the slot that had the OS still installed via flash-all.bat (Step 2)

 

[Lughnasadh]

Same test on my Pixel 7 Pro running A13 (May) with same results (this time I did not try to switch slots and boot into the slot that had the OS still installed via flash-all.bat (Step 2)

On a side note, crap, forgot to disable verity and verification before booting up after each sideload

 

[badabing2003]

On a side note, crap, forgot to disable verity and verification before booting up after each sideload

Ouch, sorry to hear that, now you need a wipe?

So at what point you should have done that?
When flashing the patched image? just add the extra flags?

 

[shoey63]

On a side note, crap, forgot to disable verity and verification before booting up after each sideload

Did that affect anything?

 

[Lughnasadh]

Ouch, sorry to hear that, now you need a wipe?

So at what point you should have done that?
When flashing the patched image? just add the extra flags?

Yeah, if I want to run a custom kernel (Pixel 7) then I need to wipe. Should have sideloaded (not booted up), then gone into bootloader and run fastboot flash vbmeta --disable-verity --disable-verification vbmeta.img to that slot. Once booted after sideload/flashing the firmware it's too late as it's enabled after booting. Don't think it matters if you do it before or after flashing the patched image, just as long as you do it before you boot up. Oh well, lol...

Nothing to do with what we were testing, just custom kernel related. Seems to also help to avoid getting the red eio corrupt message when things may not go as expected.

 

[Lughnasadh]

Did that affect anything?

No. Only needed on the Pixel 7 series if you want to flash a custom kernel.

 

[badabing2003]

Yeah, if I want to run a custom kernel (Pixel 7) then I need to wipe. Should have sideloaded (not booted up), then gone into bootloader and run fastboot flash vbmeta --disable-verity --disable-verification vbmeta.img to that slot. Once booted after sideload/flashing the firmware it's too late as it's enabled after booting. Don't think it matters if you do it before or after flashing the patched image, just as long as you do it before you boot up. Oh well, lol...

Nothing to do with what we were testing, just custom kernel related. Seems to also help to avoid getting the red eio corrupt message when things may not go as expected.

Thanks, I realize it is only needed for custom Kernel cases.
I should add extracting vbmeta from payload.bin then in addition to boot.img / init_boot.img so that the step can be performed if the options are selected.

 

[roirraW "edor" ehT]

Update:

On a Pixel 5 device, I managed to have both slots bootable.
One slot rooted, and the other not, both on the same 2023-05 firmware.

The process is as follows (which PF will support OOB in the next release)
- Sideload full OTA
- Reboot to bootloader
- Flash patched image.
- reboot to system (observe root)
- Sideload full OTA
- Reboot to System (no patching, observe no root)
- Switch slot (observe root)

With Pixel 5, one is able to make changes to boot after sideload but before reboot.
It still needs to be tested if this works on Pixel 6, 7 * devices

I find flashing full OTA is slower than flashing full factory, but the benefit of having both slots bootable is a big bonus.

Same test on my Pixel 7 Pro running A13 (May) with same results (this time I did not try to switch slots and boot into the slot that had the OS still installed via flash-all.bat (Step 2)

Thanks for the test results and extremely fascinating information.

I wonder why, exactly, this works - presumably it's related to how the OTA treats the data that the factory image normally stores on the inactive slot. And it's also interesting that the full OTA and factory image would have different results.

Hopefully I notice the notes I've made on this the next time a Stable update comes out.

 

[sawdoctor]

Okay, did some testing on my Pixel 6 Pro:

Started with:
Platform Tools 33.0.3
A14 Beta 2.1 (installed using flash-all.bat)
Rooted with Canary Magisk 26102
Active slot=b

Sideloaded the A14 Beta 2.1 OTA
Booted up
Not rooted (of course)
Active slot=a
Then rooted with Canary Magisk 26102

Switched slots to b
Did not boot (as expected)
Booted back into bootloader
Set slot back to a
Sideloaded the A14 Beta 2.1 OTA

Booted up
Not rooted
Active slot=b

Then switched slots to a and booted successfully
Slot a still rooted

Then switched slots to b and booted successfully
Slot b still not rooted

Then switched slots again back to a and booted successfully
Slot a still rooted

So as well as making it easier to keep root with an ota we can have the same firmware on the device one rooted and one not? So if magisk hide/safetynet/etc aren't working we can boot to the non rooted firmware to use wallet/banking apps etc and then boot back to rooted. Or is it a bit more complicated than that? Never had a pixel device before

 

[badabing2003]

So as well as making it easier to keep root with an ota we can have the same firmware on the device one rooted and one not? So if magisk hide/safetynet/etc aren't working we can boot to the non rooted firmware to use wallet/banking apps etc and then boot back to rooted. Or is it a bit more complicated than that? Never had a pixel device before

I'm afraid that won't help you for that usecase.
Unlocked bootloader alone will trip the detection.

 

[sawdoctor]

I'm afraid that won't help you for that usecase.
Unlocked bootloader alone will trip the detection.

At least you can relock bootloader and go back stock I guess. On Sammy once you trip Knox that's it something's will never ever work again. Still a pia though

 

[pndwal]

I'm afraid that won't help you for that usecase.
Unlocked bootloader alone will trip the detection.

Well there are some apps that detect root only and don't complain about Play Integrity verdicts or B/L unlocked...

In the case of Starling:
https://forum.xda-developers.com/t/banking-app-starling-detecting-magisk.4576421/
dual boot to root/unrooted alternatively would be quite helpful since users apparently get a 2 week grace period after app detects root before app is disabled. Dual boot would allow them to log in fortnightly w/o root to continue using the app (even with root).

ATM there's no way (even with native bridge loading) to bypass Zygisk or Riru hooking/zygote injection detection, so many users are currently disabling Zygisk and using old p-trace MagiskHide implementations to hide root in order to log in once a fortnight.

PW

 

[pndwal]

At least you can relock bootloader and go back stock I guess. On Sammy once you trip Knox that's it something's will never ever work again. Still a pia though

There's no problem relocking on Samsung either...

You will lose special Samsung secure 'business platform' B2B (Business to Business) features (+ device enrollment for Knox solutions) incl. use of the Knox Security Container when Knox fuse (warranty bit) is blown.

Several Samsung apps and utilities use Knox Security so these will be also be broken including:
- Samsung pay*
- Samsung Pass
- Samsung Health
- Samsung Secure Folder
*Nb. There should be no issue for G Pay/Wallet.

I believe warrant may still be intact depending on local law, but in many lands the warranty will be voided.

Basically:

If the Knox bit has tripped:

• A new Workspace can no longer be created on such a device.
• The data encrypted and stored in an existing Workspace can no longer be retrieved.
• Other Samsung services that utilize Knox security stop working (Samsung Pay, Secure Folder.)

Everything else outside the Workspace should be the same as before.

https://docs.samsungknox.com/admin/knox-platform-for-enterprise/faq/

Likely most users never use the Knox enterprise features and might not need S Pay, S Health etc but need to realise that those features will be lost by flashing custom mods (not simply by unlocking bootloader)... Otherwise they can simply re-lock if and continue using device as before if they wish.

PW

 

[Lughnasadh]

So as well as making it easier to keep root with an ota we can have the same firmware on the device one rooted and one not? So if magisk hide/safetynet/etc aren't working we can boot to the non rooted firmware to use wallet/banking apps etc and then boot back to rooted. Or is it a bit more complicated than that? Never had a pixel device before

Others have already addressed your question, but for me, the biggest benefit here is to have a safety valve in place where your inactive slot is bootable (without first having to flash the firmware) in case you get into a hairy situation where your active slot becomes unbootable for whatever reason. May be useful in some situations.