Related
Has anybody tried this... If so does it work? https://www.xda-developers.com/lineageos-15-1-resurrection-remix-available-project-treble/
Feel free to give it a try!
Flash the system image from TWRP, reboot to recovery, then flash Gapps (if desired). Keep a backup factory system image handy if needed.
@Telperion I wish I could... Unfortunately I don't have the pixel 2. I am very much thinking about buying one though.
I'm sure it works, there's just not been much need to run a custom ROM. I'm on P DP1 and there's not yet a P GSI so I'd have to downgrade to 8.1 before flashing.
Telperion said:
Flash the system image from TWRP, reboot to recovery, then flash Gapps (if desired). Keep a backup factory system image handy if needed.
Click to expand...
Click to collapse
When I tried installing TWRP on my Pixel 2 a few days ago, I found the ui does not respond to screen touches.
It might be simpler to just use fastboot flash a GSI.
Note that to get a GSI to work on the Pixel 2, you also need to adjust the contents of the "vbmeta" partition, which can be done using "fastboot".
There are details about it here https://github.com/phhusson/treble_experimentations/wiki
Can confirm lineage, resurrectionremix and aosp gsi by phh all work, although the twrp bug jamuir mentions did occur for me. I got around this by just flashing the gsi through the bootloader and not twrp. If you want to flash some gapps after flashing system and vbmeta (needed for pixel2), just fastboot boot twrp.img instead of rebooting to recovery. Here are basic steps I followed:
clean flash phone or do a factory reset from twrp, then boot to bootloader
fastboot flash system system-arm64-ab.img
fastboot --disable-verity --disable-verification flash vbmeta vbmeta.img #from factory image
#and if you want gapps
fastboot boot twrp.img
adb push opengapps.zip
flash your gapps
You'll get the "vendor mismatch" warning we've all come to know and love, as well as a "Hardware Overlay Picker stopped working" message on startup. Other than that, they all work.
I understand the premise of project treble, but I wonder what's the implication for custom rom developers. I'm probably mistaken, but it seems like they could just do a one-size-fits-all build for all devices now?
The twrp "not responding to touch" bug happens when you reboot into recovery straight from system using the advanced reboot menu. To prevent this, simply power off the device, and use the button combination to boot into twrp, voila, touch is now working.
Helloguys and gals,
I just got a Pixel 3 and wanted to root it. I followed this guide: https://www.youtube.com/watch?v=BgV1xxkcBk8
I installed the latest TWRP recovery (didn't keep it read only, maybe this was a mistake?). After that I installed Magisk which was followed by a bootloop.
To fix the bootloop I used TWRPs fix bootloop fix which worked. But that makes Magisk undone.
So my Questions is how to install Magisk? Do I need to flash the stock image on both slots and start again? Is the guide outdated? If so, which guide should I follow?
Edit: My phone is still on the update from November 2018.
On A/B devices there is no dedicated recovery partition anymore, recovery is contained in the boot partition, so if you install Magisk it's advised not to install TWRP on those devices anymore to avoid both modifying the same image, but instead to always fastboot boot when you need to use TWRP.
These are the steps I follow every time I need to factory reset then root my own Pixel 3 :
Boot to bootloader
Flash stock image on current slot
Flash stock image on other slot
Boot the system, enable Developer options and USB debugging
Fastboot boot TWRP image
Backup Boot partition
Flash Magisk
[optional] Flash custom kernel (check flashing order depending on kernel)
Reboot
bafforosso said:
On A/B devices there is no dedicated recovery partition anymore, recovery is contained in the boot partition, so if you install Magisk it's advised not to install TWRP on those devices anymore to avoid both modifying the same image, but instead to always fastboot boot when you need to use TWRP.
These are the steps I follow every time I need to factory reset then root my own Pixel 3 :
Boot to bootloader
Flash stock image on current slot
Flash stock image on other slot
Boot the system, enable Developer options and USB debugging
Fastboot boot TWRP image
Backup Boot partition
Flash Magisk
[optional] Flash custom kernel (check flashing order depending on kernel)
Reboot
Click to expand...
Click to collapse
Allright, thank you for your explanation! I used the stock image and the flash-all.bat to install the stock image. Will it be enough since you are speaking of two different slots? if not, how can i do both slots?
thx in advance
I run twrp as the devices recovery and have magisk. I would follow the twrp and magisk guides for this device. First boot twrp then use the installer, second reboot, third get to recovery and flash magisk. The boot partition needs to be rebooted before root. It is an initialization thing. Get twrp, reboot, magisk.
Having a similar issue here. I was rooted till the latest OTA happened a few days ago. Trying to re-root in several different ways, but all result in boot loop.
Methods I've tried:
Extracted boot.img from factory image, patched with Magisk Manager, flashed with fastboot
Fastboot boot twrp-3.3.0-0-blueline.img, installed Magisk-v19.3.zip
Fastboot boot twrp-3.3.0-0-blueline.img, installed twrp-pixel3-installer-blueline-3.3.0-0.zip, rebooted recovery, installed Magisk-v19.3.zip
Any ideas?
levibuko said:
Allright, thank you for your explanation! I used the stock image and the flash-all.bat to install the stock image. Will it be enough since you are speaking of two different slots? if not, how can i do both slots?
thx in advance
Click to expand...
Click to collapse
I tinker a lot with my phone so I usually want to have both slots clean flashed when I start back from scratch, not sure that is really necessary, but here are the steps I use for flashing both slots :
Code:
fastboot getvar current-slot
./flash-all.sh
fastboot --set-active=x (x being a or b, the other slot than the one you get with the fastboot getvar command)
./flash-all.sh
Exactly the same issue here, no luck. I'm only able to boot if I flash the stock boot.img. However, no root.
---------- Post added at 08:00 PM ---------- Previous post was at 07:52 PM ----------
tenthousandfeet said:
Having a similar issue here. I was rooted till the latest OTA happened a few days ago. Trying to re-root in several different ways, but all result in boot loop.
Methods I've tried:
Extracted boot.img from factory image, patched with Magisk Manager, flashed with fastboot
Fastboot boot twrp-3.3.0-0-blueline.img, installed Magisk-v19.3.zip
Fastboot boot twrp-3.3.0-0-blueline.img, installed twrp-pixel3-installer-blueline-3.3.0-0.zip, rebooted recovery, installed Magisk-v19.3.zip
Any ideas?
Click to expand...
Click to collapse
Exactly the same issue here, no luck. I'm only able to boot if I flash the stock boot.img. However, no root.
Boot twrp and install it, then reboot to system, then reboot recovery and install magisk. You need to boot system before installing magisk.
wangdaning said:
Boot twrp and install it, then reboot to system, then reboot recovery and install magisk. You need to boot system before installing magisk.
Click to expand...
Click to collapse
Tried that. No success.
Only thing I can think is to install an older magisk then let it update. I originally installed 18 something and have just let it update. I do not use google's factory image though, so cannot really help troubleshoot.
wangdaning said:
Only thing I can think is to install an older magisk then let it update. I originally installed 18 something and have just let it update. I do not use google's factory image though, so cannot really help troubleshoot.
Click to expand...
Click to collapse
I had a similar thought, but no dice. Tried installing Magisk 19.2, which boot looped just like the latest 19.3.
I even went back to 16.7, and though that one didn't boot loop it also didn't show up in the system. Magisk Manager didn't recognize it, anyway.
Though I'm loathe to do a full wipe/reset and then reconfigure all my junk, I may be headed in that direction as I'm running out of other ideas. Perhaps I'll save a backup just before that I can return to if the reset is fruitless.
---------- Post added at 07:53 AM ---------- Previous post was at 07:36 AM ----------
Magisk 18.0 does the same as 16.7 - no bootloop, but no root.
Interestingly, I noticed that the 18.0 and 16.7 zip installers say something about the partition being boot_a, whereas the bootlooping 19.2 and 19.3 zip installers say it's boot_b.
Run the Magisk uninstaller. Flash boot.img to both slots. Do a flash-all (minus the -w). With those things done, you should be essentially at reset state for this problem.
sliding_billy said:
Run the Magisk uninstaller. Flash boot.img to both slots. Do a flash-all (minus the -w). With those things done, you should be essentially at reset state for this problem.
Click to expand...
Click to collapse
Done. Followed that up with a TWRP flash of Magisk 19.2. Then... bootloop! Arg.
tenthousandfeet said:
Done. Followed that up with a TWRP flash of Magisk 19.2. Then... bootloop! Arg.
Click to expand...
Click to collapse
That stinks. Have you tried changing slots in fastboot boot instance of TWRP and then installing Magisk? It sure sounds like your slots are out of sync somehow, and the easiest way to remedy that is to run flash-all with -w in place.
sliding_billy said:
That stinks. Have you tried changing slots in fastboot boot instance of TWRP and then installing Magisk? It sure sounds like your slots are out of sync somehow, and the easiest way to remedy that is to run flash-all with -w in place.
Click to expand...
Click to collapse
I'm not sure if it's related to slots or not, actually. I was thinking that it was, but I've now done a flash-all on both slots (one after the other), then tried my TWRP flash of the Magisk installer again. Results? Bootloop.
I've also tried flashing Magisk Manager's patched_boot.img to both boot_a and boot_b, with the now-familiar outcome.
tenthousandfeet said:
I'm not sure if it's related to slots or not, actually. I was thinking that it was, but I've now done a flash-all on both slots (one after the other), then tried my TWRP flash of the Magisk installer again. Results? Bootloop.
I've also tried flashing Magisk Manager's patched_boot.img to both boot_a and boot_b, with the now-familiar outcome.
Click to expand...
Click to collapse
I hear you about flash-all on both slots, but if you left yourself on the same active slot there could still potentially be an issue. I'll need to think about this some more when I wake. I'd hate to see you do a full reset and end up with the same issue if it is something in the procedural that is causing it. One other thing that shouldn't be a concern, but are you using the proper/current TWRP for the P3 (twrp-3.3.0-0-blueline)? And yet one more thing... try rooting with a patched boot instead of running the installer in TWRP. I can't do the instructions by memory, but they are on here. Check the P3 XL page if they are not readily available on the P3 page.
tenthousandfeet said:
Done. Followed that up with a TWRP flash of Magisk 19.2. Then... bootloop! Arg.
Click to expand...
Click to collapse
Please update when/if you find a solution. We are both in the same boat.
I'll let you know if I get anything working.
sliding_billy said:
I hear you about flash-all on both slots, but if you left yourself on the same active slot there could still potentially be an issue. I'll need to think about this some more when I wake. I'd hate to see you do a full reset and end up with the same issue if it is something in the procedural that is causing it. One other thing that shouldn't be a concern, but are you using the proper/current TWRP for the P3 (twrp-3.3.0-0-blueline)? And yet one more thing... try rooting with a patched boot instead of running the installer in TWRP. I can't do the instructions by memory, but they are on here. Check the P3 XL page if they are not readily available on the P3 page.
Click to expand...
Click to collapse
Here's what I did to get both slots:
Code:
fastboot --set-active=_a
flash-all
fastboot reboot-bootloader
fastboot --set-active=_b
flash-all
fastboot reboot
adb reboot bootloader
fastboot boot twrp-3.3.0-0-blueline.img
Note the TWRP image is the latest - 3.3.0.
I've also tried flashing the Magisk-patched boot, using the following:
Code:
fastboot flash boot patched_boot.img
...and...
Code:
fastboot flash boot_a patched_boot.img
fastboot flash boot_b patched_boot.img
Everything reports success while flashing, but won't boot.
One more thing I could try is an updated ADB/Fastboot. Mine is probably a little dated, though I wouldn't expect that would have any ramifications for flashing with TWRP.
tenthousandfeet said:
Here's what I did to get both slots:
Code:
fastboot --set-active=_a
flash-all
fastboot reboot-bootloader
fastboot --set-active=_b
flash-all
fastboot reboot
adb reboot bootloader
fastboot boot twrp-3.3.0-0-blueline.img
Note the TWRP image is the latest - 3.3.0.
I've also tried flashing the Magisk-patched boot, using the following:
Code:
fastboot flash boot patched_boot.img
...and...
Code:
fastboot flash boot_a patched_boot.img
fastboot flash boot_b patched_boot.img
Everything reports success while flashing, but won't boot.
One more thing I could try is an updated ADB/Fastboot. Mine is probably a little dated, though I wouldn't expect that would have any ramifications for flashing with TWRP.
Click to expand...
Click to collapse
It still looks like your boot slot ended up the one you had tried already (b), since you changes to a and ran flash-all, changed back to b and ran flash-all and rebooted. As for the old platform tools, that could definnitly have an impact on running the fastboot of the patched boot. Other than that, I think a flash-all with the -w is the only approach left.
I'm also in the same boat. I've tried all the various install methods, and done the double "flash-all" on both slots, and no matter what, it ends in a bootloop.
Haven't tried the -w yet so I'll be interested if anyone gives that a go. Until then I'm dying with no root
Hi, earlier, I wanted to change the rom of my mi 5s. I've got an error 7 follow by "Failed to update system image" on twrp during the flash. I tried many things: edit the installation script, format all the data, update and downgrade TWRP, lock and unlock bootlander and finally perform a fastboot flash using mi flash and the last one worked. But I am not longer able to flash a custom rom without getting error 7 after the "Patching system image unconditionally" message. I've tested lineage, pixel experience, miui, even 8.1 rom but same result. I'm stuck with fastboot global miui 10 (oreo )
Btw, I think that after the error the partition are corrupted since I can't repair them with TWRP.
I don't know what I can do more.I think that i figured out that I am able to flash system.img file using fastboot but I can't flash zip rom using recovery.
As anyone encounter this ?
bob_bricoleur said:
Hi, earlier, I wanted to change the rom of my mi 5s. I've got an error 7 follow by "Failed to update system image" on twrp during the flash. I tried many things: edit the installation script, format all the data, update and downgrade TWRP, lock and unlock bootlander and finally perform a fastboot flash using mi flash and the last one worked. But I am not longer able to flash a custom rom without getting error 7 after the "Patching system image unconditionally" message. I've tested lineage, pixel experience, miui, even 8.1 rom but same result. I'm stuck with fastboot global miui 10 (oreo )
Btw, I think that after the error the partition are corrupted since I can't repair them with TWRP.
I don't know what I can do more.I think that i figured out that I am able to flash system.img file using fastboot but I can't flash zip rom using recovery.
As anyone encounter this ?
Click to expand...
Click to collapse
This usually happens when a partition is missed the way that TWRP doesn´t recognice the exact model and this error 7 is a kind of protection to avoid further mistake.
Some TWRP has in-built the option to fix system issue in advanced settings or then of try to flash a system image this option could appear.
Can you upload from any of the roms the updater script that is inside?
Also sometime you did a repartition? Or flashed some GSI?
SubwayChamp said:
This usually happens when a partition is missed the way that TWRP doesn´t recognice the exact model and this error 7 is a kind of protection to avoid further mistake.
Some TWRP has in-built the option to fix system issue in advanced settings or then of try to flash a system image this option could appear.
Can you upload from any of the roms the updater script that is inside?
Also sometime you did a repartition? Or flashed some GSI?
Click to expand...
Click to collapse
Here is a script from pixel experience:
https://pastebin.com/DXgKrB8Z
I have the error "E1001: Failed to update system image" or "E2001: Failed to update vendor image" or just error 7 if I remove all the abort and assert.
I never did a repartition or flashed a GSI.
bob_bricoleur said:
Here is a script from pixel experience:
https://pastebin.com/DXgKrB8Z
I have the error "E1001: Failed to update system image" or "E2001: Failed to update vendor image" or just error 7 if I remove all the abort and assert.
I never did a repartition or flashed a GSI.
Click to expand...
Click to collapse
Just to be sure I guess you removed all the lines with getprop and not only the words.
Try first flashing persist image through fastboot.
If not flash the rom not through fastboot but using EDL mode and MiFlash tool, if you have unlocked bootloader you can send device through adb with: adb reboot edl or through fastboot with: fastboot oem edl
SubwayChamp said:
Just to be sure I guess you removed all the lines with getprop and not only the words.
Try first flashing persist image through fastboot.
If not flash the rom not through fastboot but using EDL mode and MiFlash tool, if you have unlocked bootloader you can send device through adb with: adb reboot edl or through fastboot with: fastboot oem edl
Click to expand...
Click to collapse
Yep I removed all the line
I managed to flash a full fastboot rom with mi flash and I think that during the process, a persist image was flashed. So i'm runing a stock miui. I even managed to flash Twrp and magisk. But I can't flash a rom through TWRP even after that :crying:
bob_bricoleur said:
Yep I removed all the line
I managed to flash a full fastboot rom with mi flash and I think that during the process, a persist image was flashed. So i'm runing a stock miui. I even managed to flash Twrp and magisk. But I can't flash a rom through TWRP even after that :crying:
Click to expand...
Click to collapse
Some times causes different results flashing the fastboot full image through EDL mode (download mode) instead of through fastboot mode.
It could be the issue the TWRP version if there is other available.
And you could try deleting the recovery partition with fastboot erase recovery, then boot (don´t flash yet) to recovery using fastboot boot whateveriscalled.img, then in TWRP flash the TWRP image or the installer zip, then reboot for first time to TWRP and try again.
Update 12-16: I am closing this thread as it is no longer relevant. Please refer to this guide.
@V0latyle Can you help me out I installed a magisk module that caused a bootloop and I tried the adb wait-for-device shell magisk --remove-modules and it doesn't work for me I'm on the P5 a12 beta 5 I have since flashed the stock boot.img. What can I do to remove this module?
elong7681 said:
@V0latyle Can you help me out I installed a magisk module that caused a bootloop and I tried the adb wait-for-device shell magisk --remove-modules and it doesn't work for me I'm on the P5 a12 beta 5 I have since flashed the stock boot.img. What can I do to remove this module?
Click to expand...
Click to collapse
I'm honestly not that familiar with Magisk, sorry. I suggest you ask in the Magisk thread, they'll be of more help to you over there. Magisk modules live in /data, not /boot, so a data wipe would get rid of the module...and all your user data too.
V0latyle said:
I'm honestly not that familiar with Magisk, sorry. I suggest you ask in the Magisk thread, they'll be of more help to you over there. Magisk modules live in /data, not /boot, so a data wipe would get rid of the module...and all your user data too.
Click to expand...
Click to collapse
Ok thanks for your help I appreciate it
elong7681 said:
@V0latyle Can you help me out I installed a magisk module that caused a bootloop and I tried the adb wait-for-device shell magisk --remove-modules and it doesn't work for me I'm on the P5 a12 beta 5 I have since flashed the stock boot.img. What can I do to remove this module?
Click to expand...
Click to collapse
Wiki:
Module Issues:Magisk and MagiskHide Installation and Troubleshooting guide
www.didgeridoohan.com
Scroll down to read how to disable modules through Safe Mode
There is also a section how to manage modules from custom Recovery (if TWRP applies to your phone)
You seem to understand the issue with vmeta (and the associated data wipe). So I went from android 11 to android 12 beta without a wipe and although on andorid 11 i could flash my kernels, on android 12 i cannot without vmeta/wipe. I thought I read that it was because 12 was in beta. I plan to flash the factory image of 12 today, withotu doing a wipe of course. Will i be able to flash my custom kernles again?
How do we get in the download mode to install the OTA?
I do use adb reboot recovery
but every time, I got this.
E:\platform-tools>adb sideload E:\platform-tools\blueline-ota-sp1a.210812.015-cee465f5.zip
adb: sideload connection failed: device unauthorized.
This adb server's $ADB_VENDOR_KEYS is not set
Try 'adb kill-server' if that seems wrong.
Otherwise check for a confirmation dialog on your device.
adb: trying pre-KitKat sideload method...
adb: pre-KitKat sideload connection failed: device unauthorized.
This adb server's $ADB_VENDOR_KEYS is not set
Try 'adb kill-server' if that seems wrong.
Otherwise check for a confirmation dialog on your device.
E:\platform-tools>adb sideload E:\platform-tools\blueline-ota-sp1a.210812.015-cee465f5.zip
adb: sideload connection failed: no devices/emulators found
adb: trying pre-KitKat sideload method...
adb: pre-KitKat sideload connection failed: no devices/emulators found
ShadowJP88 said:
How do we get in the download mode to install the OTA?
I do use adb reboot recovery
but every time, I got this.
.....
Click to expand...
Click to collapse
Once you're in recovery, are you going into ADB sideload (hold the power button, then press the volume up key, then choose "Apply update from ADB")?
kfhughes said:
Once you're in recovery, are you going into ADB sideload (hold the power button, then press the volume up key, then choose "Apply update from ADB")?
Click to expand...
Click to collapse
I can't find out how... I only have the droid page with "no command" text
sorry i cant understand this:
* If, after flashing a patched boot image, you get the "unable to load/verify boot image", you probably didn't get the flags quite right. Just reflash vbmeta with the disable flags and that should fix the problem.
pixel 5 here, unlocked bootloader, did a clean flash, booted magisk , after direct install and restart i was stuck at booloader menu with that message, i don't understand what i have to do reading your post
where can i do this and how? Just reflash vbmeta with the disable flags
i had to clean flash again to use the phone
For re-flashing the vbmeta.img, my command has always been a little different than yours.
I use: fastboot flash --disable-verity --disable-verification vbmeta vbmeta.img
It's only a little different and your way might work, but if anyone has issues you could try this different command instead.
ShadowJP88 said:
I can't find out how... I only have the droid page with "no command" text
Click to expand...
Click to collapse
Hold down the power button and tap volume up to bring up the recovery menu.
V0latyle said:
With the Android 12 stable release just around the corner, I would like to make sure we have clear instructions on how to update with root.
These instructions work with the beta as well. This may seem redundant compared to other threads, but I wanted to consolidate the relevant information to one place.
WARNING: MANUALLY INSTALLING FACTORY UPDATES OR IMAGES REQUIRES AN UNLOCKED BOOTLOADER. If your bootloader is locked, DO NOT ATTEMPT THIS. You can, however, update using the OTA via ADB Sideload on a locked bootloader. DO NOT INSTALL THE BETA OTA WITH A LOCKED BOOTLOADER. BETA SOFTWARE IS EXPERIMENTAL AND MAY BE UNSTABLE, AND YOU MAY BE UNABLE TO RECOVER YOUR DEVICE IF SOMETHING GOES WRONG.
WARNING: MODIFY YOUR DEVICE AT YOUR OWN RISK. YOU ALONE WILL BE RESPONSIBLE FOR MALFUNCTION, DAMAGE, OR LOSS OF ANY KIND IF SOMETHING GOES WRONG.
Root will be done via Magisk. If you aren't already using it, download and install to your phone.
Warning: For the sake of simplicity, I frequently will use generalizations when referring to files ("[patched boot image]" instead of "magisk_patched-23001_xxxxx.img" for example). It is YOUR RESPONSIBILITY to ensure you are flashing the correct file. The easiest way to do this is type the command in the command line without the file itself, then drag and drop the file you want to flash into the command line window.
For those of you with a locked bootloader:
Simply install the update as usual via OTA, whether automatically through Android Update, or manually via adb sideload.
First, a bit of information on why you need to follow this guide (See this post)
Two new Verified Boot features implemented in Android 12 will interfere with attempts to root. A more detailed explanation is below if you would like.
Spoiler
Dm-verity (device-mapper-verity) is a method by which an image on block devices (the underlying storage layer of the file system) can be checked to determine if it matches an expected configuration, using a cryptographic hash tree. If the hash doesn't match, dm-verity prevents the stored code from loading.
Vbmeta verification is the other half of this - it provides a cryptographically signed reference hash which is used to verify the integrity of /boot, /system, and /vendor partitions. The vbmeta image is only used to verify /boot, while vbmeta-system is used to verify /system.
This was implemented to prevent persistent rootkits by means of a hardware level security check, to prevent "potentially harmful applications" such as Magisk from evading detection, as such applications residing within the kernel will have higher privileges than the detection applications.
What this means is that with these two enabled, a modified boot image will cause a verification error when flashed to the device, preventing boot. Interestingly, this check is not performed against "live" boot images loaded via ADB, so with dm-verity and vbmeta verification enabled, a modified image can be booted as long as the image in /boot is intact.
To update to Android 12 with data intact and reroot:
WARNING: Per Google, an Android 12 OTA should only be installed on a device running 12 DP or 12 Beta. However, other users were able to manually install the OTA via ADB without losing data, so DO THIS AT YOUR OWN RISK! It is currently unknown what Google's official instructions will be for installing the update, so the "best" current method is wait for automatic OTA.
Spoiler
If you update via automatic OTA:
1. Download the factory image (Yes, this is required) to your computer. Connect your device via USB.
2. Extract the contents of the factory image, then extract both boot.img and vbmeta.img from the image-[device].zip (where [device] is the codename for your device, such as Redfin for Pixel 5
3. Continue to Reflash vbmeta below
To manually install the OTA:
1. Download the OTA for your device, as well as the factory image (Yes, you need both) to your computer.
2. Install the OTA
3. Extract the contents of the factory image, then extract both boot.img and vbmeta.img from the image-[device].zip (where [device] is the codename for your device, such as Redfin for Pixel 5
4. Let the update complete, including reboot. Wait until you are in /system with the update process finished (no update notification)
5. Continue to Reflash vbmeta below
Reflash VBmeta
1. With device connected via USB, Developer Options enabled and USB Debugging enabled, reboot to bootloader using ADB:
Code:
adb reboot bootloader
2. Reflash vbmeta with dm-verity and boot verification disabled:
Code:
fastboot --disable-verity --disable-verification flash vbmeta vbmeta.img
3. Reboot to bootloader:
Code:
fastboot reboot bootloader
Continue to Patch Boot Image below.
To update to Android 12 using Android Flash Tool:
Spoiler
1. Open this link in Google Chrome (DO NOT USE MICROSOFT EDGE OR MOZILLA FIREFOX) Here is the link for beta
2. Connect your device via USB (make sure USB Debugging is enabled)
3. Enable ADB access in the browser
4. Select your device
5. Select the Android 12 build
6. IMPORTANT: Click the pencil icon next to the selected build
7. Ensure Wipe Device, Disable Verification, and Disable Verity are checked. DATA WIPE IS REQUIRED when updating from an older version of Android. Don't lock your bootloader if you want root. Force flash all partitions should not be necessary (but use this if you've run into problems and are starting over). Skip Secondary and Force Debuggable should be unchecked, unless you want to use ADB for root access on the stock kernel for some reason.
8. Click Install Build.
9. Wait until the update finishes.
10. Continue to Patch Boot Image below.
To update to Android 12 via ADB using the factory image:
Spoiler
1. Download the factory image to your computer and connect your device via USB, with USB debugging enabled.
2. Extract the contents of the factory ZIP
3. Reboot to bootloader:
Code:
adb reboot bootloader
4. If necessary, update the bootloader: WARNING: IF DONE INCORRECTLY THIS WILL BRICK YOUR DEVICE!
Code:
fastboot flash bootloader [bootloader image]
Reboot back to bootloader.
5. If necessary, update the radio:
Code:
fastboot flash radio [radio image]
Reboot to bootloader.
6. Install the update:
Code:
fastboot --disable-verity --disable-verification -w update [factory image zip]
DATA WIPE IS REQUIRED when updating from an older version of Android.
7. Let the update complete
8. Continue to Patch Boot Image below
Patch Boot Image:
Spoiler
1. Extract boot.img from the factory image ZIP if you haven't done so already
2. Install Magisk on your phone
3. Move the boot image to your phone via USB, and patch it using "Select and Patch a File" in Magisk
4. Move the patched boot image back to your PC
5. Reboot to bootloader
6. Flash the patched boot image:
Code:
fastboot flash boot [patched boot image]
7. Reboot to system.
For subsequent updates to Android 12:
Either install the update via OTA Sideload, then reflash vbmeta with disable flags set, or dirty flash the factory image with disable flags set.
Live boot your patched boot image from bootloader (as long as you're still on Android 12, the old kernel should work fine):
Code:
fastboot boot [patched boot image]
In system, launch Magisk then select "Direct Install" to patch the stock image in /boot.
Key reminders:
* The OTA does not have a way to set the disable flags for vbmeta, so if you update via OTA, you will have to reflash vbmeta with the disable flags every time you update.
* If you forget to do this and have a patched boot image, bootloader will return an error: "failed to load/verify boot image"
* The fastest and easiest way to update is via OTA, but remember you will lose root until you're able to reflash vbmeta and repatch the boot image.
* Manually patching the new boot image in Magisk via "Select and Patch a File" should be unnecessary every time you update. You can, instead, just keep the image you originally patched, boot it every time you update, and flash the stock image in /boot using Magisk.
* If, after flashing a patched boot image, you get the "unable to load/verify boot image", you probably didn't get the flags quite right. Just reflash vbmeta with the disable flags and that should fix the problem.
Click to expand...
Click to collapse
@V0latyle I think I know why some people are having issues with obtaining root or maintaining root on Android 12 official release... When you use the following command,
Code:
fastboot --disable-verity --disable-verification flash vbmeta vbmeta.img
I think after this command and then flashing the patched magisk boot image their might be a check on both slots. Would I be wrong suggesting for the disable vbmeta command be this instead?
Code:
fastboot --disable-verity --disable-verification flash --slot=all vbmeta vbmeta.img
I was having the same issue where it was saying that the system was corrupt and having to do a factory wipe after doing the command without --slot=all for the vbmeta disable flag command.
rester555 said:
@V0latyle I think I know why some people are having issues with obtaining root or maintaining root on Android 12 official release... When you use the following command,
Code:
fastboot --disable-verity --disable-verification flash vbmeta vbmeta.img
I think after this command and then flashing the patched magisk boot image their might be a check on both slots. Would I be wrong suggesting for the disable vbmeta command be this instead?
Code:
fastboot --disable-verity --disable-verification flash --slot=all vbmeta vbmeta.img
I was having the same issue where it was saying that the system was corrupt and having to do a factory wipe after doing the command without --slot=all for the vbmeta disable flag command.
Click to expand...
Click to collapse
I haven't read his full instructions hidden behind the spoiler tags, but in my experience after flashing the vbmeta.img the first time, I needed to follow it with "fastboot -w" and wipe my phone, then flash the patched boot.img.
On subsequent updates as long as I booted to bootloader immediately after flashing the OTA.zip to flash vbmeta, I didn't have to wipe. If I boot to system by mistake, I'll need to fastboot -w again
rester555 said:
@V0latyle I think I know why some people are having issues with obtaining root or maintaining root on Android 12 official release... When you use the following command,
Code:
fastboot --disable-verity --disable-verification flash vbmeta vbmeta.img
I think after this command and then flashing the patched magisk boot image their might be a check on both slots. Would I be wrong suggesting for the disable vbmeta command be this instead?
Code:
fastboot --disable-verity --disable-verification flash --slot=all vbmeta vbmeta.img
Click to expand...
Click to collapse
xunholyx said:
I haven't read his full instructions hidden behind the spoiler tags, but in my experience after flashing the vbmeta.img the first time, I needed to follow it with "fastboot -w" and wipe my phone, then flash the patched boot.img.
On subsequent updates as long as I booted to bootloader immediately after flashing the OTA.zip to flash vbmeta, I didn't have to wipe. If I boot to system by mistake, I'll need to fastboot -w again
Click to expand...
Click to collapse
@xunholyx I did what you suggested, flashing the vbmeta.img and then patching the magisk boot image and I got the corrupt system message in recovery. So I ended up reflashing stock image with wipe through adb.. did minimal initial setup, then reflashed the vbmeta.img to all slots and then immediately flashed the patched magisk image. That seemed to work for me to gain root on A12.
Did as you showed , and it works well .Thank!
4a 5G here (sorry, I know that this is the section for Pixel 5, but I assume most or all things are the same). I rushed and installed the OTA the normal way, thinking I'll be able to patch and flash boot.img afterwards (like normally). Update went fine (upgrading from 11, haven't used any of the DPs/betas), but after I flash the patched boot.img, I get "failed to load/verify boot images" in fastboot. Am I out of luck?
rester555 said:
@V0latyle I think I know why some people are having issues with obtaining root or maintaining root on Android 12 official release... When you use the following command,
Code:
fastboot --disable-verity --disable-verification flash vbmeta vbmeta.img
I think after this command and then flashing the patched magisk boot image their might be a check on both slots. Would I be wrong suggesting for the disable vbmeta command be this instead?
Code:
fastboot --disable-verity --disable-verification flash --slot=all vbmeta vbmeta.img
I was having the same issue where it was saying that the system was corrupt and having to do a factory wipe after doing the command without --slot=all for the vbmeta disable flag command.
Click to expand...
Click to collapse
So are you saying that using the slot all flag fixed your problem?
killchain said:
4a 5G here (sorry, I know that this is the section for Pixel 5, but I assume most or all things are the same). I rushed and installed the OTA the normal way, thinking I'll be able to patch and flash boot.img afterwards (like normally). Update went fine (upgrading from 11, haven't used any of the DPs/betas), but after I flash the patched boot.img, I get "failed to load/verify boot images" in fastboot. Am I out of luck?
Click to expand...
Click to collapse
Did you follow the instructions on flashing vbmeta with the disable flags set?
Another 4a 5G owner here. I installed the OTA via recovery yesterday and tried to flash a patched boot.img, but got "failed to load/verify boot images". Reanimated the phone using a factory image, then tried to flash vbmeta.img with verification disabled (but no wipe) and patched boot.img. The phone couldn't boot into the system and offered to perform factory reset. I didn't want to wipe anything so I didn't go with it, but it seems like there is no way to root 4a 5G and keep your data (at least for now).
But I will be happy to be proven wrong!
Bricked my OP8T (unlocked bootloader, rooted) in a failed OS update attempt. I'm pretty sure I was running OS 11.0.8.12, attempted updating to 11.0.11.11 following Magisk OTA update instructions to keep root. It seemed to mess up as when I viewed OS info, 11.0.8.12 was still listed, but then phone calling, wifi, audio all were broken. So I then attempted the local upgrade option, which didn't work at all. After rebooting, found myself in Qualcomm crash boot, but was able to still get to fastboot using Vol Up + Vol Down + Power key combination.
I've attempted switching active boot slots and that didn't fix anything. My slot a seems to have considerable issues so been trying to reflash images to b slot. I've extracted all images from payload.bin from both 11.0.8.12 and 11.0.11.11. I also have magisk patched boot images for both versions of OS's on my PC. When I've attempted flashing 11.0.11.11 system image, I get errors regarding can't resize partition, not enough space. I've tried 'Fastboot delete-logical-partition product', but still received same error. So I've thought, I'll just reflash the 11.0.8.12 images and try to get my phone back to bootable.
I've ran the following commands to attempt to get back to bootable phone:
fastboot flash boot boot.img
fastboot flash recovery recovery.img
fastboot reboot bootloader
fastboot --disable-verity flash vbmeta vbmeta.img
fastboot--disable-verity flash vbmeta_system vbmeta_system.img
fastboot reboot fastboot
fastboot flash system system.img
fastboot flash vendor vendor.img
fastboot flash product product.img
fastboot reboot bootloader
Issue is now that whenever I attempt to reboot the phone, it automatically boots back into fastboot :/ I've attempted wiping the cache too in hopes it would help but no dice.
Curious if there is a way to recover the phone without wiping my data partition. I've got most apps and settings backed up but it's still a hassle I'd prefer to avoid. Would it be possible to boot into TWRP using 'fastboot boot twrp.img' to pull the user data partition to local pc? Then wipe the phone and install fresh OS? I've heard that twrp can't decrypt the user data partition for stock OP Roms?
TWRP have always been able to decrypt user data for stock OOS roms. The latest twrp version can even flash OOS rom (thanks to a patch by a helpful community member).
If I where you I would try to boot latest TWRP and see if that can decrypt the data (do not freak out if it can't there might still be a way to save the data).
If it can decrypt data I would perform a backup of the data partition and then copy your whole internal sd over to your computer just to be safe.
After that I would try to flash the latest OOS ota in TWRP and see if that fixes it. If not you can try to format data and reboot. If that fixes it you can just restore your data backup. If that don't work I would use the MSM tool and then unlock bootloader and restore data backup.
If TWRP are unable to decrypt the data I would sideload the OOS ota in TWRP and see if that fixes it (it did for me when I had a similar problem). If not your data is lost and you might need to use MSM tool.
I would wait to install magisk until I made sure everything boots without it.
Qnorsten said:
TWRP have always been able to decrypt user data for stock OOS roms. The latest twrp version can even flash OOS rom (thanks to a patch by a helpful community member).
If I where you I would try to boot latest TWRP and see if that can decrypt the data (do not freak out if it can't there might still be a way to save the data).
If it can decrypt data I would perform a backup of the data partition and then copy your whole internal sd over to your computer just to be safe.
After that I would try to flash the latest OOS ota in TWRP and see if that fixes it. If not you can try to format data and reboot. If that fixes it you can just restore your data backup. If that don't work I would use the MSM tool and then unlock bootloader and restore data backup.
If TWRP are unable to decrypt the data I would sideload the OOS ota in TWRP and see if that fixes it (it did for me when I had a similar problem). If not your data is lost and you might need to use MSM tool.
I would wait to install magisk until I made sure everything boots without it.
Click to expand...
Click to collapse
Unfortunately I wasn't able to get TWRP to decrypt my data :/ Tried using TWRP with stock boot image flashed as well as with magisk patched boot image.
Tried using the following guide here to see if I could make it happen while saving my data but was unsuccessful. Ah well, glad I use Swift Backup and SMS Backup & Restore. Should make restoring phone to prior state a bit easier, but still a little pain in the butt.
I'm pretty sure I've run into issues in the past with upgrades on OnePlus and new versions not being able to decrypt previously encrypted user data. Hence why I was resistant to upgrading for the last 5 months. Hopefully the upgrade to the december update goes a little smoother.
Appreciate the advice/guidance @Qnorsten!
Sorry to hear that didn't help. I never had any problems with any updates, except when I was messing around with TWRP and that was my own fault.
Older OOS versions can't decrypt data from newer versions but if you flash a newer one it should work.
Have you tried sideloading the latest full OOS ota zip in TWRP?