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
Related
WARNING: Before attempting to root your device, do note that by unlocking your bootloader and modifying your device with root, ROMs, etc... you are risking voiding your warranty! I am NOT responsible for what you do to your device either, so follow these instructions at your own risk. Make sure you know what you're doing, it's best to understand the process rather than just copy and paste commands and such.
Useful and important general information can be found in the second post here.
NOTES
1. If you flash the TWRP Installer when you've already got Magisk installed, your device will keep booting to the recovery. You should be able to fix this by just simply reflashing Magisk.
2. If you have TWRP installed via the TWRP Installer, you will not be able to install stock OTA updates. You will have to reflash the stock boot image for whatever build you're running beforehand.
3. The prebuilt TWRP image may not have touch functionality if you're using the September 2018 Update or newer. Patching the boot image, however, for these builds with the TWRP Installer will allow touch to work flawlessly. Here is a pre-patched September 2018 Boot Image with TWRP. It should also work with builds newer than September. Since it's based off the September 2018 update, I suggest not using this as your main boot image but rather just as a replacement for the pre-built TWRP image from the official TWRP thread.
4. Simple "flash and forget" boot images pre-patched with Magisk and TWRP are provided by @aer0zer0 and are available here. They are based on ianmacd's variant of Magisk. If you are running stock, you can flash these boot images to get root and TWRP instead of following the guide to patch it yourself. Here is January's.
If you don't care about TWRP and simply want to just root your device, you can just simply patch the boot image for your ROM with the Magisk Manager and flash it in fastboot with
Code:
fastboot flash boot patched_boot.img
The link to the boot images for most stock builds can be grabbed from my Google Drive link in the second post or from the back-to-stock zips.
REQUIREMENTS
An unlocked bootloader
Working adb and fastboot environment, along with knowledge on how they work.
The latest build of TWRP along with the TWRP Installer. Read Note 3 above beforehand.
1. Download the latest build of TWRP and the TWRP Installer. Transfer the TWRP Installer zip to your device.
2. Reboot your phone into fastboot. Once in fastboot, change your device's current slot using the command
Code:
fastboot set_active other
If the command above doesn't work for you, use fastboot getvar current-slot followed by fastboot -aX, replacing "X" with the slot opposite (a or b) from your current slot.
3. Once your device's current slot has been switched, flash the TWRP image you downloaded earlier using the command
Code:
fastboot flash boot twrp.img
Depending on your version of fastboot, the above command might not work either. In that case, you can enter the following command, replacing "X" with your current slot (a or b).
Code:
fastboot flash boot_X twrp.img
4. Once TWRP has been flashed, boot into the recovery.
5. Once you have booted into TWRP, simply flash the TWRP Installer zip.
6. Once you have finished flashing the TWRP Installer zip, boot to recovery on the OPPOSITE slot. You can do this from TWRP by going to "Reboot", then selecting the opposite of the current slot (if on A, select Slot B. If on B, select Slot A), then select "Recovery." You can also do this through fastboot by running the same command from step 2.
7. Once you have booted back into TWRP, simply flash the Magisk zip and you are now good to go! Feel free to flash anything else like kernels while you're at it.
8. Reboot. :good:
NOTE: TWRP WILL remain installed on your device so long as you reflash the installer zip after every update.
Important Information for the Essential PH-1 can be found here. Keep it bookmarked.
Tips on updating via OTA after rooting can be found here.
In the case that you mess something up on your device, you may find it helpful to revert back to stock with the unofficial factory images graciously provided by @invisiblek and @aer0zer0 over here.
Official TWRP XDA Thread for the Essential PH-1
Join the Essential PH-1 Discord Server! -- Lots of cool people here!
Join the Essential PH-1 Development Telegram Channel!
Stock Boot Images for most builds can be found at my Google Drive link here.
Have a Red Verity Warning when booting your device? Click here.
If the link to the boot.fix.red image isn't working, you can also find it here or in my Google Drive link in the first post.
Essential Phone (PH-1) Partition Layout
Dumping Boot Images
1. Find the current slot with
Code:
fastboot getvar current-slot
or
Code:
adb shell getprop ro.boot.slot_suffix
2. Switch to the opposite slot in Fastboot using the command
Code:
fastboot set_active other
3. Flash TWRP using the command
Code:
fastboot flash boot twrp.img
4. Now, boot into TWRP and use the following command from your PC, replacing X in "boot_X" with the original slot from step 1 (a or b). TRIPLE CHECK:
Code:
adb shell dd if=/dev/block/bootdevice/by-name/boot_X of=/sdcard/boot.img
5. Profit! Don't forget to switch back to the original partition with the same command from step 2!
extractTarFork() error when restoring data from a TWRP backup
1. Reinstall the ROM from which the backup is based on.
2. Wipe your data. You can do this from the recovery or from fastboot using the command
Code:
fastboot -w
3. Boot into the ROM. When going through the initial setup, use the EXACT same security setup as the one from your backup. For example, if you used a Fingerprint + Password in the backed up ROM, use the exact same combo along with the exact same password as well. There is no need to set up anything else, like accounts.
4. Flash, install, and reboot into TWRP. You should now be able to restore the data backup without any issues.
AFH mirrors for images:
Build NMJ32F
NMJ32F patched boot image
NMJ32F factory image
Build NMJ20D
NMJ20D patched boot image
NMJ20D factory image
TWRP (alpha v4)
Thanks for getting the latest boot image up so quickly.
Thanks for the detailed guide, it worked great!
Any idea how to install xposed sdk 25? I tried the adb sideload function and the Magsik Module but both failed. Any ideas?
how to install the NMJ32F ota update when you are already rooted on NMJ20D?
Tried adb sideload but cannot install obviously because boot-loader is unlocked and is rooted.
prgopala said:
how to install the NMJ32F ota update when you are already rooted on NMJ20D?
Tried adb sideload but cannot install obviously because boot-loader is unlocked and is rooted.
Click to expand...
Click to collapse
You need to flash the system and boot images from Invisiblek's stock ROM dump. You'll then be unrooted and will be able to accept the update.
Factory reset no longer required if your bootloader is already unlocked? Does TWRP read encypted storage now? Or is that still a problem?
@bmg1001 , good looks, here are more free XDA points to trade in for that pool table, lol.
gk1984 said:
Factory reset no longer required if your bootloader is already unlocked? Does TWRP read encypted storage now? Or is that still a problem?
Click to expand...
Click to collapse
As far as I know, TWRP still doesn't have decryption fully working just yet, but installing Magisk works fine without any factory resets.
prozo said:
Thanks for the detailed guide, it worked great!
Any idea how to install xposed sdk 25? I tried the adb sideload function and the Magsik Module but both failed. Any ideas?
Click to expand...
Click to collapse
Xposed works fine for me. Make sure you installed the correct Xposed Installer/Manager apk linked in the thread for the Xposed Module. Also, it may take a reboot or two for Xposed to fully activate.
Did anyone manage to disable encryption? I tried everything and failed
bmg1001 said:
Xposed works fine for me. Make sure you installed the correct Xposed Installer/Manager apk linked in the thread for the Xposed Module. Also, it may take a reboot or two for Xposed to fully activate.
Click to expand...
Click to collapse
Maybe I'm not gathering the information correctly, using the Magisk Module itself doesn't work, sideloading the zip file via the adb fastboot TWRP.img doesn't work either, using the actual Xposed APK installer doesn't work either. I rebooted the phone about 4 times before removing it entirely.
Any chance you can walk me through how you got it installed without the TWRP recovery fully installed?
prozo said:
Maybe I'm not gathering the information correctly, using the Magisk Module itself doesn't work, sideloading the zip file via the adb fastboot TWRP.img doesn't work either, using the actual Xposed APK installer doesn't work either. I rebooted the phone about 4 times before removing it entirely.
Any chance you can walk me through how you got it installed without the TWRP recovery fully installed?
Click to expand...
Click to collapse
All I did was install the Xposed APK and then the Xposed Magisk Module. After two reboots, the apk said everything was working. This is the apk I used: https://drive.google.com/file/d/16-OHpswcngp1KLtkWCBDwwl8AvFafR5H/view?usp=drivesdk
bmg1001 said:
All I did was install the Xposed APK and then the Xposed Magisk Module. After two reboots, everything was working. This is the apk I used: https://drive.google.com/file/d/16-OHpswcngp1KLtkWCBDwwl8AvFafR5H/view?usp=drivesdk
Click to expand...
Click to collapse
Thanks for replying so quickly I appreciate it, the file you linked keeps opening on my end and fails to install saying it's corrupt
prozo said:
Thanks for replying so quickly I appreciate it, the file you linked keeps opening on my end and fails to install saying it's corrupt
Click to expand...
Click to collapse
The apk should be the same one found here: https://forum.xda-developers.com/xposed/unofficial-systemless-xposed-t3388268
bmg1001 said:
All I did was install the Xposed APK and then the Xposed Magisk Module. After two reboots, the apk said everything was working. This is the apk I used: https://drive.google.com/file/d/16-OHpswcngp1KLtkWCBDwwl8AvFafR5H/view?usp=drivesdk
Click to expand...
Click to collapse
Alright I got it to work
So I didn't use the APK instead I downloaded the zip from the XDA thread that is specifically for Magisk Module and then added via the modules tab on the left side of the Magisk Module APK.
After I restarted I had the newly installed APK to download and install the proper version of Xposed 88.2 sdk25
Another restart and boom I got the active module notification in green.
Thanks man!
Thread for downloads can be found here:
https://www.google.com/amp/s/forum....ed/unofficial-systemless-xposed-t3388268/amp/
Thank you for this!
My PH-1 is arriving today. SooOoo excited!
spotmark said:
You need to flash the system and boot images from Invisiblek's stock ROM dump. You'll then be unrooted and will be able to accept the update.
Click to expand...
Click to collapse
Would using flashfire work to install the ota?
drocny87 said:
Would using flashfire work to install the ota?
Click to expand...
Click to collapse
Couldn't tell you. I just used TWRP to flash the system and boot, and then took the update, and then rerooted.
I've only recently bought the OnePlus 6; maybe a month or so ago. So, I had the Havoc ROM installed earlier and when i tried to update it with the new version, i got the crashdump mode. I'm not sure what i did wrong, but whatever.
I downloaded the flashboot Pie OTA and installed it, and was able to boot it. I then went back into fastboot and booted up the blu_spark twrp and did a data wipe and installed Havoc and twrp again. and it installed successfully and when i tried to restart recovery, i keep getting a blank screen with the white led light. I googled that and it looks like a kernel issue or whatever. But I'm having trouble figuring out how to fix it. I can't seem to load my Slot A at all. Whenever i switch to slot A, i get the blank screen with the white led, but i restart into fastboot and switch my slot to B, it loads up the Pie OTA.
Is there something I can do to fix this? Or my slot A is just broken from day 1 and i never realized it?
you need pie fw on both slots before flashing a custom pie rom!
flash pie+twrp
reboot twrp and flash pie+twrp
reboot twrp and flash havoc+twrp
reboot twrp and flash others(i.e. gapps+magisk)
reboot system and you should be up and running
https://forum.xda-developers.com/oneplus-6/how-to/guide-noobs-guide-to-b-partitions-op6-t3816123
snigor said:
you need pie fw on both slots before flashing a custom pie rom!
flash pie+twrp
reboot twrp and flash pie+twrp
reboot twrp and flash havoc+twrp
reboot twrp and flash others(i.e. gapps+magisk)
reboot system and you should be up and running
https://forum.xda-developers.com/oneplus-6/how-to/guide-noobs-guide-to-b-partitions-op6-t3816123
Click to expand...
Click to collapse
the flashboot OTAs flash pie on both slots. I went through the batch commands and its flashing boot_a and boot_b, system_a and system_b. I'm talking about the fastboot OTAs found here https://forum.xda-developers.com/oneplus-6/how-to/rom-stock-fastboot-roms-oneplus-6-t3796665
alienwolf426 said:
the flashboot OTAs flash pie on both slots. I went through the batch commands and its flashing boot_a and boot_b, system_a and system_b. I'm talking about the fastboot OTAs found here https://forum.xda-developers.com/oneplus-6/how-to/rom-stock-fastboot-roms-oneplus-6-t3796665
Click to expand...
Click to collapse
oh, right.. my bad! did you test both slots with only pie?
So, an update in case someone else has this issue with a busted slot and they want to fix it.
I had to download the unbrick tool from here https://forum.xda-developers.com/oneplus-6/how-to/tool-msmdownloadtool-v4-0-international-t3798892
I ran that, and installed the OxygenOS Pie OB4 (but i guess it can work with whatever pie build) on both slot A and B.
And that fixed it.
I guess, what may have broken the slots for me was that i installed official TWRP and blu_spark TWRP, which probably fked up the boot image.
Not the slot that got ****ed up,it was you that didn't read and follow the guide. It's important to follow the steps when flashing custom ROMs. So,from TWRP you shouöd have flashed pie firmware 2 times. (Yes it says it's flashed to a and b,that is not the case still...that's why the guide tells you to do what it tells you to do) also the TWRP thing is incorrect,but whatever floats your boat.
I installed the Stable Android 10 on my GM1910 via TWRP, totally forgetting about maintaining root and TWRP.
So how do I bring back TWRP and root?
fastboot boot doesn't seem to work, I managed to pull the boot.img and patch it with Magisk from another device but flashing it through fastboot ends up in an endless bootanimation.
Could anyone help me? here's a link of the boot.img i pulled, it works if you flash it without magisk patching it.
Link: https://drive.google.com/file/d/1O8lF1UDwwu0zT8ro5Q1gKKfdxF-HGPEW/view?usp=sharing
(Almost) exactly the same here. I tired flashing a patched boot.img, it actually boots - but magisk manager gets stuck on the splash screen and some apps, including chrome, won't start. Trying to boot TWRP results in the phone getting stuck on the "fastboot mode" screen.
My only solution would be to downgrade, root, keep the upgrade this time. But because my ISP is doing some maintenance work I don't have wifi - and restoring my phone through mobile data does not seem to work correctly.
EDIT: In fastboot, neither bootloader version nor baseband version are show, product name is "msmnile". Has this always been that way?
EDIT 2, solution:
I extracted the boot.img from the device, and patched it using magisk on the same phone:
https://drive.google.com/file/d/1-Gf-6iXSFuYT5xDR-mnLKANvkXUHal9e/view?usp=sharing
Run this command in fastboot so you know which is the CURRENT active slot :
Code:
fastboot getvar current-slot
Run this command so you can flash the correct slot :
Code:
fastboot flash boot_X magisk_patched.img
replace X with the a or b from the command before.
:good:
dmj0shu4 said:
I installed the Stable Android 10 on my GM1910 via TWRP, totally forgetting about maintaining root and TWRP.
So how do I bring back TWRP and root?
fastboot boot doesn't seem to work, I managed to pull the boot.img and patch it with Magisk from another device but flashing it through fastboot ends up in an endless bootanimation.
Could anyone help me? here's a link of the boot.img i pulled, it works if you flash it without magisk patching it.
Link: https://drive.google.com/file/d/1O8lF1UDwwu0zT8ro5Q1gKKfdxF-HGPEW/view?usp=sharing
Click to expand...
Click to collapse
Hi sorry to hear that you got this problem and hopefully it gets fixed. I have another question: does that mean using TWRP to completely clean the device then installing Android 10 via zip will remove TWRP and fastboot everything? Does that mean after installing, everything will be refreshed like a box opened phone?
dmj0shu4 said:
I installed the Stable Android 10 on my GM1910 via TWRP, totally forgetting about maintaining root and TWRP.
So how do I bring back TWRP and root?
fastboot boot doesn't seem to work, I managed to pull the boot.img and patch it with Magisk from another device but flashing it through fastboot ends up in an endless bootanimation.
Could anyone help me? here's a link of the boot.img i pulled, it works if you flash it without magisk patching it.
Link: https://drive.google.com/file/d/1O8lF1UDwwu0zT8ro5Q1gKKfdxF-HGPEW/view?usp=sharing
Click to expand...
Click to collapse
If you have an endless boot animation you might be trying to boot from the wrong slot, try using the fastboot set_active command to change slot, then restart
h0l said:
Run this command in fastboot so you know which is the CURRENT active slot :
Run this command so you can flash the correct slot : replace X with the a or b from the command before.
:good:
Click to expand...
Click to collapse
I got a bit confused.
If the current slot is boot_a, i flash it in boot_b or am I supposed to flash on the one that isn't the current slot?
djsubterrain said:
If you have an endless boot animation you might be trying to boot from the wrong slot, try using the fastboot set_active command to change slot, then restart
Click to expand...
Click to collapse
Which is the default active slot? Is it okay to use either of the 2?
dmj0shu4 said:
Which is the default active slot? Is it okay to use either of the 2?
Click to expand...
Click to collapse
Either one should work if the rom and the rooted boot image is on it (If you are rooting). That's why you should install using TWRP, if you look in the reboot menu it will show you the active slot.
djsubterrain said:
Either one should work if the rom and the rooted boot image is on it (If you are rooting). That's why you should install using TWRP, if you look in the reboot menu it will show you the active slot.
Click to expand...
Click to collapse
I would've used TWRP but it won't let me boot into it
fastboot boot [recovery.img] does not seem to work for android 10, atleast on my case
dmjoshu4 said:
I got a bit confused.
If the current slot is boot_a, i flash it in boot_b or am I supposed to flash on the one that isn't the current slot?
Click to expand...
Click to collapse
You are supposed to flash it in the one that IS the active one. Because you do want to root the slot that you'll be booting.
does that mean using TWRP to completely clean the device then installing Android 10 via zip will remove TWRP and fastboot everything? I.e. everything will be refreshed like a box opened phone?
gh279760559 said:
does that mean using TWRP to completely clean the device then installing Android 10 via zip will remove TWRP and fastboot everything? I.e. everything will be refreshed like a box opened phone?
Click to expand...
Click to collapse
not everything, just twrp and root will be gone if you restarted without installing magisk to the inactive slot
h0l said:
(Almost) exactly the same here. I tired flashing a patched boot.img, it actually boots - but magisk manager gets stuck on the splash screen and some apps, including chrome, won't start. Trying to boot TWRP results in the phone getting stuck on the "fastboot mode" screen.
My only solution would be to downgrade, root, keep the upgrade this time. But because my ISP is doing some maintenance work I don't have wifi - and restoring my phone through mobile data does not seem to work correctly.
EDIT: In fastboot, neither bootloader version nor baseband version are show, product name is "msmnile". Has this always been that way?
EDIT 2, solution:
I extracted the boot.img from the device, and patched it using magisk on the same phone:
https://drive.google.com/file/d/1-Gf-6iXSFuYT5xDR-mnLKANvkXUHal9e/view?usp=sharing
Run this command in fastboot so you know which is the CURRENT active slot :
Code:
fastboot getvar current-slot
Run this command so you can flash the correct slot :
Code:
fastboot flash boot_X magisk_patched.img
replace X with the a or b from the command before.
:good:
Click to expand...
Click to collapse
dude, thanks for this, i was banging my head against a wall trying to get root to work. I used your patched boot img and i had the version mismatch, but i local updated my android and it has root!
dmj0shu4 said:
I would've used TWRP but it won't let me boot into it
fastboot boot [recovery.img] does not seem to work for android 10, atleast on my case
Click to expand...
Click to collapse
I have not been able to boot TWRP either in fastboot mode - got stuck at "OnePlus Logo FastBoot" black screen.
Hi guys.. can you post the steps in rooting android 10??
I've already had bootloader unlocked.
Do i need to.follow the steps intended for android 9??
Like
1. Install TWRP via fastboot.. (2files)
2. Reboot to twrp.
3. Flash magisk via twrp??
Is that it?? If so. Then after reading this thread.. some of. You mentioned about boot. Img?? Patched?? What's that supposed to mean?? Sir??
Thanks. Any advice is highly appreciated..
---------- Post added at 08:30 AM ---------- Previous post was at 08:28 AM ----------
And by the way..
Im on Gm1910 model. Global rom. Gm21AA build.. if that info would matter.. i dont actually need the root on android 9. Coz parallel app is working.. but now in android 10. It isnt working.. so.i need to root to grant su to game guardian.. thanks..
MigbyPie said:
I have not been able to boot TWRP either in fastboot mode - got stuck at "OnePlus Logo FastBoot" black screen.
Click to expand...
Click to collapse
Same.
I've read that Q/10 is different and you can't install TWRP like that anymore. Supposedly you need to use the MSM tool or the all-in-one tool but I've tried both of those and still can't boot to TWRP.
E30Nova said:
Same.
I've read that Q/10 is different and you can't install TWRP like that anymore. Supposedly you need to use the MSM tool or the all-in-one tool but I've tried both of those and still can't boot to TWRP.
Click to expand...
Click to collapse
Hopefully there will be a solution. I had tried to update from Pie to Q10 while staying rooted and it didn't work. So I had to wipe the whole device and decided to wait for a smoother root method for my device. If you have any other ideas about rooting Q10 let me know. Thank you
h0l said:
(Almost) exactly the same here. I tired flashing a patched boot.img, it actually boots - but magisk manager gets stuck on the splash screen and some apps, including chrome, won't start. Trying to boot TWRP results in the phone getting stuck on the "fastboot mode" screen.
My only solution would be to downgrade, root, keep the upgrade this time. But because my ISP is doing some maintenance work I don't have wifi - and restoring my phone through mobile data does not seem to work correctly.
EDIT: In fastboot, neither bootloader version nor baseband version are show, product name is "msmnile". Has this always been that way?
EDIT 2, solution:
I extracted the boot.img from the device, and patched it using magisk on the same phone:
https://drive.google.com/file/d/1-Gf-6iXSFuYT5xDR-mnLKANvkXUHal9e/view?usp=sharing
Run this command in fastboot so you know which is the CURRENT active slot :
Code:
fastboot getvar current-slot
Run this command so you can flash the correct slot :
Code:
fastboot flash boot_X magisk_patched.img
replace X with the a or b from the command before.
:good:
Click to expand...
Click to collapse
You saved my life! Thank you!
But how do we get twrp now? Is there any way?
Me too. Use tool all in one but it doesnt work. Stuck at "waiting twrp boots".
Any help, thanks.
Same here any Solution?
Sent from my GM1911 using Tapatalk
---------- Post added at 08:14 AM ---------- Previous post was at 08:14 AM ----------
Stuck at Fastboot booting when flashed img and also zip
Sent from my GM1911 using Tapatalk
I updated my phone to 10 last night, followed the same guide as I have for every other update but this time I lost root for some reason.
I still have TWRP recovery on there but it can't read internal storage so I can't flash Magisk.
I tried changing file system to ext 2 then back to 4 and then repairing it as I read elsewhere and this wiped the phone obviously but internal storage seemed to be working until I set the phone up again, downloaded Magisk, rebooted to recovery and I'm back where I started, internal storage showing as 0mb in TWRP.
Any ideas how to fix?
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
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
Dude. You f*ckin' broke. it. down! Thank you so much. I finally get it.
I'm not a fan of just following a tutorial and calling it a day. I like to understand how a process acheives a goal (atleast when gooning on a phone for hours). So, thank you for laying out like that!!
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!