• Introducing XDA Computing: Discussion zones for Hardware, Software, and more!    Check it out!

[GUIDE] Upgrade Beta to Android 12, *keep* root and data (no wipe!)

Search This thread

HumorBaby

Member
Oct 22, 2021
13
14
Google Pixel 5
It seems the trick is to manually sideload OTA upgrade, then flash vbmeta and patched boot image, all without rebooting in between.

Important Notes:​

  • DO NOT take the OTA directly from your phone's System Upgrade settings item.

  • This assumes you already wiped your phone once going from 11 to the 12 beta!
    In order to get root in 12b5 you had to flash the beta image with --disable-verification and --disable-verity which would force a wipe before you could boot the Magisk patched boot image.

    Other guides showed how to do this; e.g., https://forum.xda-developers.com/t/guide-flash-magisk-on-android-12.4242959/post-84605557



So, if you have already flashed the 12 beta with --disable-verification and --disable-verity, and currently have root, here is the general procedure:

Try to make sure you have the latest ADB binary before starting this.

  1. Download release factory AND OTA images from https://developers.google.com/android/images

  2. Extract vbmeta.img and boot.img from the factory image

  3. Patch boot.img using Magisk App on 12b5 phone and pull back to your PC

  4. sideload the OTA image. Then without reboot, switch to fastboot mode

    Bash:
    $ adb reboot sideload
    $ adb sideload redfin-ota-sp1a.210812.015-2596fc07.zip
    DO NOT REBOOT AFTER THIS!
    Once OTA upgrade is complete, you should be dropped into recovery menu.
    Pick "Boot to fastboot"
    Pick "Reboot to bootloader"
    Turns out we should flash vbmeta in bootloader, not fastbootd.

    The CRITICAL issue is to not allow the device to boot into system until vbmeta has been disabled. If this happens, a wipe will be required when it is disabled again.



    What I believe we have to do, as pointed out by @Anonshe , is that we have to reflash vbmeta in bootloader, not fastbootd - and we must not allow the kernel to boot until that is done. Meaning, directly following OTA sideload, immediately reboot into bootloader and reflash vbmeta to both slots with disable flags.

  5. flash vbmeta.img; make sure verity is disabled still (you already disabled it when you installed the 12 beta, remember?)
    Bash:
    $ fastboot --disable-verity --disable-verification flash vbmeta vbmeta.img
    STILL DO NOT REBOOT AFTER THIS!

  6. flash magisk_patched_boot.img

    Bash:
    $ fastboot flash boot magisk_patched-23001_XXXXX.img

  7. NOW you can reboot

    Bash:
    $ fastboot reboot
  8. Check your magisk, safetynet, gpay, etc.

  9. Optional: Reboot and check again if you want to really be sure, then breathe sigh of relief when root+data are still intact
 
Last edited:
Any insight on what exactly necessitates the wipe between 11 and 12?
At this point, a lot of guesses, but nothing has been pinpointed. We're basically at the point where we understand that there is a problem, we used to know how to get around it, but our method doesn't seem to work on 12 Stable.

So when the 12 Beta came out, it became quickly apparent that we couldn't just patch and flash the boot image like we had on Android 11. This caused a verification error in bootloader, that we figured out was caused by Android Boot Verification. Flashing /vbmeta with the --disable-verity and --disable-verification flags allowed us to flash /boot with a patched image, and all was well - at least for root. I'm not sure who, if anyone, was able to upgrade from 11 to 12 Beta without wiping /data.

Now on 12 Stable, it seems that we have a new problem - you can only boot without wiping data post upgrade if you leave everything stock. If you don't wipe, AND try to disable verity and verification, the kernel will begin to load, but then will reboot you into recovery with a data corruption message.

Why exactly this is happening is as yet unknown.

It's possible, even likely, that the boot image (which contains kernel and recovery) itself has some sort of boot verification that also must be disabled, most likely through modification of the image itself. Magisk used to have the capability to do this but it was removed some time ago.

It has been suggested that the bootloader is causing this, but the flaw in that theory is that everything passes the initial verification, and it's only when the kernel begins to load that we encounter the problem.

The really confusing thing is that this all seems to hinge on a data wipe. If you upgrade with a wipe, there's no issue disabling AVB and flashing a patched boot image. Doing the same thing post upgrade without a wipe causes the data verification error, but leaving everything stock works, and we are also able to temporarily boot patched images if /vbmeta and /boot are both untouched.
 

rester555

Senior Member
Oct 27, 2010
365
88
I really hope this doesn't necessitate a wipe after every monthly update since there is a new boot image every single month. That would really suck!
 
  • Like
Reactions: V0latyle
@HumorBaby I'd like to point out that this method only flashes the active slot, and you can't flash both slots from fastboot. You can switch slots in bootloader but that seems to break the whole deal. I'm not completely sure when the phone would switch slots anyway, most likely after an automatic OTA, so while this should work going forward, we'll have to ensure everyone knows to avoid the automatic OTA.

This is what I tried:
-Sideloaded OTA
-Entered fastboot, flashed /vbmeta and /boot
-Rebooted, confirmed I still had root
-Rebooted to bootloader, switched slots, rebooted to recovery, re entered fastboot
-Flashed /vbmeta and /boot again
-Rebooted, got dumped in recovery with the Corrupted Data message

I'm going to have to try everything all over again when I get home today. I'm using the same patched image with the same version of Magisk that worked before, but I don't have root for some odd reason.

I think what I'll do is start in fastboot, then reflash both a and b sides of everything with stock images - I wish we could do this via Android Flash Tool but force flash all partitions requires a data wipe.

Then, switch to slot A, reboot to recovery, apply OTA, enter fastboot, flash vbmeta with disable flags, flash patched boot, confirm successful boot and root.

Then, switch to slot B, and try to do the same thing.
 

HumorBaby

Member
Oct 22, 2021
13
14
Google Pixel 5
This is what I tried:
-Sideloaded OTA
-Entered fastboot, flashed /vbmeta and /boot
-Rebooted, confirmed I still had root

Any chance you (or anyone else) tried this for the Nov patch (sp1a.211105)
I tried it this AM and ended up having to wipe.

But I think this was because in my hurry I forgot to patch the boot image on my phone first, and didn't remember until I had sideloaded OTA and dropped to fastbootd. Then, I had to use my Magisk 23001 (same version I am currently running on Pixel 5) on my Pixel 2XL to patch the 5's boot image.

After flashing vbmeta and patched boot (using Magisk on Pixel 2XL), a reboot took me to a system that didn't have root. I am hoping this is because the boot image was patched on a Pixel 2XL and not a 5, and not because the OTA/slot-issues have once again required a wipe even for simple monthly updates 😿


I have just finished restoring and don't want to go through a series of wipe/install/tests if I don't have to .
 

HumorBaby

Member
Oct 22, 2021
13
14
Google Pixel 5
-Rebooted to bootloader, switched slots, rebooted to recovery, re entered fastboot
-Flashed /vbmeta and /boot again
-Rebooted, got dumped in recovery with the Corrupted Data message

I'm going to have to try everything all over again when I get home today. I'm using the same patched image with the same version of Magisk that worked before, but I don't have root for some odd reason.

I think what I'll do is start in fastboot, then reflash both a and b sides of everything with stock images - I wish we could do this via Android Flash Tool but force flash all partitions requires a data wipe.

Then, switch to slot A, reboot to recovery, apply OTA, enter fastboot, flash vbmeta with disable flags, flash patched boot, confirm successful boot and root.

Then, switch to slot B, and try to do the same thing.

Related to this (and my previous post), in order to try to salvage my failed root, I did exactly this: reboot to bootloader, switch slots, flash vbmeta and patched boot (patched on Pixel 5 this time). I had the same result: Corruped Data.

My point is: I have a feeling that switching slots is going to reset your "successful boot with disable-verity and disable-verification", which will once again force a wipe… i'm curious to see what you find, as if you do end up having to wipe, this would support my understanding/guess as to what the new bootloader that came with 12b5 (and onwarrds) is doing in regards to storing boot state (based on what I parsed from this section about AVB onward)
 
Any chance you (or anyone else) tried this for the Nov patch (sp1a.211105)
I tried it this AM and ended up having to wipe.

But I think this was because in my hurry I forgot to patch the boot image on my phone first, and didn't remember until I had sideloaded OTA and dropped to fastbootd. Then, I had to use my Magisk 23001 (same version I am currently running on Pixel 5) on my Pixel 2XL to patch the 5's boot image.

After flashing vbmeta and patched boot (using Magisk on Pixel 2XL), a reboot took me to a system that didn't have root. I am hoping this is because the boot image was patched on a Pixel 2XL and not a 5, and not because the OTA/slot-issues have once again required a wipe even for simple monthly updates 😿


I have just finished restoring and don't want to go through a series of wipe/install/tests if I don't have to .
Turns out we should flash vbmeta in bootloader, not fastbootd.

The CRITICAL issue is to not allow the device to boot into system until vbmeta has been disabled. If this happens, a wipe will be required when it is disabled again.

I successfully updated to the November patch exactly like this:

- Sideloaded the OTA in recovery, immediately rebooted to bootloader
- Flashed vbmeta:
Code:
fastboot flash vbmeta --disable-verity --disable-verification --slot=all vbmeta.img
I flashed to both slots because the OTA is typically an out of band update, and I wanted to be safe.
- Booted the patched boot image; got stuck on Google logo with loading bar, so forced reboot and allowed device to boot
- Rebooted to bootloader, booted patched image, confirmed root was working, performed Direct Install, rebooted again, root was retained.

Then, for the sake of proof, I dirty flashed the factory image through Android Flash Tool with verity and verification disabled, and let the device reboot into unrooted system. Rebooted to bootloader, flashed patched boot image, rebooted into rooted system.

As for losing root, it's possibly because you patched Magisk with a different device, as Magisk does leave a signature on the patch.

Try re-patching the stock boot image on the Pixel 5, then boot it and see if it works.
 
Last edited:
  • Like
Reactions: elong7681
Related to this (and my previous post), in order to try to salvage my failed root, I did exactly this: reboot to bootloader, switch slots, flash vbmeta and patched boot (patched on Pixel 5 this time). I had the same result: Corruped Data.

My point is: I have a feeling that switching slots is going to reset your "successful boot with disable-verity and disable-verification", which will once again force a wipe… i'm curious to see what you find, as if you do end up having to wipe, this would support my understanding/guess as to what the new bootloader that came with 12b5 (and onwarrds) is doing in regards to storing boot state (based on what I parsed from this section about AVB onward)
That method failed for me too.

What I believe we have to do, as pointed out by @Anonshe , is that we have to reflash vbmeta in bootloader, not fastbootd - and we must not allow the kernel to boot until that is done. Meaning, directly following OTA sideload, immediately reboot into bootloader and reflash vbmeta to both slots with disable flags.

Alternatively, you can dirty flash the system image with the disable flags.

This seems to be the trick. Once vbmeta has been disabled, it must be kept disabled, and if it gets reflashed without the disable flags for any reason, the device must not leave bootloader until it is disabled again, otherwise a wipe is required.

This is why the automatic OTA requires a wipe to re-root - because it writes /vbmeta without the disable flags, then reboots.

I don't see why switching slots would do it.
 
Last edited:

HumorBaby

Member
Oct 22, 2021
13
14
Google Pixel 5
Turns out we should flash vbmeta in bootloader, not fastbootd.
Yep, I realized that this may be the main culprit, since as you noted, OTA works by updating the non-current slot, then switches after a reboot.


What I believe we have to do, as pointed out by @Anonshe , is that we have to reflash vbmeta in bootloader, not fastbootd - and we must not allow the kernel to boot until that is done. Meaning, directly following OTA sideload, immediately reboot into bootloader and reflash vbmeta to both slots with disable flags.

Alternatively, you can dirty flash the system image with the disable flags.

This seems to be the trick. Once vbmeta has been disabled, it must be kept disabled, and if it gets reflashed without the disable flags for any reason, the device must not leave bootloader until it is disabled again, otherwise a wipe is required.
Thinking back and looking at the old ouput from my commands showed that OTA much has updated _a for me, but since I was in _b, fastboot flash vbmeta/patched-boot was put in _b. Then, reboot changed to _a, and a successful boot reset the verity flag and forced a wipe upon any subsequent actions.

My gut was telling me that I needed to be more aware/thoughtful of the slots as I was doing it, but I ignored it. Lesson learned.


Try re-patching the stock boot image on the Pixel 5, then boot it and see if it works.
I did try this once I realized I didn't have root, but at this point it was already too late since slot_a already booted without a disabled verity/verification.

I don't see why switching slots would do it.
Nope, just was floundering. Was hoping since I flashed vbmeta/patched boot into _b, a switch would get me root and bootloader would respect the disabled-verity during flash. However, knowing now that verity status is stored in userdata, it makes sense that it wouldn't work.
 
  • Like
Reactions: V0latyle
Yep, I realized that this may be the main culprit, since as you noted, OTA works by updating the non-current slot, then switches after a reboot.



Thinking back and looking at the old ouput from my commands showed that OTA much has updated _a for me, but since I was in _b, fastboot flash vbmeta/patched-boot was put in _b. Then, reboot changed to _a, and a successful boot reset the verity flag and forced a wipe upon any subsequent actions.

My gut was telling me that I needed to be more aware/thoughtful of the slots as I was doing it, but I ignored it. Lesson learned.



I did try this once I realized I didn't have root, but at this point it was already too late since slot_a already booted without a disabled verity/verification.


Nope, just was floundering. Was hoping since I flashed vbmeta/patched boot into _b, a switch would get me root and bootloader would respect the disabled-verity during flash. However, knowing now that verity status is stored in userdata, it makes sense that it wouldn't work.
Well..."A smart man learns from his own mistakes; a wise man learns from other's mistakes." I am by no means wise, so I don't blame you!
 

Top Liked Posts

  • There are no posts matching your filters.
  • 2
    It seems the trick is to manually sideload OTA upgrade, then flash vbmeta and patched boot image, all without rebooting in between.

    Important Notes:​

    • DO NOT take the OTA directly from your phone's System Upgrade settings item.

    • This assumes you already wiped your phone once going from 11 to the 12 beta!
      In order to get root in 12b5 you had to flash the beta image with --disable-verification and --disable-verity which would force a wipe before you could boot the Magisk patched boot image.

      Other guides showed how to do this; e.g., https://forum.xda-developers.com/t/guide-flash-magisk-on-android-12.4242959/post-84605557



    So, if you have already flashed the 12 beta with --disable-verification and --disable-verity, and currently have root, here is the general procedure:

    Try to make sure you have the latest ADB binary before starting this.

    1. Download release factory AND OTA images from https://developers.google.com/android/images

    2. Extract vbmeta.img and boot.img from the factory image

    3. Patch boot.img using Magisk App on 12b5 phone and pull back to your PC

    4. sideload the OTA image. Then without reboot, switch to fastboot mode

      Bash:
      $ adb reboot sideload
      $ adb sideload redfin-ota-sp1a.210812.015-2596fc07.zip
      DO NOT REBOOT AFTER THIS!
      Once OTA upgrade is complete, you should be dropped into recovery menu.
      Pick "Boot to fastboot"
      Pick "Reboot to bootloader"
      Turns out we should flash vbmeta in bootloader, not fastbootd.

      The CRITICAL issue is to not allow the device to boot into system until vbmeta has been disabled. If this happens, a wipe will be required when it is disabled again.



      What I believe we have to do, as pointed out by @Anonshe , is that we have to reflash vbmeta in bootloader, not fastbootd - and we must not allow the kernel to boot until that is done. Meaning, directly following OTA sideload, immediately reboot into bootloader and reflash vbmeta to both slots with disable flags.

    5. flash vbmeta.img; make sure verity is disabled still (you already disabled it when you installed the 12 beta, remember?)
      Bash:
      $ fastboot --disable-verity --disable-verification flash vbmeta vbmeta.img
      STILL DO NOT REBOOT AFTER THIS!

    6. flash magisk_patched_boot.img

      Bash:
      $ fastboot flash boot magisk_patched-23001_XXXXX.img

    7. NOW you can reboot

      Bash:
      $ fastboot reboot
    8. Check your magisk, safetynet, gpay, etc.

    9. Optional: Reboot and check again if you want to really be sure, then breathe sigh of relief when root+data are still intact
    1
    I really hope this doesn't necessitate a wipe after every monthly update since there is a new boot image every single month. That would really suck!
    1
    Any chance you (or anyone else) tried this for the Nov patch (sp1a.211105)
    I tried it this AM and ended up having to wipe.

    But I think this was because in my hurry I forgot to patch the boot image on my phone first, and didn't remember until I had sideloaded OTA and dropped to fastbootd. Then, I had to use my Magisk 23001 (same version I am currently running on Pixel 5) on my Pixel 2XL to patch the 5's boot image.

    After flashing vbmeta and patched boot (using Magisk on Pixel 2XL), a reboot took me to a system that didn't have root. I am hoping this is because the boot image was patched on a Pixel 2XL and not a 5, and not because the OTA/slot-issues have once again required a wipe even for simple monthly updates 😿


    I have just finished restoring and don't want to go through a series of wipe/install/tests if I don't have to .
    Turns out we should flash vbmeta in bootloader, not fastbootd.

    The CRITICAL issue is to not allow the device to boot into system until vbmeta has been disabled. If this happens, a wipe will be required when it is disabled again.

    I successfully updated to the November patch exactly like this:

    - Sideloaded the OTA in recovery, immediately rebooted to bootloader
    - Flashed vbmeta:
    Code:
    fastboot flash vbmeta --disable-verity --disable-verification --slot=all vbmeta.img
    I flashed to both slots because the OTA is typically an out of band update, and I wanted to be safe.
    - Booted the patched boot image; got stuck on Google logo with loading bar, so forced reboot and allowed device to boot
    - Rebooted to bootloader, booted patched image, confirmed root was working, performed Direct Install, rebooted again, root was retained.

    Then, for the sake of proof, I dirty flashed the factory image through Android Flash Tool with verity and verification disabled, and let the device reboot into unrooted system. Rebooted to bootloader, flashed patched boot image, rebooted into rooted system.

    As for losing root, it's possibly because you patched Magisk with a different device, as Magisk does leave a signature on the patch.

    Try re-patching the stock boot image on the Pixel 5, then boot it and see if it works.
    1
    Turns out we should flash vbmeta in bootloader, not fastbootd.
    Yep, I realized that this may be the main culprit, since as you noted, OTA works by updating the non-current slot, then switches after a reboot.


    What I believe we have to do, as pointed out by @Anonshe , is that we have to reflash vbmeta in bootloader, not fastbootd - and we must not allow the kernel to boot until that is done. Meaning, directly following OTA sideload, immediately reboot into bootloader and reflash vbmeta to both slots with disable flags.

    Alternatively, you can dirty flash the system image with the disable flags.

    This seems to be the trick. Once vbmeta has been disabled, it must be kept disabled, and if it gets reflashed without the disable flags for any reason, the device must not leave bootloader until it is disabled again, otherwise a wipe is required.
    Thinking back and looking at the old ouput from my commands showed that OTA much has updated _a for me, but since I was in _b, fastboot flash vbmeta/patched-boot was put in _b. Then, reboot changed to _a, and a successful boot reset the verity flag and forced a wipe upon any subsequent actions.

    My gut was telling me that I needed to be more aware/thoughtful of the slots as I was doing it, but I ignored it. Lesson learned.


    Try re-patching the stock boot image on the Pixel 5, then boot it and see if it works.
    I did try this once I realized I didn't have root, but at this point it was already too late since slot_a already booted without a disabled verity/verification.

    I don't see why switching slots would do it.
    Nope, just was floundering. Was hoping since I flashed vbmeta/patched boot into _b, a switch would get me root and bootloader would respect the disabled-verity during flash. However, knowing now that verity status is stored in userdata, it makes sense that it wouldn't work.