Related
it freezes the phone then it boots back into the OS.
I noticed that it takes a bit of a long time (0.6 minutes) to patch the boot image but it ends up successful.
Before this, I unlocked the bootloader on my phone which was on Android 8.0.0 October 2017, then I OTA updated it to Android 8.0.0 November 2017 using the recovery mode.
Also, right after I unlocked the bootloader, I tried to flash the November full system image but it didn't work and returned the error "could not create userdata" or similar, and it threw a lot of missing .sig errors.
The OS all works fine and it still boots into it, just I have no recovery mode now.
I used https://www.youtube.com/watch?v=FcgCrmL8xfE to flash the latest TWRP.
I verified the hashes of all the files too, no luck.
What can I do to fix the issue?
UPDATE: I was trying TWRP 3.2.3-1, I also tried 3.2.3-0 which failed then I tried 3.1.1-1 which didn't change the recovery mode at all, it just returned errors when I was in the temporary TWRP boot.
I'm curious why you want a one year old version of the ROM, and not the most recent version. In any case, you should be able to download the full factory image, then extract the boot.img file. Use fastboot to flash the boot.img to your phone using
Code:
fastboot flash boot boot.img
After that, you should be able to boot to system fine, and you should also be able to boot from the TWRP.img file fine. Always use the latest version of TWRP. Specifically for the Pixel phones, version 3.2.3-1 of TWRP is the first version which successfully unlocks phones with a pattern unlock.
OnePlus 6, Ubuntu 18.04. I think I've basically wiped everything.
I am trying to follow https://forum.xda-developers.com/oneplus-6/how-to/rom-stock-fastboot-roms-oneplus-6-t3796665 but I can't get either of these to boot:
Code:
fastboot boot TWRP.img
or
Code:
fastboot boot twrp-3.3.1-2-enchelada.img
Doing this gives me the OnePlus logo with "Fastboot Mode" underneath and it hangs.
I've tried
Code:
fastboot --set-active=b
fastboot flash slot_b TWRP.img
and
Code:
fastboot flash slot_b twrp-3.3.1-2-enchilada.img
Rebooting into slot_b recovery gives me the warning about "The boot loader is unlocked and software integrity cannot be guaranteed. ... PRESS POWER KEY TO PAUSE BOOT" and then it hangs.
I am trying to get back to stock OOS so I can try Havoc but I'll settle for the former just to get the phone working.
I have a nandroid backup, I rsynced my /sdcard, and I have a Titanium backup.
I really need some guidance here...
What should I make of
Code:
$fastboot erase recovery
erasing 'recovery'...
FAILED (remote: Check device console.)
iconoclasthero said:
OnePlus 6, Ubuntu 18.04. I think I've basically wiped everything.
I am trying to follow https://forum.xda-developers.com/oneplus-6/how-to/rom-stock-fastboot-roms-oneplus-6-t3796665 but I can't get either of these to boot:
Code:
fastboot boot TWRP.img
or
Code:
fastboot boot twrp-3.3.1-2-enchelada.img
Doing this gives me the OnePlus logo with "Fastboot Mode" underneath and it hangs.
I've tried
Code:
fastboot --set-active=b
fastboot flash slot_b TWRP.img
and
Code:
fastboot flash slot_b twrp-3.3.1-2-enchilada.img
Rebooting into slot_b recovery gives me the warning about "The boot loader is unlocked and software integrity cannot be guaranteed. ... PRESS POWER KEY TO PAUSE BOOT" and then it hangs.
I am trying to get back to stock OOS so I can try Havoc but I'll settle for the former just to get the phone working.
I have a nandroid backup, I rsynced my /sdcard, and I have a Titanium backup.
I really need some guidance here...
Click to expand...
Click to collapse
What rom was installed last before all this began.
MrSteelX said:
What rom was installed last before all this began.
Click to expand...
Click to collapse
Havoc OS (Havoc-OS-v3.1-20200120-enchilada-Official.zip). The problem was that somehow my pin got corrupted/changed after my first couple of boots into Havoc. That precipitated a big mess.
That said, I switched to my desktop (also running Ubuntu 18.04) and got a new version of the SDK directly from android.com, and replaced the files that came from the repo. That was able to do the formatting and install the stock image so now I just need to go through the procedure again...
I wish I'd had a better sense of what was going on with the partition table/fstab/blkid because I was able to get in with adb shell and I theoretically could have manually formatted...
iconoclasthero said:
OnePlus 6, Ubuntu 18.04. I think I've basically wiped everything.
I am trying to follow https://forum.xda-developers.com/oneplus-6/how-to/rom-stock-fastboot-roms-oneplus-6-t3796665 but I can't get either of these to boot:
Code:
fastboot boot TWRP.img
or
Code:
fastboot boot twrp-3.3.1-2-enchelada.img
Doing this gives me the OnePlus logo with "Fastboot Mode" underneath and it hangs.
I've tried
Code:
fastboot --set-active=b
fastboot flash slot_b TWRP.img
and
Code:
fastboot flash slot_b twrp-3.3.1-2-enchilada.img
Rebooting into slot_b recovery gives me the warning about "The boot loader is unlocked and software integrity cannot be guaranteed. ... PRESS POWER KEY TO PAUSE BOOT" and then it hangs.
I am trying to get back to stock OOS so I can try Havoc but I'll settle for the former just to get the phone working.
I have a nandroid backup, I rsynced my /sdcard, and I have a Titanium backup.
I really need some guidance here...
Click to expand...
Click to collapse
It looks like you had android 10 and you flashed official twrp, which is android 9 only, which happened to me before. I could recommend using this to flash OOS through fastboot.
[email protected] said:
It looks like you had android 10 and you flashed official twrp, which is android 9 only, which happened to me before. I could recommend using this to flash OOS through fastboot.
Click to expand...
Click to collapse
I haven't checked to see what, if any, recovery is on there now. I'm assuming that the stock one was flashed on when I was able to get 10.3.0-OnePlus6Oxygen_22_OTA_042_all_1912142031_0fb330-FASTBOOT.zip. Now that I've got it working again, how do I put Havoc on it? Isn't that based on Android 10 ... ?
I found this in one of the many tabs I had open from figuring all this out: https://del.dog/pelihovape.txt. I wish it had some version numbers!
iconoclasthero said:
I haven't checked to see what, if any, recovery is on there now. I'm assuming that the stock one was flashed on when I was able to get 10.3.0-OnePlus6Oxygen_22_OTA_042_all_1912142031_0fb330-FASTBOOT.zip. Now that I've got it working again, how do I put Havoc on it? Isn't that based on Android 10 ... ?
I found this in one of the many tabs I had open from figuring all this out: https://del.dog/pelihovape.txt. I wish it had some version numbers!
Click to expand...
Click to collapse
https://forum.xda-developers.com/on...overy-unofficial-twrp-touch-recovery-t3860815 ?
iconoclasthero said:
https://forum.xda-developers.com/on...overy-unofficial-twrp-touch-recovery-t3860815 ?
Click to expand...
Click to collapse
iconoclasthero said:
I haven't checked to see what, if any, recovery is on there now. I'm assuming that the stock one was flashed on when I was able to get 10.3.0-OnePlus6Oxygen_22_OTA_042_all_1912142031_0fb330-FASTBOOT.zip. Now that I've got it working again, how do I put Havoc on it? Isn't that based on Android 10 ... ?
I found this in one of the many tabs I had open from figuring all this out: https://del.dog/pelihovape.txt. I wish it had some version numbers!
Click to expand...
Click to collapse
I was looking around but I could not find what is going on with Havoc OS. I would probably recommended choosing a better maintained ROM with up to date instructions and support. Maybe Pixen or something. I was only able to find this old thread. Maybe you have better luck.
But if you really want Havoc, figure out first if it is androdi 9 or 10. If it is 10, use malfuriono unofficial twrp. If it is 9, you have to downgrade to OOS 9.0.9 first. Also, dirty flashes tend to cause problems, I would not recommended doing that. Make sure you wipe appropriate partitions
Trying to root the Pixel 5 running Android 12 by flashing a magisk-patched boot image results in the phone only booting to fastboot mode ("failed to load/verify boot images")
Some users have reported that booting (instead of flashing) the patched boot image works and makes root temporarily available but i didn't have any success with that.
The phone booted up but root didn't work.
I won't explain how to unlock the bootloader or set up adb here.
!Warning! This will wipe your phone so take a backup!
Also i do not take any responsibility if you break your device.
And if anything goes wrong just factory reset your device using the Android Flash Tool or by following this tutorial.
Here's what i did to get Magisk v22.0 working on the first developer preview of Android 12:
Install A12 with disabled AVB & dm-verity:
Make sure USB-Debugging is enabled in developer-options and you have authorized the pc you're using on your phone.
Boot your phone into fastboot mode.
You can do this by turning it off and then starting it by holding Power + Volume Down
until fastboot mode appears or just adb reboot bootloader
Go here and click on the link for the Android Flash Tool.
(I didn't copy the link directly so i don't have to update it everytime google releases a new update)
It should ask you to allow the website to access ADB Keys. Click Ok.
If the website somehow doesn't work, try using Google Chrome.
Select your Pixel 5. If it's not showing up click add device.
Click on the edit symbol (pen) in the box where the selected build is shown.
Make sure Wipe Device, Disable Verity and Disable Verification are checked.
Install and boot the phone when it's finished.
Patch & flash boot.img
Download and install the Magisk Canary App from GitHub.
Download the factory image from here and extract boot.img from it.
(Inside the downloaded zip-file is another zip file containing the boot image)
Copy the extracted boot.img to your phone and open the magisk app.
Click on Install -> Select and Patch a File and let it do its magic.
Copy the magisk-patched boot image that should be found in your phones download folder back to your PC.
Reboot into fastboot mode as i explained earlier and flash the patched boot image.
(fastboot flash boot magisk_patched.img)
Then reboot the device.
Now root should be working. If it bootloops and says your phone has to be factory reset, do it.
If for some reason you still get an AVB-Error and end up stuck in fastboot mode just flash the stock image and try to patch it again.
This is my first post on here and i didn't have much time but i'm glad if it helped at least one person.
Thanks for create this post.Works perfect,
Ivixmax said:
Thanks for create this post.Works perfect,
Click to expand...
Click to collapse
Hey, thanks for this. FYI @LazerL0rd (zest kernel) detailed here (click on the spoiler) how to do this with just the command line and factory images and without the need for the AFT.
edit: formatting
I keep on getting the AVB-Error to no end.
new beta magisk not working
morpheus620 said:
new beta magisk not working
Click to expand...
Click to collapse
Make sure to disable verity & verification and use magisk canary, not beta
okay. is working. sorry für the misstake.
morpheus620 said:
okay. is working. sorry für the misstake.
Click to expand...
Click to collapse
Alles gut
Anyone able to get safety net to pass on Android 12?
greenlight63 said:
Anyone able to get safety net to pass on Android 12?
Click to expand...
Click to collapse
Unfortunately no, universal safetynet fix 2.0.0 by kdrag0n makes basicIntegrity pass but since the update to dp3 CTS still fails.
Dirty flashing newer factory images will restore the verity and verification state, so when you patch the kernel with magisk it will fail to boot again.
Installing a verity and verification disabled image without wiping from the web based flasher will also corrupt your data and not let the phone boot, forcing you to wipe.
Wonder what the flags are for flashing factory images with verity and verification state off and giving the ability to continue on without wiping and being able to boot the magisk patched kernel again.
fastboot update --disable-verity --disable-verification image-redfin-spp3210325.010.zip maybe?
Or prepatch the boot.img before flashing it with fastboot, and then flashing it back before rebooting from after flashing the factory image as an update?
tauio111 said:
Dirty flashing newer factory images will restore the verity and verification state, so when you patch the kernel with magisk it will fail to boot again.
Installing a verity and verification disabled image without wiping from the web based flasher will also corrupt your data and not let the phone boot, forcing you to wipe.
Wonder what the flags are for flashing factory images with verity and verification state off and giving the ability to continue on without wiping and being able to boot the magisk patched kernel again.
fastboot update --disable-verity --disable-verification image-redfin-spp3210325.010.zip maybe?
Or prepatch the boot.img before flashing it with fastboot, and then flashing it back before rebooting from after flashing the factory image as an update?
Click to expand...
Click to collapse
Don't know but sounds interesting. I just use
Code:
fastboot --disable-verity --disable-verification flash vbmeta vbmeta.img
after every update
Works like a charm Android 12 pixel 4a 5g
I just installed the newest Public Beta via OTA. Can I root? I was rooted on 11 before and just enrolled in the beta program and installed it via OTA. Without factory reset or reflash. Now I tried patching boot.img via Magisk Manager, but it wont boot. I mean it boots, but wont unlock phone to homescreen. I'm locked out of my phone. Reverted back to stock PB1 boot image. Any ideas without factory reset?
THEVAN3D said:
I just installed the newest Public Beta via OTA. Can I root? I was rooted on 11 before and just enrolled in the beta program and installed it via OTA. Without factory reset or reflash. Now I tried patching boot.img via Magisk Manager, but it wont boot. I mean it boots, but wont unlock phone to homescreen. I'm locked out of my phone. Reverted back to stock PB1 boot image. Any ideas without factory reset?
Click to expand...
Click to collapse
I just tried it using the canary build and it won't boot either. It gets stuck at the Bootloader screen and shows "Failed to load/verify boot images". Maybe we need to wait for an update to for Magisk?
QuickInfo said:
I just tried it using the canary build and it won't boot either. It gets stuck at the Bootloader screen and shows "Failed to load/verify boot images". Maybe we need to wait for an update to for Magisk?
Click to expand...
Click to collapse
Did you try it according to the manual from the first post from @myhuky3?
kafisc said:
Did you try it according to the manual from the first post from @myhuky3?
Click to expand...
Click to collapse
Not yet, I'll wait until the end of the beta program before I reset it. I can get temporary root by booting into the patched Magisk boot image
Following the OP it worked great on the public beta been running it since last night its awesome thank you for the guide
delete
I'm on 11.2.2.2 global, successfully rooted with Magisk. When I follow the OTA update procedure -- uninstall Magisk, install the OTA update but don't reboot, install Magisk to inactive slot, and reboot -- everything appears to work and I don't get any errors, but when the phone boots up afterwards, it's still on 11.2.2.2.
I've tried with the both of the recent OTA updates and the result is the same. Am I doing something wrong, or is this expected when rooted, and I need to wait for the full ROM to be released by 1+?
Oxygen Updater - Apps on Google Play
Skip staged rollout queues and update your OnePlus device ASAP!
play.google.com
Okay, I see you can't install incremental OTAs with an unlocked bootloader. Disappointing. Guess I am waiting for full updates.
It is written in a lot of guides. It works when you do it correctly. I got a oneplus 8 and it works without a problem.
0No said:
It is written in a lot of guides. It works when you do it correctly. I got a oneplus 8 and it works without a problem.
Click to expand...
Click to collapse
Well I followed the same procedure when I flashed the full zip of 11.2.2.2, and it worked. So I don't see how I am doing it incorrectly.
Slikkster2k said:
I'm on 11.2.2.2 global, successfully rooted with Magisk. When I follow the OTA update procedure -- uninstall Magisk, install the OTA update but don't reboot, install Magisk to inactive slot, and reboot -- everything appears to work and I don't get any errors, but when the phone boots up afterwards, it's still on 11.2.2.2.
I've tried with the both of the recent OTA updates and the result is the same. Am I doing something wrong, or is this expected when rooted, and I need to wait for the full ROM to be released by 1+?
Click to expand...
Click to collapse
My suggestion is to uninstall magisk (restore the stock image) and reboot. Then do the update and reboot. The use the 11.2.2 modified boot image in fastboot do: fastboot boot boot.img and when it boots let magisk install which will backup then modify the new boot image from 11.2.4.4 and voila you now have root and a backup of the newest boot image which will let you be able to update to the next Ota using this same method
toyanucci said:
My suggestion is to uninstall magisk (restore the stock image) and reboot. Then do the update and reboot. The use the 11.2.2 modified boot image in fastboot do: fastboot boot boot.img and when it boots let magisk install which will backup then modify the new boot image from 11.2.4.4 and voila you now have root and a backup of the newest boot image which will let you be able to update to the next Ota using this same method
Click to expand...
Click to collapse
Well I tried this and I'm really hosed now... phone will only boot to recovery after uninstalling Magisk and rebooting. I tried flashing the stock 11.2.2.2 boot.img from fastboot, and that didn't help either. I'm kinda stuck unless I can flash the full 11.2.2.2 from fastboot or recovery? I don't know how to do that.
Slikkster2k said:
Well I tried this and I'm really hosed now... phone will only boot to recovery after uninstalling Magisk and rebooting. I tried flashing the stock 11.2.2.2 boot.img from fastboot, and that didn't help either. I'm kinda stuck unless I can flash the full 11.2.2.2 from fastboot or recovery? I don't know how to do that.
Click to expand...
Click to collapse
What version OP9 are you using and what OS version and phone version boot images are you using?
Instructions are here for how to do a manual flash via fastboot. Basically extract with payload dumper and flash each image manually like in the example in the link.
toyanucci said:
What version OP9 are you using and what OS version and phone version boot images are you using?
Instructions are here for how to do a manual flash via fastboot. Basically extract with payload dumper and flash each image manually like in the example in the link.
Click to expand...
Click to collapse
Not sure what you mean by what version OP9?
I have 11.2.2.2AA installed, I've tried flashing the matching stock boot image, the magisk patched version of it, and even the stock 11.2.3.3AA boot image.
I found those instructions and I'm trying it, but I'm running into problems with the payload dumper (FileNotFoundError when attempting to dump).
Slikkster2k said:
Not sure what you mean by what version OP9?
I have 11.2.2.2AA installed, I've tried flashing the matching stock boot image, the magisk patched version of it, and even the stock 11.2.3.3AA boot image.
I found those instructions and I'm trying it, but I'm running into problems with the payload dumper (FileNotFoundError when attempting to dump).
Click to expand...
Click to collapse
And you're sure the boot images you've tried are for the global version? If all you've messed with is the boot image I don't see why the phone won't boot Before flashing any boot image it's best to do fastboot boot boot.img. It doesn't overwrite the boot image so in case it doesn't work a simple reboot will get you back up ad running.
Re payload dumber make sure you've CD'd to the right folder? I had the same error when I was trying to do it yesterday and it was because I hadn't CD'd to the right folder.
Have you got the files extracted?
toyanucci said:
And you're sure the boot images you've tried are for the global version? If all you've messed with is the boot image I don't see why the phone won't boot Before flashing any boot image it's best to do fastboot boot boot.img. It doesn't overwrite the boot image so in case it doesn't work a simple reboot will get you back up ad running.
Re payload dumber make sure you've CD'd to the right folder? I had the same error when I was trying to do it yesterday and it was because I hadn't CD'd to the right folder.
Have you got the files extracted?
Click to expand...
Click to collapse
I found them in the root thread in this forum, the user who posted them said they were for global, yes.
I did try using fastboot boot first, but I get this error:
Code:
FAILED (remote: 'Failed to load/authenticate boot image: Load Error')
So I just tried to flash instead, which flashes successfully, but then it fails to boot after and dumps me back into fastboot or recovery.
I know my way around the command line pretty well, so yes I'm in the right directory. Here's the full error when running extract_android_ota_payload.py:
Code:
Extracting 'abl.img'
Traceback (most recent call last):
File "E:\extract_android_ota_payload-master\extract_android_ota_payload.py", line 142, in <module>
main(filename, output_dir)
File "E:\extract_android_ota_payload-master\extract_android_ota_payload.py", line 121, in main
parse_payload(payload, p, out_f)
File "E:\extract_android_ota_payload-master\extract_android_ota_payload.py", line 95, in parse_payload
r = decompress_payload('xzcat', data, e.num_blocks * BLOCK_SIZE, operation.data_sha256_hash)
File "E:\extract_android_ota_payload-master\extract_android_ota_payload.py", line 78, in decompress_payload
p = subprocess.Popen([command, '-'], stdout=subprocess.PIPE, stdin=subprocess.PIPE)
File "C:\Program Files\Python39\lib\subprocess.py", line 947, in __init__
self._execute_child(args, executable, preexec_fn, close_fds,
File "C:\Program Files\Python39\lib\subprocess.py", line 1416, in _execute_child
hp, ht, pid, tid = _winapi.CreateProcess(executable, args,
FileNotFoundError: [WinError 2] The system cannot find the file specified
I believe it's failing because it can't find xzcat. I am trying to install MinGW in an effort to resolve that.
The only boot image I haven't tried yet so far is 11.2.4.4 as I haven't been able to find a copy of that. I don't know why that would work when nothing else has though.
Slikkster2k said:
I found them in the root thread in this forum, the user who posted them said they were for global, yes.
I did try using fastboot boot first, but I get this error:
Code:
FAILED (remote: 'Failed to load/authenticate boot image: Load Error')
So I just tried to flash instead, which flashes successfully, but then it fails to boot after and dumps me back into fastboot or recovery.
I know my way around the command line pretty well, so yes I'm in the right directory. Here's the full error when running extract_android_ota_payload.py:
Code:
Extracting 'abl.img'
Traceback (most recent call last):
File "E:\extract_android_ota_payload-master\extract_android_ota_payload.py", line 142, in <module>
main(filename, output_dir)
File "E:\extract_android_ota_payload-master\extract_android_ota_payload.py", line 121, in main
parse_payload(payload, p, out_f)
File "E:\extract_android_ota_payload-master\extract_android_ota_payload.py", line 95, in parse_payload
r = decompress_payload('xzcat', data, e.num_blocks * BLOCK_SIZE, operation.data_sha256_hash)
File "E:\extract_android_ota_payload-master\extract_android_ota_payload.py", line 78, in decompress_payload
p = subprocess.Popen([command, '-'], stdout=subprocess.PIPE, stdin=subprocess.PIPE)
File "C:\Program Files\Python39\lib\subprocess.py", line 947, in __init__
self._execute_child(args, executable, preexec_fn, close_fds,
File "C:\Program Files\Python39\lib\subprocess.py", line 1416, in _execute_child
hp, ht, pid, tid = _winapi.CreateProcess(executable, args,
FileNotFoundError: [WinError 2] The system cannot find the file specified
I believe it's failing because it can't find xzcat. I am trying to install MinGW in an effort to resolve that.
Click to expand...
Click to collapse
Try the instructions here to get payload dumper working
toyanucci said:
Try the instructions here to get payload dumper working
Click to expand...
Click to collapse
Okay that worked. I should've just tried that version first instead of the 'newer' one I found.
Now when I try to flash I'm getting
Code:
FAILED (remote: 'Flashing is not allowed for Critical Partitions')
I have found that I can use 'fastboot flashing unlock-critical' to unlock these, but it will wipe the phone.
I really don't want to wipe my device if I can avoid it.
Maybe try just flashing the boot partition
Slikkster2k said:
Now when I try to flash I'm getting
Code:
FAILED (remote: 'Flashing is not allowed for Critical Partitions')
I have found that I can use 'fastboot flashing unlock-critical' to unlock these, but it will wipe the phone.
I really don't want to wipe my device if I can avoid it.
Click to expand...
Click to collapse
Maybe try just flashing the boot partition
toyanucci said:
Maybe try just flashing the boot partition
Maybe try just flashing the boot partition
Click to expand...
Click to collapse
Yeah that was the first thing I tried, no dice.
You have 11.2.4.4 global on your phone right? Would you be able to retrieve the stock boot.img and upload it for me so I can try booting with that? It's a long shot but I'm desperate.
Slikkster2k said:
Yeah that was the first thing I tried, no dice.
You have 11.2.4.4 global on your phone right? Would you be able to retrieve the stock boot.img and upload it for me so I can try booting with that? It's a long shot but I'm desperate.
Click to expand...
Click to collapse
Uploaded to mega here
I found 2 backed up images and I wasn't sure which is 4.4 so I uploaded both to the link for you to try
So I tried fastboot flashing unlock_critical just now, and it fails and says Device already : unlocked!
I am finding that these instructions for restoring the OnePlus 8T do not work at all for the OnePlus 9. My phone boots straight to fastboot on slot a, and if I try fastboot reboot fastboot, it fails to boot to fastboot userspace.
On slot b, it will boot to fastboot userspace, which allows me to flash the partitions I extracted from the payload.bin, BUT the list of files is not the same as for the 8T. I flashed the ones that were in list, and a couple more that had similar names as missing ones, but it's still not a complete list. At no point have I done 'fastboot -w' as I don't want to wipe userspace.
I'm also not sure if I should try to flash every file it extracted to the equivalent partition name, as the instructions for the 8T don't do that.
toyanucci said:
Uploaded to mega here
I found 2 backed up images and I wasn't sure which is 4.4 so I uploaded both to the link for you to try
Click to expand...
Click to collapse
Thanks, didn't work unfortunately.
Slikkster2k said:
So I tried fastboot flashing unlock_critical just now, and it fails and says Device already : unlocked!
I am finding that these instructions for restoring the OnePlus 8T do not work at all for the OnePlus 9. My phone boots straight to fastboot on slot a, and if I try fastboot reboot fastboot, it fails to boot to fastboot userspace.
On slot b, it will boot to fastboot userspace, which allows me to flash the partitions I extracted from the payload.bin, BUT the list of files is not the same as for the 8T. I flashed the ones that were in list, and a couple more that had similar names as missing ones, but it's still not a complete list. At no point have I done 'fastboot -w' as I don't want to wipe userspace.
I'm also not sure if I should try to flash every file it extracted to the equivalent partition name, as the instructions for the 8T don't do that.
Click to expand...
Click to collapse
I had a similar situation with the 7T (and 8T lol) and used the info from the link as a guide to flashing every partition. I did have to wipe the phone though but in the end it booted up which was the biggest concern I had
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!