Can someone explain a/b and twrp simply - Moto G7 Power Questions & Answers

Can someone explain a/b and twrp simply - Moto G7 Power Questions & Answers

Is there a sticky about why twrp is so hard to tackle with this phone? If not, can someone explain the concept of the a/b stuff and how/why it affects the twrp process.?
Thank you!

motolio said:
Is there a sticky about why twrp is so hard to tackle with this phone? If not, can someone explain the concept of the a/b stuff and how/why it affects the twrp process.?
Thank you!
Click to expand...
Click to collapse
A/B is like having dual boot on a PC. The major difference here is the /data partition is shared with both slots. It makes everything a pain in the ass if you ask me.
For instance... You can keep two different operating systems on the device at once, but if the data isn't 100% compatible between both you're going to have a horrible time. I tried keeping stock on one slot, and using the other for GSIs. Sounds like a great idea but it really isn't. You have to format data if you switch.
This is where twrp problems also come in... Not so much twrp itself but Motorola I guess. On my current device at least, the G7 Play, Motorola is using something called "forward error correction". It makes it impossible for twrp to be installed on the same slot as the stock OS. It also makes it impossible for twrp to restore the stock OS. We have to flash the entire firmware and erase userdata. Everything works perfectly if a GSI is installed though. I don't know if that's a problem for the G7 Power but it is for us.
Another issue is that Magisk and twrp don't play nice with each other. I can't for the life of me get both installed at the same time. It's one or the other, but not both. That's because traditionally magisk was installed to the ramdisk of the boot.img. So when Google merged boot and recovery into one image, magisk went along with it. This wouldn't normally be an issue, but for reasons unknown to me (probably ota related), Topjohnwu decided to make Magisk have an off/on switch. Reboot to recovery, you get a system rooted with magisk. Reboot normally, no root. This breaks twrp because obviously you need to reboot into recovery for twrp to work. If it was designed so that you're rooted when you boot normally it wouldn't be a problem. Another solution is "system root", which only Phh has at the moment. It works great on his GSIs, but it's not an every day solution for stock.
I hope this is the kind of info your were after.

motolio said:
Is there a sticky about why twrp is so hard to tackle with this phone? If not, can someone explain the concept of the a/b stuff and how/why it affects the twrp process.?
Thank you!
Click to expand...
Click to collapse
In the post before some facts have been mixed up.
The Moto G7 Power is a A/B device. It has two slots (_a and _b) for every important partition such as /system, /vendor, /boot, /oem and some others. That means the device has them double.
What's the purpose and how does it effect the partition layout?
With a A/B device you can install an OTA update in background while your system is running as usual. You do not have to boot into recovery anymore to install it. While running on slot _a the update is being installed on slot _b. When the update is successfully installed you just reboot into the "new" OS on slot _b. The new boot slot will be set automatically by system.
For us, the users, this new concept is very handy because we can still use the device and don't have to wait. That's the purpose of a A/B device. But what has been changed?
Well, as I said before, you don't need a recovery for the update process. So Google removed the dedicated recovery partition and merged it into the boot partition or rather into the ramdisk of the boot partition. But where to flash TWRP now? To install TWRP you must override the stock recovery - inside the boot partition. Fastboot can't handle it since you need to unpack the boot.img, override recovery and repack the boot.img again. But fastboot has the option to boot any kernel from a external source, such as TWRP. And what a luck: TWRP contains terminal binaries to un- and repack a boot.img to install itself!
That's the reason why you have to boot TWRP first to install TWRP through TWRP!

WoKoschekk said:
In the post before some facts have been mixed up.
The Moto G7 Power is a A/B device. It has two slots (_a and _b) for every important partition such as /system, /vendor, /boot, /oem and some others. That means the device has them double.
What's the purpose and how does it effect the partition layout?
With a A/B device you can install an OTA update in background while your system is running as usual. You do not have to boot into recovery anymore to install it. While running on slot _a the update is being installed on slot _b. When the update is successfully installed you just reboot into the "new" OS on slot _b. The new boot slot will be set automatically by system.
For us, the users, this new concept is very handy because we can still use the device and don't have to wait. That's the purpose of a A/B device. But what has been changed?
Well, as I said before, you don't need a recovery for the update process. So Google removed the dedicated recovery partition and merged it into the boot partition or rather into the ramdisk of the boot partition. But where to flash TWRP now? To install TWRP you must override the stock recovery - inside the boot partition. Fastboot can't handle it since you need to unpack the boot.img, override recovery and repack the boot.img again. But fastboot has the option to boot any kernel from a external source, such as TWRP. And what a luck: TWRP contains terminal binaries to un- and repack a boot.img to install itself!
That's the reason why you have to boot TWRP first to install TWRP through TWRP!
Click to expand...
Click to collapse
So there is no stock recovery in a sence now?

roadkill42 said:
So there is no stock recovery in a sence now?
Click to expand...
Click to collapse
There's no separate partition for recovery, stock nor TWRP.
Sent from my Moto E (4) using Tapatalk

https://www.xda-developers.com/how-...ess-updates-affect-custom-development-on-xda/

Just came across this. https://www.androidpolice.com/2020/...tes-on-devices-launching-with-android-11/?amp
Sent from my [device_name] using XDA-Developers Legacy app

WoKoschekk said:
https://www.xda-developers.com/how-...ess-updates-affect-custom-development-on-xda/
Click to expand...
Click to collapse
Thank you! Exactly what I was looking for

Related

Booting TWRP Advice

HTCDreamOn said:
A word of advice: I strongly recommend temporarily booting any images (be it recoveries or kernels) you are about to flash to your device. This is simply a case of using the command "fastboot boot blahblah.img" whether blahblah.img is a recovery or kernel.
Click to expand...
Click to collapse
We know you can boot to TWRP vice flash to your device by using the command:
Code:
fastboot boot twrp.img
But how do you proceed from here? Are you required to use ADB commands at this point or can you unplug your USB cable and use TWRP as if it was installed, I.E. , back up current ROM, and install new zip.

purplepizza said:
We know you can boot to TWRP vice flash to your device by using the command:
Code:
fastboot boot twrp.img
But how do you proceed from here? Are you required to use ADB commands at this point or can you unplug your USB cable and use TWRP as if it was installed, I.E. , back up current ROM, and install new zip.
Click to expand...
Click to collapse
Sorry if I wasn't clear. Yes you can unplug usb and use as normal, it just means twrp isn't flashed to the device so it won't be there when you reboot.
I just recommend this step because I'm paranoid. Once you've confirmed the image works you should reboot to bootloader and fastboot flash the image, then you'll be able to boot into twrp whenever you want.

HTCDreamOn said:
Sorry if I wasn't clear. Yes you can unplug usb and use as normal, it just means twrp isn't flashed to the device so it won't be there when you reboot.
I just recommend this step because I'm paranoid. Once you've confirmed the image works you should reboot to bootloader and fastboot flash the image, then you'll be able to boot into twrp whenever you want.
Click to expand...
Click to collapse
This is a good step to do, and if the device supports it it should be used... for example the Moto G (if unlocked) fully supports fastboot boot commands, devices like the HTC One M7 do NOT support this anymore...
To the OP, what is really happening here is that TWRP or the boot.img (kernel) is being loaded from USB into RAM and executed normally, instead of the standard /boot partition which is skipped when executing fastboot boot. TWRP (and recovery in general) is really just a specialized micro-sized android distribution and when started via fastboot boot is executed as if it was the boot image. Once the image is transferred into RAM, the boot continues normally per the instructions of TWRP or the boot image, and no further action via USB is required. USB is just the medium to load the image into RAM and nothing more.
fastboot boot - used to manually load a boot image (or recovery) and execute from RAM, it is not flashed to the device, on the next reboot it will return to it's previous state
fastboot flash boot/recovery - used to actually flash the boot image or recovery image to the it's appropriate partition on the device, it does not execute it. On a reboot or factory default this information will stay in the device.

acejavelin said:
This is a good step to do, and if the device supports it it should be used... for example the Moto G (if unlocked) fully supports fastboot boot commands, devices like the HTC One M7 do NOT support this anymore...
To the OP, what is really happening here is that TWRP or the boot.img (kernel) is being loaded from USB into RAM and executed normally, instead of the standard /boot partition which is skipped when executing fastboot boot. TWRP (and recovery in general) is really just a specialized micro-sized android distribution and when started via fastboot boot is executed as if it was the boot image. Once the image is transferred into RAM, the boot continues normally per the instructions of TWRP or the boot image, and no further action via USB is required. USB is just the medium to load the image into RAM and nothing more.
fastboot boot - used to manually load a boot image (or recovery) and execute from RAM, it is not flashed to the device, on the next reboot it will return to it's previous state
fastboot flash boot/recovery - used to actually flash the boot image or recovery image to the it's appropriate partition on the device, it does not execute it. On a reboot or factory default this information will stay in the device.
Click to expand...
Click to collapse
Thanks. So it seems there is no reason to ever flash TWRP unless you don't want the PC dependence to use the TWRP tool.

purplepizza said:
Thanks. So it seems there is no reason to ever flash TWRP unless you don't want the PC dependence to use the TWRP tool.
Click to expand...
Click to collapse
Well, sort of... but the point is once you flash anything via twrp, you are no longer stock, so why not flash twrp to make it easier to flash other things?
The smartest thing would be to unlock, boot TWRP, make a nandroid backup before you do anything at all, then flash TWRP and do your thing...

acejavelin said:
Well, sort of... but the point is once you flash anything via twrp, you are no longer stock, so why not flash twrp to make it easier to flash other things?
The smartest thing would be to unlock, boot TWRP, make a nandroid backup before you do anything at all, then flash TWRP and do your thing...
Click to expand...
Click to collapse
I understand what you are saying. The only flash I planned on was SuperSU. I thought when a system upgrade is available, I could simply use SU to unroot and be ready for the update. Would this work?
If I followed your recommendation, could I feasibly, flash TWRP, then when an upgrade is ready, flash nandroid backup (which I assume removes TWRP) then accept system update, then re-flash TWRP. I could restore apps by using TB. Does this make sense? Or does TWRP remain in place after flashing nandroid backup?

purplepizza said:
I understand what you are saying. The only flash I planned on was SuperSU. I thought when a system upgrade is available, I could simply use SU to unroot and be ready for the update. Would this work?
If I followed your recommendation, could I feasibly, flash TWRP, then when an upgrade is ready, flash nandroid backup (which I assume removes TWRP) then accept system update, then re-flash TWRP. I could restore apps by using TB. Does this make sense? Or does TWRP remain in place after flashing nandroid backup?
Click to expand...
Click to collapse
TWRP remains in place after restoring a nandroid (I think, I haven't installed on my Moto G, but in most devices it doesn't backup/restore recovery), but you can easily restore the original recovery via fastboot.

acejavelin said:
TWRP remains in place after restoring a nandroid (I think, I haven't installed on my Moto G, but in most devices it doesn't backup/restore recovery), but you can easily restore the original recovery via fastboot.
Click to expand...
Click to collapse
Just curious, how did you go from 5.1.1 to 6.0?

purplepizza said:
Just curious, how did you go from 5.1.1 to 6.0?
Click to expand...
Click to collapse
OTA... part of soak test on December 22.

acejavelin said:
OTA... part of soak test on December 22.
Click to expand...
Click to collapse
Hey thanks for helping to answer this, your explanation was much better I thought it had something to do with loading into RAM but wasn't sure. I didn't know some devices don't allow fastboot boot commands though, I've always relied on them. Part of the reason I'm avoiding htc now.
@purplepizza I agree with everything acejavelin has said: essentially you really do want to make sure your have twrp flashed.
To answer your nandroid question: It basically just takes an image of the partitions you choose, usually /system, /data, and /boot (where kernel stuff is) which is the least you need to boot back with all your data. It doesn't backup recovery and when you restore it doesn't write anything to recovery, so yes twrp will still be in place. In general you should only ever flash stuff to the recovery partition whilst in fastboot mode (i.e. using fastboot flash recovery recovery.img), I know on some devices you can flash recoveries as zip files in the recovery itself but you shouldn't.
I've seen quite a few people querying about the 6.0 OTA: in short, I wouldn't worry about it because once they start rolling out, people always catch the OTA and post here on xda. You can flash that and it'll return you to stock 6.0 anyway, at which point you can reroot and everything if you want.

acejavelin said:
Well, sort of... but the point is once you flash anything via twrp, you are no longer stock, so why not flash twrp to make it easier to flash other things?
The smartest thing would be to unlock, boot TWRP, make a nandroid backup before you do anything at all, then flash TWRP and do your thing...
Click to expand...
Click to collapse
One more question, when making the first nandroid backup. do you just back up system and data or do you include boot as well?

purplepizza said:
One more question, when making the first nandroid backup. do you just back up system and data or do you include boot as well?
Click to expand...
Click to collapse
My opinion is always backup everything, you can always choose what to restore
Sent from my MotoG3 using Tapatalk

acejavelin said:
My opinion is always backup everything, you can always choose what to restore
Sent from my MotoG3 using Tapatalk
Click to expand...
Click to collapse
So what is boot? I know I am kind of going back to my previous question, but if I restore boot, is that the boot loader? I would assume this would not commonly need restored?
And I now assume the bootloader is completely independent from recovery.

purplepizza said:
So what is boot? I know I am kind of going back to my previous question, but if I restore boot, is that the boot loader? I would assume this would not commonly need restored?
And I now assume the bootloader is completely independent from recovery.
Click to expand...
Click to collapse
It is not the bootloader... It is the /boot partition of the phone, basically the kernel and RAM disk. If you screw things up and need to restore, you typically want to restore /boot, /system, and /data, and occasionally /cache (if you want to restore to save time and get an exact duplicate of the previous image, otherwise many people skip /cache and let it rebuild on the first boot which takes 10-15 minutes extra).

acejavelin said:
Well, sort of... but the point is once you flash anything via twrp, you are no longer stock, so why not flash twrp to make it easier to flash other things?
The smartest thing would be to unlock, boot TWRP, make a nandroid backup before you do anything at all, then flash TWRP and do your thing...
Click to expand...
Click to collapse
HTCDreamOn said:
@purplepizza I agree with everything acejavelin has said: essentially you really do want to make sure your have twrp flashed.
Click to expand...
Click to collapse
So I am following your advice. I booted to TWRP, made Nandroid backup.
Rebooted and flashed TWRP, see below:
Code:
sudo fastboot flash recovery twrp.img
target reported max download size of 268435456 bytes
sending 'recovery' (7772 KB)...
OKAY [ 10.635s]
writing 'recovery'...
OKAY [ 0.141s]
finished. total time: 10.776s
All seems OK.
Scrolled to recovery, selected recovery. TWRP was there. I then powered down.
After that I held power and volume down, system boots to dead Android with message “No command” Held power then volume up, I see stock boot loader. Is TWRP flashed somewhere or is it gone? So what did I do wrong.

purplepizza said:
So I am following your advice. I booted to TWRP, made Nandroid backup.
Rebooted and flashed TWRP, see below:
Code:
sudo fastboot flash recovery twrp.img
target reported max download size of 268435456 bytes
sending 'recovery' (7772 KB)...
OKAY [ 10.635s]
writing 'recovery'...
OKAY [ 0.141s]
finished. total time: 10.776s
All seems OK.
Scrolled to recovery, selected recovery. TWRP was there. I then powered down.
After that I held power and volume down, system boots to dead Android with message “No command” Held power then volume up, I see stock boot loader. Is TWRP flashed somewhere or is it gone? So what did I do wrong.
Click to expand...
Click to collapse
I have no idea, you did it right... selecting recovery from the bootloader should start TWRP, not stock recovery, that should be gone.

acejavelin said:
I have no idea, you did it right... selecting recovery from the bootloader should start TWRP, not stock recovery, that should be gone.
Click to expand...
Click to collapse
Any recommendations how to proceed?

I also need help with my soft bricked moto g3
Moto g3 (xt 1550, Indian dual sim 16 gb version)
I officially upgraded to 6.0.0 via ota and my objective was to root my phone and use xposed modules. I am not interested in any other custom rom (I'd rather keep stock rom just for moto display and ota upgrades) or custom recovery like twrp(I'm afraid it may cause ota upgrades to fail).
I used the method described here in the question- http://android.stackexchange.com/qu...rsu-using-play-store-versus-a-custom-recovery
So I first successfully unlocked my bootloader using the official motorola method.
I then proceeded to use google's backup settings to re-install all the apps that were uninstalled due to unlocking the bootloader. I also put supersu.zip version 2.46 on internal sd card.
I then proceeded to (without rebooting) enter fastboot where i used minimal adb to temporarily boot into twrp version2.8.7 r5 (link - http://forum.xda-developers.com/2015-moto-g/orig-development/twrp-twrp-moto-g-2015-t3170537 ).
Once in twrp, I located and flashed the supersu.zip. It flashed successfully. I procceded to clear dalvik cache and then after clearing cache I tried to reboot my phone using twrp.
However, it did not go beyond the "Warning - Bootloader Unlocked" screen that you get on unlocking a motorola bootloader. I left it for over 10 minutes (usb was still plugged in, I had >80% battery) but it did not proceed.
Long -pressing the power button causes the phone to vibrate and again attempt to boot, stuck at the same initial screen. Adb quite understandably does not work here.
I can press vol down+power and enter fastboot , where adb works fine.
I can enter stock recovery from the fastboot sceen too.
Using adb in fastboot, I am able to boot twrp . In fact, I tried to re-install supersu.zip. I retried version 2.46 and then tried version 2.56. On all occcassions, it was able to successfully flash it, but gets hung on the initial boot screen.
USB Debugging is also enabled, and I have a backp of my sd card data.
I tried taking a backup of the system and apps in twrp (3 gb in total) and tried to reflash it, but it still hangs at the same screen.
Is there any way I can unbrick my device and- (in decreasing order of preference)
1. Keep my stock rom and recovery?
2. Keep stock rom with twrp? (It should not be a problem)
3. Custom rom with custom recovery - perhaps official cm. Least preferred as I want Moto Display and stock/vanilla android.
Also, is SELinux involved anywhere with my phone getting bricked? I also read that a custom kernel is required for rooting 6.0, which I don't have. Supersu Version 2.56 is said to prevent soft bricks if the kernel is incorrect (systemless root), yet even after flashing the newer one it is still bricked. Where am I going wrong? What should I do? Thanks in advance! :good:

purplepizza said:
Any recommendations how to proceed?
Click to expand...
Click to collapse
Try the flash again? Sorry, but I don't really know help... if you are successfully rooted, perhaps try to flash TWRP image with Flashify? (select your file, don't let it auto-grab an image)

acejavelin said:
Try the flash again? Sorry, but I don't really know help... if you are successfully rooted, perhaps try to flash TWRP image with Flashify? (select your file, don't let it auto-grab an image)
Click to expand...
Click to collapse
I have not rooted yet. I guess I can try by booting TWRP then flashing SuperSU.
Can you think of any reasons not to try fastboot again the re-flash TWRP?

Dual Booting

Since this is a new setup for Android phones, I am trying to take full advantage of it. I already unlocked the bootloader and installed twrp. I was running under slot a and installed EX kernel and rooted. What I want to ultimately do is have slot A handle anything I want to use root for and slot B to be unrooted with EX kernel to hide the bootloader unlock. Now my question is should I be loading up both slots using adb and fastboot with stock images and then using twrp to install the kernels and root? I tried to install my backup into slot B from A and soft bricked my device. It refused to allow me to mount /system. After 20 minutes of fiddling, I got booted up again but before I try it again, I want to find out from someone who has already done this. Thank you.

so I successfully have the dual boot running on my pixel (verizon edition) with the same configuration you are trying (one is NDE63X image rooted and one is NDE63X image stock/unrooted). Here were my steps:
-> dePixel8 to unlock bootloader (because verizon edition pixel)
-> download NDE63X image from google and modified flash_all.sh to flash stock images to both slots manually
using the --slot _a/_b and --skip-secondary flags. Modified scripts below. At this point I confirmed that I could boot to both slots. I also verified bootloader lock/unlock again to make sure it was stock image on both slots
-> TWRP alpha2 to get recovery on both slots
-> with slot _b selected as active in TWRP, i installed the SuperSU v2.78 SR4 zip
-> with slot _a as active in TWRP, installed ElementalX-P-1.00 zip for the kernel patch to pass SafetyNet
voila, I now have non-rooted on slot _a and rooted on slot _b
Note that TWRP is not really a requirement for doing this. I had the same dual boot configuration working with SuperSU v2.78 SR3 rooting one slot directly. The only reason I needed TWRP is so that I can switch slots easily on the device and don't need a cable and a laptop just to switch the bootloader flag
Although, I got this to work it still falls short of what I really wanted to do. For my use-case I would really want an isolated userdata for the two slots so I can use the rooted slot as a complete sandbox. and then perhaps have a shared folder mechanism between the two. ...so if somebody has an idea on this, I'm all ears.
[UPDATE]: Note that the unrooted slot is still limited in the sense that safetynet checks fail and so AndroidPay etc.. that use that API will still not work. This, however, has little to do with the dual boot setup and more because SafetyNet now fails on just unlocked bootloader and we do need it unlocked. On Conchors' suggestion, I installed ElementalX kernel on slotA from TWRP and now my 'otherwise-stock' non-rooted image on slotA passes SafetyNet while slotB is successfully rooted
flash_all_slot-a.sh
Code:
fastboot flash --slot _a bootloader bootloader-sailfish-8996-012001-1608281716.img
fastboot reboot-bootloader
sleep 5
fastboot flash --slot _a radio radio-sailfish-8996-012511-1609191801.img
fastboot reboot-bootloader
sleep 5
#fastboot -w update image-sailfish-nde63x.zip
fastboot update --slot _a --skip-secondary image-sailfish-nde63x.zip
flash_all_slot-b.sh
Code:
fastboot flash --slot _b bootloader bootloader-sailfish-8996-012001-1608281716.img
fastboot reboot-bootloader
sleep 5
fastboot flash --slot _b radio radio-sailfish-8996-012511-1609191801.img
fastboot reboot-bootloader
sleep 5
#fastboot -w update image-sailfish-nde63x.zip
fastboot update --slot _b --skip-secondary image-sailfish-nde63x.zip

hucqym said:
so I successfully have the dual boot running on my pixel (verizon edition) with the same configuration you are trying (one is NDE63X image rooted and one is NDE63X image stock/unrooted). Here were my steps:
-> dePixel8 to unlock bootloader (because verizon edition pixel)
-> download NDE63X image from google and modified flash_all.sh to flash stock images to both slots manually
using the --slot _a/_b and --skip-secondary flags. Modified scripts below. At this point I confirmed that I could boot to both slots. I also verified bootloader lock/unlock again to make sure it was stock image on both slots
-> TWRP alpha2 to get recovery
-> with slot _b selected as active in TWRP, i installed the SuperSU v2.78 SR4 zip
voila, I now have stock on slot _a and rooted on slot _b
Although, I got this to work it still falls short of what I really wanted to do. For my use-case I would really want an isolated userdata for the two slots so I can use the rooted slot as a complete sandbox. and then perhaps have a shared folder mechanism between the two.
flash_all_slot-a.sh
flash_all_slot-b.sh
Click to expand...
Click to collapse
That is awesome and is exactly what I wanted to do. What I had tried doing was my original stock ROM was in slot A and I tried to fastboot another stock image into slot B. It immediately went into a boot loop in slot B. When I tried booting back to slot A, it also went into boot loop. Upon going into twrp, I found my system partition refused to mount. After several reboots and reinstalls of a backup I had done before I started playing with it, I got it to boot up again, but it was a brand new image instead of the backup which I tried to install. Upon the next reboot, both system and vendor would not mount, which is when I had enough and fastbooted the entire stock image.
Upon looking back at your modifications, I am curious if what happened is the stock image tried first to load into slot A even though I was in slot B, thus corrupting both my slots. Since the slot A I had at the time was rooted with EX kernel, flashing stock directly over it with no wipe is going to cause issues. I will try your changes tonight and get back to you with the results.

unless you use --skip-secondary, you are bound to affect the other slot while updating one. That is the standard behavior of the dual slot update process. If you see inside the update image, there is a system_other.img that gets flashed to the other slot. you can see that on the log output of the flash scripts too.
I found this article on the dual slot design very useful in understanding this.
Also make sure you are using the latest version adb and fastboot (I am using the latest that got updated with android studio/sdk bundle). I ran into some trouble earlier when I was using an older version of fastboot

hucqym said:
unless you use --skip-secondary, you are bound to affect the other slot while updating one. That is the standard behavior of the dual slot update process. If you see inside the update image, there is a system_other.img that gets flashed to the other slot. you can see that on the log output of the flash scripts too.
I found this article on the dual slot design very useful in understanding this.
Also make sure you are using the latest version adb and fastboot (I am using the latest that got updated with android studio/sdk bundle). I ran into some trouble earlier when I was using an older version of fastboot
Click to expand...
Click to collapse
Thank you very much for the tips. I have the latest adb and fastboot already so I am fine there. It is exactly like you said though on making the flash not affect both slots at once. I had not done a whole lot of research on the new dual slot setup yet and was just fiddling with it to see if I could do it myself. I knew with the bootloader unlocked I could always flash it back to stock with fastboot if I soft bricked it. I am going to look up that article tonight before I do the dual boot setup for myself. Never hurts to learn a bit more.

Does flashing bootloader remove TWRP? Or is that only in recovery?

Conchors said:
Does flashing bootloader remove TWRP? Or is that only in recovery?
Click to expand...
Click to collapse
flashing using my modified flash_all.sh does remove TWRP in the selected slot. You still can have TWRP in the other slot.
However, this is all of limited use, given SafetyNet now triggers false on even unlocked bootloader. Sigh!

hucqym said:
flashing using my modified flash_all.sh does remove TWRP in the selected slot. You still can have TWRP in the other slot.
However, this is all of limited use, given SafetyNet now triggers false on even unlocked bootloader. Sigh!
Click to expand...
Click to collapse
If I can reinstall TWRP than it shouldnt be an issue. Also, I'm running unlocked with the ElementX Kernel on my current setup and it keeps safetynet from triggering. My plan is to setup dual boot so I can have one slot for the un-rooted EX kernel for safetynet stuff and Root on the other slot.

Conchors said:
If I can reinstall TWRP than it shouldnt be an issue. Also, I'm running unlocked with the ElementX Kernel on my current setup and it keeps safetynet from triggering. My plan is to setup dual boot so I can have one slot for the un-rooted EX kernel for safetynet stuff and Root on the other slot.
Click to expand...
Click to collapse
ahaa. I must check out this EX kernel thingy then.
yes you can get TWRP back on both slots, no problem. tried and tested

hucqym said:
ahaa. I must check out this EX kernel thingy then.
yes you can get TWRP back on both slots, no problem. tried and tested
Click to expand...
Click to collapse
http://forum.xda-developers.com/pixel/development/kernel-elementalx-p-0-04-t3490086 That's for the small one.
Cool. Thanks! I'll give it a shot soon. I've got slot_a set up how i want, so I'll just flash b and su on that.

Conchors said:
http://forum.xda-developers.com/pixel/development/kernel-elementalx-p-0-04-t3490086 That's for the small one.
Cool. Thanks! I'll give it a shot soon. I've got slot_a set up how i want, so I'll just flash b and su on that.
Click to expand...
Click to collapse
your suggestion to install EX kernel worked. my SlotA now passes SafetyNet and androidpay works. Thanks

hucqym said:
your suggestion to install EX kernel worked. my SlotA now passes SafetyNet and androidpay works. Thanks
Click to expand...
Click to collapse
No prob. Thanks for the dual boot tutorial yourself

Update: I now have full dual boot on my phone. Once I became familiar with the slot command in fastboot, I see how easy it was to get it working. It is nice having the best of both worlds.

Following. Stock rooted with ElementalX kernel right now.
Don't care about Safetynet or Android Pay. Once more roms become available I'd like to dual boot 2 totally different roms.... Because Android.
Great info so far guys!
Sent from my Pixel using Tapatalk

Hey guys, since TWRP is capable of switching slots, couldn't we just make a full backup, switch slots, restore the backup, and reboot? Then you can go back and flash a rom or whatever to that slot.
Would any partitions be missing by doing this?
Sent from my Pixel using Tapatalk

Hey followers of this thread,. I just posted a new topic Here ,. and was wondering what solutions you all are using.

I thought SuperSU was made to install to both slots when flashed in TWRP? Or are you just using the boot to root method?

Hey, I'm just going through that dual boot thread and was wondering if you've come across any issues yet. I'm looking to have one rooted slot and one unrooted. I would like to have one stock slot in case I need safety net for an app like Android pay. The rooted for my many rooted apps and flashing Roms (if I can unlock bootloader and accomplish both objectives!). That's the idea, but just wanted to get any insight on how it has been working out and any major issues thus far.
Thanks a lot for the info in the thread thus far anyway.

zaksimmermon said:
I thought SuperSU was made to install to both slots when flashed in TWRP? Or are you just using the boot to root method?
Click to expand...
Click to collapse
Nope, TWRP installs to both slots, SuperSU will install to whichever boot slot is currently active. Same as Elemental-X kernel for instance.

Are there separate data partitions for each slot that contain user apps and app data or do the slots share that partition?
Shared would be great for a root/non root version of same rom but I could see that causing problems switching between custom Roms or different Android versions (similar to a dirty flash)...
Sent from my Pixel using Tapatalk

Installed TWRP to Boot, want to boot myself in the a**.

Own the OPP6; Rooted, on OxygenOS 5.18.
Went to install the newest TWRP (was going to install XXX no limits), when asked where to install it to, accidentally, without thinking, hit install to Boot.
Problems.
I can get into fastboot, the PC sees the phone in fastboot.
Have tried to flash a recovery image and similar, got an error saying: FAILED (remote: (recovery_b) No such partition).
Just want to get the phone booting again, wipe the whole thing start over, from fastboot.
Any help appreciated.

https://forum.xda-developers.com/oneplus-6/how-to/tool-msmdownloadtool-v4-0-international-t3798892

Thank you, the tool worked like a charm.
BTW: I did search and find other "methods" but none of them worked

noncomjd said:
Own the OPP6; Rooted, on OxygenOS 5.18.
Went to install the newest TWRP (was going to install XXX no limits), when asked where to install it to, accidentally, without thinking, hit install to Boot.
Problems.
I can get into fastboot, the PC sees the phone in fastboot.
Have tried to flash a recovery image and similar, got an error saying: FAILED (remote: (recovery_b) No such partition).
Just want to get the phone booting again, wipe the whole thing start over, from fastboot.
Any help appreciated.
Click to expand...
Click to collapse
What you should have done was fastboot boot twrp.img. which would start twrp, then you could have used the installer in to install twrp on phone. After that you would have to installed stock or custom kernel.

MrSteelX said:
What you should have done was fastboot boot twrp.img. which would start twrp, then you could have used the installer in to install twrp on phone. After that you would have to installed stock or custom kernel.
Click to expand...
Click to collapse
That is exactly what I wanted to do.
I could get into TWRP, but I couldn't see the phone on the PC and couldn't move files (ROM) to the phone (although fastboot was working and I could see the device using adb) but I couldn't figure out how to have TWRP look for or find the ROM on the PC.

There's no recovery partition on A/B phones remember.

RusherDude said:
There's no recovery partition on A/B phones remember.
Click to expand...
Click to collapse
Thanks for that. and that explains a few things and explains why when I installed TWRP, I didn't see the recovery option. Doesn't pardon my hitting install to Boot.
Just thought of another Q, if there is no recovery partition, where is the OEM recovery stored? (I figured the lack of a recovery partition is why TWRP gets overwritten if installed without a custom ROM)
I did a quick read on that, it seems really interesting and may be of some use as soon as I learn more.
I've got so much to learn about this. I keep meaning to take time to begin, but stuff comes up and boom more changes.
I've got to do more reading to take advantage of that.
@MrSteelX mentioned that I could have used TWRP to install a ROM from the PC.
Is this what is referred to as "sideloading". I've been looking for some info on this and haven't really come across much that is any good.
Are there any available guides that anyone can point to so I can learn about using TWRP that way?

noncomjd said:
Thanks for that. and that explains a few things and explains why when I installed TWRP, I didn't see the recovery option. Doesn't pardon my hitting install to Boot.
Just thought of another Q, if there is no recovery partition, where is the OEM recovery stored? (I figured the lack of a recovery partition is why TWRP gets overwritten if installed without a custom ROM)
I did a quick read on that, it seems really interesting and may be of some use as soon as I learn more.
I've got so much to learn about this. I keep meaning to take time to begin, but stuff comes up and boom more changes.
I've got to do more reading to take advantage of that.
@MrSteelX mentioned that I could have used TWRP to install a ROM from the PC.
Is this what is referred to as "sideloading". I've been looking for some info on this and haven't really come across much that is any good.
Are there any available guides that anyone can point to so I can learn about using TWRP that way?
Click to expand...
Click to collapse
In twrp, you go to advance/sideload. Twrp then waits for adb sideload to push file to phone then auto flashes file.
In your case, you would sideload rom to flash and have been go to go.

noncomjd said:
Own the OPP6; Rooted, on OxygenOS 5.18.
Went to install the newest TWRP (was going to install XXX no limits), when asked where to install it to, accidentally, without thinking, hit install to Boot.
Problems.
I can get into fastboot, the PC sees the phone in fastboot.
Have tried to flash a recovery image and similar, got an error saying: FAILED (remote: (recovery_b) No such partition).
Just want to get the phone booting again, wipe the whole thing start over, from fastboot.
Any help appreciated.
Click to expand...
Click to collapse
If you have working fastboot mode and getting detected via fastboot then
fastboot flashable stock rom via fastboot mode.
U don't have to do anything just downloaded zip file unzip it any folder u want. Connect u r phone to. Computer in fastboot mode
Then go to that folder and just click flash all bat waut for 10to 15 min and then phone boots in working oos.
(all data will be get wipes after this)
Link
https://www.google.co.in/amp/s/foru...m-stock-fastboot-roms-oneplus-6-t3796665/amp/

MrSteelX said:
In twrp, you go to advance/sideload. Twrp then waits for adb sideload to push file to phone then auto flashes file.
In your case, you would sideload rom to flash and have been go to go.
Click to expand...
Click to collapse
Thanks.
I will give this a try. After I learn a little more about the A/B partitions & recovery on this phone, I want to try one on the custom ROMs.

pankspoo said:
If you have working fastboot mode and getting detected via fastboot then
fastboot flashable stock rom via fastboot mode.
U don't have to do anything just downloaded zip file unzip it any folder u want. Connect u r phone to. Computer in fastboot mode
Then go to that folder and just click flash all bat waut for 10to 15 min and then phone boots in working oos.
(all data will be get wipes after this)
Link
https://www.google.co.in/amp/s/foru...m-stock-fastboot-roms-oneplus-6-t3796665/amp/
Click to expand...
Click to collapse
Thanks for the link/guide. I had been trying an iteration of this (and the guide) but after reading your link, it too explains some things. I was trying to restore a Stock ROM from fastboot according to your link:
Things are changing with the advent of project treble. OnePlus will no longer release ROMs flashable via recovery (either stock or twrp) because is no more needed. The updates will be done on the slot not used for example if you are using slot a the update will be installed on slot b and the slot b will be set as default. If you brick and you are in bootloop how you can restore the rom? You can't with Stock ROM you have, because the zip can be only installed via Update Engine, so what can you do? Flash a stock rom via fastboot. I have extracted all images from the stock zip and i have made a new zip with the Fastboot ROM with a flash-all.bat included. This will work only if your bootloader is unlcoked. This will erase all your data and will wipe
I download and was trying to use the stock ROMs, I didn't see any bats, and now I know why.
Lots more reading to do. I love doing playing with this stuff, but trying to learn & keep up with things burns time, which most days I don't have.
This is the longest I've ever been on a stock OS (6 weeks? got the phone right after its release) although it's rooted (can never leave things completely alone).

noncomjd said:
Thanks for the link/guide. I had been trying an iteration of this (and the guide) but after reading your link, it too explains some things. I was trying to restore a Stock ROM from fastboot according to your link:
Things are changing with the advent of project treble. OnePlus will no longer release ROMs flashable via recovery (either stock or twrp) because is no more needed. The updates will be done on the slot not used for example if you are using slot a the update will be installed on slot b and the slot b will be set as default. If you brick and you are in bootloop how you can restore the rom? You can't with Stock ROM you have, because the zip can be only installed via Update Engine, so what can you do? Flash a stock rom via fastboot. I have extracted all images from the stock zip and i have made a new zip with the Fastboot ROM with a flash-all.bat included. This will work only if your bootloader is unlcoked. This will erase all your data and will wipe
I download and was trying to use the stock ROMs, I didn't see any bats, and now I know why.
Lots more reading to do. I love doing playing with this stuff, but trying to learn & keep up with things burns time, which most days I don't have.
This is the longest I've ever been on a stock OS (6 weeks? got the phone right after its release) although it's rooted (can never leave things completely alone).
Click to expand...
Click to collapse
I have to unzip the downloaded fastboot ROM at any folder on computer and open that folder u will see named [flash all bat]
Now connect phone in fastboot mode to computer and just click [flash all bat] file

noncomjd said:
Thanks for that. and that explains a few things and explains why when I installed TWRP, I didn't see the recovery option. Doesn't pardon my hitting install to Boot.
Just thought of another Q, if there is no recovery partition, where is the OEM recovery stored? (I figured the lack of a recovery partition is why TWRP gets overwritten if installed without a custom ROM)
I did a quick read on that, it seems really interesting and may be of some use as soon as I learn more.
I've got so much to learn about this. I keep meaning to take time to begin, but stuff comes up and boom more changes.
I've got to do more reading to take advantage of that.
@MrSteelX mentioned that I could have used TWRP to install a ROM from the PC.
Is this what is referred to as "sideloading". I've been looking for some info on this and haven't really come across much that is any good.
Are there any available guides that anyone can point to so I can learn about using TWRP that way?
Click to expand...
Click to collapse
"recovery" (what's left of it... wipe and mostly nothing else) is inside the boot partition. TWRP on those devices is installed into the boot partition (NOT overwriting the boot partition, but into the "ramdisk", a part of the kernel where OEM recovery resides and where TWRP, Magisk, Xposed and all the mods do their stuff on the kernel. On a phone with A/B partitions, you have to fastboot BOOT twrp, and then you have to flash the installer zip, you should never ever flash the image to any partition since there isn't any.

RusherDude said:
"recovery" (what's left of it... wipe and mostly nothing else) is inside the boot partition. TWRP on those devices is installed into the boot partition (NOT overwriting the boot partition, but into the "ramdisk", a part of the kernel where OEM recovery resides and where TWRP, Magisk, Xposed and all the mods do their stuff on the kernel. On a phone with A/B partitions, you have to fastboot BOOT twrp, and then you have to flash the installer zip, you should never ever flash the image to any partition since there isn't any.
Click to expand...
Click to collapse
Thanks for the information.
and this is what I did, originally I thought I had accidentally selected the wrong partition, but it seems since there is no recovery partition, I did it wrong from the start.
Q: I'm guessing this is why when you do load TWRP (the correct way, which I did once, following a guide) without a custom ROM (still using Oxygen OS) that the OEM recovery overwrites TWRP or the OEM recovery is called up at the next reboot into recovery?
Q: I understand, at least in theory the benefit of the A/B partitions, what is the benefit of eliminating the recovery partition other than giving more control of the phone to the OEM and OS? Is this setup limited to the stock kernel or mandated to be copied by any potential replacement kernels (this information is new to me, I haven't yet read up on kernels).

Fixing a trashed "A" boot partition

My device is a rooted, TWRP-enabled OnePlus 7 Pro ... GM1917.
Through some failed flash attempts in the past, I hosed my "A" boot partition, meaning that I can't boot into it, nor do any meaningful work in it via TWRP. The data partition is empty and cannot be written to when I boot into TWRP via the "A" partition. My "B" partition is fine, and my device is running fine with that partition active.
Is there any way to get my "A" boot partition back to being properly functional without messing up my current device configuration? For example, one question I have is this: if I format the data partition in TWRP when I'm booted into the "A" partition, will it format the working data partition that I see when I boot into "B", thereby causing me to lose everything that is currently resident on this data partition?
I don't have a good understanding of the A/B boot partition methodology, so any help will be greatly appreciated.
.

I think you should do a clean factory reset
https://forums.oneplus.com/threads/...ide-for-a-hard-bricked-oneplus-7-pro.1041896/

sonvotrung said:
I think you should do a clean factory reset
https://forums.oneplus.com/threads/...ide-for-a-hard-bricked-oneplus-7-pro.1041896/
Click to expand...
Click to collapse
Thank you, and I agree. I tried a few things via fastboot, but they didn't fix the problem.
Playing with TWRP, fastboot, and boot slots has been an over-complicated headache.
In following your link and reading, I see that this is the flash download that I need:
https://otafsg1.h2os.com/patch/amaz...ygen_21.O.16_OTA_016_all_1908281716_b2bb5.zip
I downloaded it. Then, does the following procedure appear to be correct? ...
First, back up everything that's important on my data partition. Then, from my desktop ...
Code:
fastboot --set-active=b
fastboot reboot bootloader
... just to make sure that "B" is indeed currently the active partition, which it should be.
I should then boot back into my system and flash that ROM I downloaded.
I should flash it via Settings->System update->Local upgrade.
After the system reboots and I get it initialized, I should make sure that OEM unlocking is set,
I can then boot back into the bootloader and do the following
Code:
fastboot flashing unlock
Then, after the system reboots again and I make sure my system is set up properly, I should reboot yet again to the boot loader.
I should then run this command:
Code:
fastboot boot twrp-3.3.1-4-guacamole.img
This should bring up TWRP recovery. Inside of TWRP, I should go into Advanced->Sideload, and then from my desktop ...
Code:
adb sideload twrp-installer-3.3.1-4-guacamole.zip
In TWRP, I should go back to sideload and then do the following from my desktop ...
Code:
adb sideload Magisk-v20.1.zip
At this point, I should boot back into my system and get everything restored and set up the way I want.
Does this all look correct?
Thank you again!
.

Hmmm.. happened to my boot a partition too.. it cant boot because i flashed dm verity or something like that hoping that it would erase the lock pattern before entering and decrypting TWRP. but it failed. Took.me about an hour before i noticed that if i boot my phone to partition B.. its working fine.. when i boot to B.. i have read somewhere that android 10 installs on inactive slot..so i gambled to see if it would.fix my partition A that i think has been corrupted.. and so.it. worked. I lost my root and TWRP BECAuse i rebooted too soon..but hey... Patching my boot img with magisk..gives me a rooted device again...
So,. Im suggesting to flash ANDROID 10 FULL ROM.VIA Local upgrade then reboot.. i think it will be installed to your inactive slot and will fix the corrupt issue.. ehehehehe

santiagoruel13 said:
Hmmm.. happened to my boot a partition too.. it cant boot because i flashed dm verity or something like that hoping that it would erase the lock pattern before entering and decrypting TWRP. but it failed. Took.me about an hour before i noticed that if i boot my phone to partition B.. its working fine.. when i boot to B.. i have read somewhere that android 10 installs on inactive slot..so i gambled to see if it would.fix my partition A that i think has been corrupted.. and so.it. worked. I lost my root and TWRP BECAuse i rebooted too soon..but hey... Patching my boot img with magisk..gives me a rooted device again...
So,. Im suggesting to flash ANDROID 10 FULL ROM.VIA Local upgrade then reboot.. i think it will be installed to your inactive slot and will fix the corrupt issue.. ehehehehe
Click to expand...
Click to collapse
Thank you. Yes, I plan to flash the new 10.0.2 ROM soon, and I am glad to know from your experience that this should indeed solve my problem with the "A" slot.
Regarding dm-verity ... did you ever get that to work? I want to decrypt my phone, but I'm still not confident that dm-verity will work for me.

HippoMan said:
Thank you. Yes, I plan to flash the new 10.0.2 ROM soon, and I am glad to know from your experience that this should indeed solve my problem with the "A" slot.
Regarding dm-verity ... did you ever get that to work? I want to decrypt my phone, but I'm still not confident that dm-verity will work for me.
Click to expand...
Click to collapse
Nope.. i cant seem to make it work.. it just messes up and corrupt my phone partition slot.. dont know why.
It says decrypting phone.. successful.. and then.. it wont boot.

santiagoruel13 said:
Nope.. i cant seem to make it work.. it just messes up and corrupt my phone partition slot.. dont know why.
It says decrypting phone.. successful.. and then.. it wont boot.
Click to expand...
Click to collapse
Thank you. You have saved me a big headache, because now I won't even try to decrypt.
I'll keep investigating decryption, however, and if I can get it to work, I'll let you know
There seem to be a lot of posts in the following thread where people report problems similar to yours, so maybe we just have to wait until there is some sort of enhancement to dm-verity, or perhaps a new method for decrypting.
The thread: https://forum.xda-developers.com/android/software/universal-dm-verity-forceencrypt-t3817389
PS: I just saw this message: https://forum.xda-developers.com/showpost.php?p=80185974&postcount=599
This person first formatted data, then rebooted TWRP, then did a factory reset, and then did the rest of the flashing.
Also, as you can see, the flashing was done twice, with a TWRP reboot in between.
Did you perform that many steps when you tried to decrypt via dm-verity?
.

Boot to twrp
Format data
Reboot twrp again
Flash A10.01 rom
Flash TWRP
REBOOT TWRP
Flash decrypt via dm verity
REBOOT.. STUCK..

santiagoruel13 said:
Boot to twrp
Format data
Reboot twrp again
Flash A10.01 rom
Flash TWRP
REBOOT TWRP
Flash decrypt via dm verity
REBOOT.. STUCK..
Click to expand...
Click to collapse
In the other message whose link I posted, the writer did repeated flashing and more rebooting, including 3 dm verity flashes.
I think this multiple flashing and rebooting might be necessary because of the A/B slots, but I'm not sure ...
Format data,reboot twrp,factory reset,flash rom ,flash twrp ,flash dm verity.
Reboot again twrp
flash again rom,twrp,dm verity
Reboot twrp
flash gapps(when nedded)magisk(im using 19.4) flash dm verity.
Reboot system.
Click to expand...
Click to collapse
I'll have time to try all this on the weekend.

I fixed the problem via the following steps ...
(1) uninstall all Magisk modules
(2) reboot to System
(3) install the 10.0.2 OOS ROM via System Update->Local upgrade
(4) boot to bootloader
(5) "fastboot boot twrp.img" (version 3.3.1-70)
(6) go into Sideload and flash the twrp 3.3.1-70 installer
(7) reboot recovery
(8) go into Sideload and flash Magisk 20.1
(9) reboot to System
(10) reinstall the xXx-NoLimits ROM (version 9.3) via Magisk
In the process, I ended up with 10.0.2, as well.

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

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.
Download release factory AND OTA images from https://developers.google.com/android/images
Extract vbmeta.img and boot.img from the factory image
Patch boot.img using Magisk App on 12b5 phone and pull back to your PC
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"
V0latyle said:
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.
Click to expand...
Click to collapse
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!
flash magisk_patched_boot.img
Bash:
$ fastboot flash boot magisk_patched-23001_XXXXX.img
NOW you can reboot
Bash:
$ fastboot reboot
Check your magisk, safetynet, gpay, etc.
Optional: Reboot and check again if you want to really be sure, then breathe sigh of relief when root+data are still intact

Has anyone tried this way?

If this works coming from the 12 Beta, I don't see why it wouldn't work coming from Android 11.

I'm guessing this wouldn't work if you're already on the stable A12 release unrooted?

Any insight on what exactly necessitates the wipe between 11 and 12?

killchain said:
Any insight on what exactly necessitates the wipe between 11 and 12?
Click to expand...
Click to collapse
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.

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!

rester555 said:
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!
Click to expand...
Click to collapse
Agreed. And since we don't know exactly what the issue is, it's impossible to say.

PablosCorner said:
I'm guessing this wouldn't work if you're already on the stable A12 release unrooted?
Click to expand...
Click to collapse
I am bumping this reply... Wouldn't this guide apply to someone unrooted on A12 as well?

rester555 said:
I am bumping this reply... Wouldn't this guide apply to someone unrooted on A12 as well?
Click to expand...
Click to collapse
Potentially, but your mileage may vary.

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

V0latyle said:
This is what I tried:
-Sideloaded OTA
-Entered fastboot, flashed /vbmeta and /boot
-Rebooted, confirmed I still had root
Click to expand...
Click to collapse
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 .

V0latyle said:
-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.
Click to expand...
Click to collapse
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)

HumorBaby said:
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 .
Click to expand...
Click to collapse
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.

HumorBaby said:
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)
Click to expand...
Click to collapse
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.

V0latyle said:
Turns out we should flash vbmeta in bootloader, not fastbootd.
Click to expand...
Click to collapse
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.
V0latyle said:
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.
Click to expand...
Click to collapse
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.
V0latyle said:
Try re-patching the stock boot image on the Pixel 5, then boot it and see if it works.
Click to expand...
Click to collapse
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.
V0latyle said:
I don't see why switching slots would do it.
Click to expand...
Click to collapse
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.

HumorBaby said:
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.
Click to expand...
Click to collapse
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!

Database Info

welcome