How To Guide Method to upgrade every month, without wiping data and retaining root

[roirraW "edor" ehT]

The two slots are updated and upgraded alternately every month.

If you take the actual Over The Air update, then this is true. If you manually update your phone, then it depends on which method you use to manually flash your phone, and one of the two OTA methods - the one that flashes the other slot, is very hit and mostly miss for working with Magisk. Magisk has removed support for it yet again because it's a buggy method.

Flash-All.Bat doesn't switch slots.

Sideload full OTA does switch slots.

Edit: See further posts on this page regarding suggestions to get Magisk working with the OTA other slot method.

 

[Homeboy76]

If you take the actual Over The Air update, then this is true. If you manually update your phone, then it depends on which method you use to manually flash your phone, and one of the two OTA methods - the one that flashes the other slot, is very hit and mostly miss for working with Magisk. Magisk has removed support for it yet again because it's a buggy method.

Flash-All.Bat doesn't switch slots.

Sideload full OTA does switch slots.

So, if I want to flash the Factory image and Magisk to the other slot each time I update the factory image. I should edit the flash-all.bat file:

* * * Edited flash-all.bat file * * *
...@ECHO OFF
PATH=%PATH%;"%SYSTEMROOT%\System32"
fastboot --set-active=other
fastboot reboot-bootloader
ping -n 5 127.0.0.1 >nul
fastboot flash bootloader bootloader-aaaaaaaaa-aaaaaaaaa-9.9-9999999.img
fastboot reboot-bootloader
ping -n 5 127.0.0.1 >nul
fastboot flash radio radio-aaaaaa-a9999a-999999-999999-a-9999999.img
fastboot reboot-bootloader
ping -n 5 127.0.0.1 >nul
fastboot -- skip-reboot update image-aaaaaa-tp1a.999999.999.zip
Note: I removed the -w to Keep Data.
fastboot reboot-bootloader
ping -n 5 127.0.0.1 >nul
fastboot flash boot magisk_patched-25203_AaAAA.img
fastboot reboot-bootloader
ping -n 5 127.0.0.1 >nul
echo Press any key to exit...
pause >nul
exit
* * * * * * * * * *

 

[roirraW "edor" ehT]

So, if I want to flash the Factory image and Magisk to the other slot each time I update the factory image. I should edit the flash-all.bat file:

* * * Edited flash-all.bat file * * *
...@ECHO OFF
PATH=%PATH%;"%SYSTEMROOT%\System32"
fastboot --set-active=other
fastboot reboot-bootloader
ping -n 5 127.0.0.1 >nul
fastboot flash bootloader bootloader-aaaaaaaaa-aaaaaaaaa-9.9-9999999.img
fastboot reboot-bootloader
ping -n 5 127.0.0.1 >nul
fastboot flash radio radio-aaaaaa-a9999a-999999-999999-a-9999999.img
fastboot reboot-bootloader
ping -n 5 127.0.0.1 >nul
fastboot -- skip-reboot update image-aaaaaa-tp1a.999999.999.zip
Note:I removed the -w to Keep Data.
fastboot reboot-bootloader
ping -n 5 127.0.0.1 >nul
fastboot flash boot magisk_patched-25203_AaAAA.img
fastboot reboot-bootloader
ping -n 5 127.0.0.1 >nul
echo Press any key to exit...
pause >nul
exit
* * * * * * * * * *

That looks exactly correct to me.

 

[card13]

One thing I noticed, and want to make others aware is when I upgrade monthly I have to re-root (this isn't the new part), but after re-rooting it causes the following hiccup: The Magisk Module "Audio Compatibility Patch" has to be reapplied every time you update the OS to re-apply the patches.

 

[Lughnasadh]

One thing I noticed, and want to make others aware is when I upgrade monthly I have to re-root (this isn't the new part), but after re-rooting it causes the following hiccup: The Magisk Module "Audio Compatibility Patch" has to be reapplied every time you update the OS to re-apply the patches.

Yeah, that sometimes happens with JamesDSP as well for me.

 

[TheDeliverator]

I just followed this method to update from the August patch (TP1A.220624.021) to the September patch (TP1A.220905.004). Everything (root included) was working fine on the Aug patch, but after following these steps to flash the Sept patch my phone will not turn on. This isn't a soft-brick or bootloop, the screen is fully dead and no combination of button holding so far has managed to get even a glimmer of life out of it.
More details:

• It's a brand new Pixel 6 Pro, pulled it out of the box two days ago and it hasn't experience any trauma or anything.
• After applying the patch, it tried to boot twice (made it to the google logo, displayed a progress bar), but failed, taking it back to the 'Bootloader is unlocked' screen. After this, it shut off entirely and there is no life in it whatsoever.
• The battery was at ~60% when I was performing the update, so a dead battery is unlikely to be the issue. Just in case I have it plugged in right now, but again no glimmer of life or anything.
• My computer doesn't seem to be able to recognize it when it is plugged in. I've tried adb, fastboot, and lsusb.

Any thoughts or words of wisdom, or do I just try and claim the warranty on this thing and hope they can't tell the bootloader was unlocked?

 

[Lughnasadh]

I just followed this method to update from the August patch (TP1A.220624.021) to the September patch (TP1A.220905.004). Everything (root included) was working fine on the Aug patch, but after following these steps to flash the Sept patch my phone will not turn on. This isn't a soft-brick or bootloop, the screen is fully dead and no combination of button holding so far has managed to get even a glimmer of life out of it.
More details:

• It's a brand new Pixel 6 Pro, pulled it out of the box two days ago and it hasn't experience any trauma or anything.
• After applying the patch, it tried to boot twice (made it to the google logo, displayed a progress bar), but failed, taking it back to the 'Bootloader is unlocked' screen. After this, it shut off entirely and there is no life in it whatsoever.
• The battery was at ~60% when I was performing the update, so a dead battery is unlikely to be the issue. Just in case I have it plugged in right now, but again no glimmer of life or anything.
• My computer doesn't seem to be able to recognize it when it is plugged in. I've tried adb, fastboot, and lsusb.

Any thoughts or words of wisdom, or do I just try and claim the warranty on this thing and hope they can't tell the bootloader was unlocked?

Did you have, at the minimum, the A13 bootloader flashed to both slots to avoid the new ARB shenanigans before trying to update? If not, it sounds like your device reverted to the inactive/A12 slot when it bootlooped and bricked your phone. From reports from this forum, Google has been pretty good at accepting RMAs when this has happened so I would try that route, unfortunately. Having your bootloader unlocked shouldn't matter to them.

 

[TheDeliverator]

Did you have, at the minimum, the A13 bootloader flashed to both slots to avoid the new ARB shenanigans before trying to update? If not, it sounds like your device reverted to the inactive/A12 slot when it bootlooped and bricked your phone. From reports from this forum, Google has been pretty good at accepting RMAs when this has happened so I would try that route, unfortunately. Having your bootloader unlocked shouldn't matter to them.

I did not, unfortunately, and yeah that seems to be the issue. Good to hear google will probably RMA this brick.

 

[mkhcb]

If you take the actual Over The Air update, then this is true. If you manually update your phone, then it depends on which method you use to manually flash your phone, and one of the two OTA methods - the one that flashes the other slot, is very hit and mostly miss for working with Magisk. Magisk has removed support for it yet again because it's a buggy method.

Flash-All.Bat doesn't switch slots.

Sideload full OTA does switch slots.

Since when did Magisk disable the OTA root other slot feature? I used this method for the Sept update.

 

[Lughnasadh]

Since when did Magisk disable the OTA root other slot feature? I used this method for the Sept update.

I am curious too. I've heard someone else say that support for this was removed for the Pixel 6 series , but I've searched through the commits and the changelogs and could not find any change relating to this. I know support was removed for Pixels a couple of years ago but was added back earlier this year. And their is no note in the documentation referring to support removal like there was when he removed it a couple of years ago.

It is, however, hit and miss for a lot of people.

OTA Upgrade Guides

The Magic Mask for Android

topjohnwu.github.io

 

[roirraW "edor" ehT]

Since when did Magisk disable the OTA root other slot feature? I used this method for the Sept update.

I was definitely going by what someone else said since I don't ever use an OTA method, as @Lughnasadh observed someone else said, too, but I don't know who it was (I thought it was @Lughnasadh! LOL!), and I've been so crazy busy in real life this week that I can't try to find the reference right now.

I'll try to get around to searching and let you know if I find it, if someone else doesn't find it first.

 

[Lughnasadh]

I was definitely going by what someone else said since I don't ever use an OTA method, as @Lughnasadh observed someone else said, too, but I don't know who it was (I thought it was @Lughnasadh! LOL!), and I've been so crazy busy in real life this week that I can't try to find the reference right now.

I'll try to get around to searching and let you know if I find it, if someone else doesn't find it first.

I think it was shoey63.

 

[shoey63]

I think it was shoey63.

Yeah it was me. Saw it posted in an issue on Magisk GitHub. Maybe they fixed it (again).
Will find out next month

 

[Lughnasadh]

Since when did Magisk disable the OTA root other slot feature? I used this method for the Sept update.

I'm curious. When you used this method to successfully update to the September build, did you have verity and verification disabled?

 

[mkhcb]

I'm curious. When you used this method to successfully update to the September build, did you have verity and verification disabled?

I disabled that back in the day.

I use to not be able to do the OTA successfully until I noticed that I needed to disable all modules before doing it.

 

[Lughnasadh]

Yeah it was me. Saw it posted in an issue on Magisk GitHub. Maybe they fixed it (again).
Will find out next month

Think I found the issue you were talking about. Don't see anyone has submitted a Pull Request for it though so it doesn't look like a fix is in the works. Since @mkhcb was able to successfully use this method for the September update, I'm wondering if there is a workaround that users can do if they wish to, such as disabling verity and verification and/or disabling all Magisk mods beforehand (per mkhcb's comment above). I also noticed in capntrips logs that there were a few verity and dm-verity errors.

I guess in the end it appears it still does work (since mkhcb used it successfully last month and I'm pretty sure I've seen a few others use it successfully in recent times, either in these forums or on another not to be named platform), but the right conditions have to be met. In practice, this means it won't work for the majority of users, as we have seen.

I guess if one were really interested they could disable verity and verification and see if it works. Possibly disabling verity alone since just disabling verity (without disabling verification) doesn't require a wipe. And disabling all Magisk mods.

Anyway...

 

[shoey63]

@Lughnasadh
Yep, that's the issue. Good job finding it
I have never disabled Verity or verification, so you may be on to something.
I'll try disabling Verity on next update and see if it works. . . .

Edit: Not confident though. The act of modifying the vbmeta partition may cause the OTA update to abort, as I'm pretty sure all partitions need to be untouched stock before it will proceed .

 

[Lughnasadh]

Edit: Not confident though. The act of modifying the vbmeta partition may cause the OTA update to abort, as I'm pretty sure all partitions need to be untouched stock before it will proceed .

Yeah, that very well could end up being the case. What is interesting, though, is that a few (2-3) people reported that they were able to update from A12 to A13 (via normal OTA, not the "Install to inactive slot" method) while rooted. Normally the OTA would fail because it would fail the pre-OTA block verifications because of being rooted . Of course they lost root afterwards, but they were at least able to successfully update while rooted. This makes me wonder of Google altered some of their pre-OTA verification checks. And if so, was it just for when upgrading from A12 to A13 or maybe applies to A13 in general? Normally I would have thought this was an "outlier" if 1 person reported this, but I remember at least 2 (maybe 3) reporting this.

Anyway, just thought I'd through that little tidbit into the conversation and I guess some of our questions may or may not be answered come October

 

[Dataman100]

FYI. I've used the method in the OP every time I've upgraded since I got the phone at launch, and I've not had any issues. I always disable verity and verification by adding the flags in flash-all.bat. I don't disable any Magisk modules before but I only have systemless hosts and USNF installed. After I installed A13, I reflashed the bootloader to both slots '--slot all' to be sure I didn't have an A12 bootloader anywhere. When I flashed the most recent update, I added the fastboot commands to switch to the other slot before flashing '--set active=other' as indicated earlier in this thread.

I hope that helps anyone having issues.

 

[Dataman100]

I can confirm that using the OP method, changing slots, disabling verity and verification, using Magisk (25203) worked with no issues for the Oct update. Best of luck to everyone!