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!
Related
My device is a rooted, TWRP-enabled OnePlus 7 Pro ... GM1917.
Through some failed flash attempts in the past, I hosed my "A" boot partition, meaning that I can't boot into it, nor do any meaningful work in it via TWRP. The data partition is empty and cannot be written to when I boot into TWRP via the "A" partition. My "B" partition is fine, and my device is running fine with that partition active.
Is there any way to get my "A" boot partition back to being properly functional without messing up my current device configuration? For example, one question I have is this: if I format the data partition in TWRP when I'm booted into the "A" partition, will it format the working data partition that I see when I boot into "B", thereby causing me to lose everything that is currently resident on this data partition?
I don't have a good understanding of the A/B boot partition methodology, so any help will be greatly appreciated.
.
I think you should do a clean factory reset
https://forums.oneplus.com/threads/...ide-for-a-hard-bricked-oneplus-7-pro.1041896/
sonvotrung said:
I think you should do a clean factory reset
https://forums.oneplus.com/threads/...ide-for-a-hard-bricked-oneplus-7-pro.1041896/
Click to expand...
Click to collapse
Thank you, and I agree. I tried a few things via fastboot, but they didn't fix the problem.
Playing with TWRP, fastboot, and boot slots has been an over-complicated headache.
In following your link and reading, I see that this is the flash download that I need:
https://otafsg1.h2os.com/patch/amaz...ygen_21.O.16_OTA_016_all_1908281716_b2bb5.zip
I downloaded it. Then, does the following procedure appear to be correct? ...
First, back up everything that's important on my data partition. Then, from my desktop ...
Code:
fastboot --set-active=b
fastboot reboot bootloader
... just to make sure that "B" is indeed currently the active partition, which it should be.
I should then boot back into my system and flash that ROM I downloaded.
I should flash it via Settings->System update->Local upgrade.
After the system reboots and I get it initialized, I should make sure that OEM unlocking is set,
I can then boot back into the bootloader and do the following
Code:
fastboot flashing unlock
Then, after the system reboots again and I make sure my system is set up properly, I should reboot yet again to the boot loader.
I should then run this command:
Code:
fastboot boot twrp-3.3.1-4-guacamole.img
This should bring up TWRP recovery. Inside of TWRP, I should go into Advanced->Sideload, and then from my desktop ...
Code:
adb sideload twrp-installer-3.3.1-4-guacamole.zip
In TWRP, I should go back to sideload and then do the following from my desktop ...
Code:
adb sideload Magisk-v20.1.zip
At this point, I should boot back into my system and get everything restored and set up the way I want.
Does this all look correct?
Thank you again!
.
Hmmm.. happened to my boot a partition too.. it cant boot because i flashed dm verity or something like that hoping that it would erase the lock pattern before entering and decrypting TWRP. but it failed. Took.me about an hour before i noticed that if i boot my phone to partition B.. its working fine.. when i boot to B.. i have read somewhere that android 10 installs on inactive slot..so i gambled to see if it would.fix my partition A that i think has been corrupted.. and so.it. worked. I lost my root and TWRP BECAuse i rebooted too soon..but hey... Patching my boot img with magisk..gives me a rooted device again...
So,. Im suggesting to flash ANDROID 10 FULL ROM.VIA Local upgrade then reboot.. i think it will be installed to your inactive slot and will fix the corrupt issue.. ehehehehe
santiagoruel13 said:
Hmmm.. happened to my boot a partition too.. it cant boot because i flashed dm verity or something like that hoping that it would erase the lock pattern before entering and decrypting TWRP. but it failed. Took.me about an hour before i noticed that if i boot my phone to partition B.. its working fine.. when i boot to B.. i have read somewhere that android 10 installs on inactive slot..so i gambled to see if it would.fix my partition A that i think has been corrupted.. and so.it. worked. I lost my root and TWRP BECAuse i rebooted too soon..but hey... Patching my boot img with magisk..gives me a rooted device again...
So,. Im suggesting to flash ANDROID 10 FULL ROM.VIA Local upgrade then reboot.. i think it will be installed to your inactive slot and will fix the corrupt issue.. ehehehehe
Click to expand...
Click to collapse
Thank you. Yes, I plan to flash the new 10.0.2 ROM soon, and I am glad to know from your experience that this should indeed solve my problem with the "A" slot.
Regarding dm-verity ... did you ever get that to work? I want to decrypt my phone, but I'm still not confident that dm-verity will work for me.
HippoMan said:
Thank you. Yes, I plan to flash the new 10.0.2 ROM soon, and I am glad to know from your experience that this should indeed solve my problem with the "A" slot.
Regarding dm-verity ... did you ever get that to work? I want to decrypt my phone, but I'm still not confident that dm-verity will work for me.
Click to expand...
Click to collapse
Nope.. i cant seem to make it work.. it just messes up and corrupt my phone partition slot.. dont know why.
It says decrypting phone.. successful.. and then.. it wont boot.
santiagoruel13 said:
Nope.. i cant seem to make it work.. it just messes up and corrupt my phone partition slot.. dont know why.
It says decrypting phone.. successful.. and then.. it wont boot.
Click to expand...
Click to collapse
Thank you. You have saved me a big headache, because now I won't even try to decrypt.
I'll keep investigating decryption, however, and if I can get it to work, I'll let you know
There seem to be a lot of posts in the following thread where people report problems similar to yours, so maybe we just have to wait until there is some sort of enhancement to dm-verity, or perhaps a new method for decrypting.
The thread: https://forum.xda-developers.com/android/software/universal-dm-verity-forceencrypt-t3817389
PS: I just saw this message: https://forum.xda-developers.com/showpost.php?p=80185974&postcount=599
This person first formatted data, then rebooted TWRP, then did a factory reset, and then did the rest of the flashing.
Also, as you can see, the flashing was done twice, with a TWRP reboot in between.
Did you perform that many steps when you tried to decrypt via dm-verity?
.
Boot to twrp
Format data
Reboot twrp again
Flash A10.01 rom
Flash TWRP
REBOOT TWRP
Flash decrypt via dm verity
REBOOT.. STUCK..
santiagoruel13 said:
Boot to twrp
Format data
Reboot twrp again
Flash A10.01 rom
Flash TWRP
REBOOT TWRP
Flash decrypt via dm verity
REBOOT.. STUCK..
Click to expand...
Click to collapse
In the other message whose link I posted, the writer did repeated flashing and more rebooting, including 3 dm verity flashes.
I think this multiple flashing and rebooting might be necessary because of the A/B slots, but I'm not sure ...
Format data,reboot twrp,factory reset,flash rom ,flash twrp ,flash dm verity.
Reboot again twrp
flash again rom,twrp,dm verity
Reboot twrp
flash gapps(when nedded)magisk(im using 19.4) flash dm verity.
Reboot system.
Click to expand...
Click to collapse
I'll have time to try all this on the weekend.
I fixed the problem via the following steps ...
(1) uninstall all Magisk modules
(2) reboot to System
(3) install the 10.0.2 OOS ROM via System Update->Local upgrade
(4) boot to bootloader
(5) "fastboot boot twrp.img" (version 3.3.1-70)
(6) go into Sideload and flash the twrp 3.3.1-70 installer
(7) reboot recovery
(8) go into Sideload and flash Magisk 20.1
(9) reboot to System
(10) reinstall the xXx-NoLimits ROM (version 9.3) via Magisk
In the process, I ended up with 10.0.2, as well.
IMPORTANT!! THESE FILES / THIS THREAD IS FOR PIXEL 4 XL "CORAL" ONLY, NOT PIXEL 4 "FLAME"!!
**IT IS HIGHLY RECOMMENDED TO PATCH THE STOCK BOOT IMAGE YOURSELF, FROM YOUR OWN DEVICE, USING MAGISK MANAGER. WHILE THERE'S A GOOD CHANCE THE FILE I PROVIDED BELOW WILL BE IDENTICAL (USE A FILE HASH CHECKSUM TOOL IF YOU'RE CURIOUS), THERE IS ALSO A CHANCE THEY MAY HAVE SMALL, BUT SIGNIFICANT, VARIANCES**
Thanks for the info and link, @wrongway213
Link to @topjohnwu's post: twitter dot com /topjohnwu/status/1272136975022084097?s=19 (until I figure out how to stop new XDA from forcing the URL to embed a giant twitter posting in the middle of the post...)
ALL FILES BELOW ARE FOR "RQ2A.210305.006, Mar 2021"!
Magisk v22.0 Patched Boot Image: https://www.androidfilehost.com/?fid=17248734326145746586
Factory Untouched Boot Image: https://www.androidfilehost.com/?fid=17248734326145746583
Factory Untouched DTBO Image: https://www.androidfilehost.com/?fid=17248734326145746585
----------------------------------------------
-------------UPDATE PROCESS BELOW-------------
----------------------------------------------
EASY UPDATE / SEAMLESS KEEP-ROOT UPDATE PROCESS (using a PC - a very intuitive, effective, and relatively safe method).
** You can only follow this guide verbatim if coming EXACTLY from build "11.0.0 (RQ1A.210205.004, Feb 2021)". But the general idea is the same for other builds, you just need the correct files for your device.
coral-rq1a.210205.004-factory-dtbo.img: https://www.androidfilehost.com/?fid=17248734326145727318
coral-rq1a.210205.004-factory-boot.img: https://www.androidfilehost.com/?fid=17248734326145727317
March 2021 sideload OTA zip: https://dl.google.com/dl/android/aosp/coral-ota-rq2a.210305.006-c7e59bf8.zip
DO NOT BOOT BACK INTO O/S UNTIL ALL STEPS ARE COMPLETED - THIS ENSURES EVERYTHING BOOTS BACK UP WITH MAGISK / EDXPOSED ALL RUNNING PROPERLY RIGHT AWAY
1. boot into bootloader
----------------
** I was on custom kernel, so I needed to flash BOTH the stock boot and dtbo images
2. fastboot flash boot coral-rq1a.210205.004-factory-boot.img
3. fastboot flash dtbo coral-rq1a.210205.004-factory-dtbo.img
......* these steps to restore stock recovery; dtbo.img also necessary for some kernel installations.
......* won't hurt to flash both anyway, so if you're unsure, go ahead and do both.
-----------------
4. use volume keys to change selection to boot to Recovery Mode
......- when you reach the android symbol with No Command, hold power button, tap volume up, in case you've forgotten
5. choose option "Apply update from ADB"
6. adb sideload coral-ota-rq2a.210305.006-c7e59bf8.zip
7. Once the OTA sideload is done, Reboot to bootloader (you'll also notice it's now on the other slot after OTA flashed)
8. fastboot flash boot coral-rq2a.210305.006-magisk_patched-22.0.img
9. done, start the phone
(Optional - Flash custom kernel. If you had a custom kernel, you need to re-flash it)
This is a 100% seamless update that requires no additional / re-setup of any of my Magisk or EdXposed setups. All of the factory files can be found here https://developers.google.com/android/images. boot.img and dtbo.img are in their corresponding full Factory Image zips, and the ota zip is under Full OTA Images.
-------------------------------------------------
-------------------TROUBLESHOOTING-------------------
-------------------------------------------------
Issues after updating?
If you end up unable to boot or bootlooping afterwards, you most likely have an old Magisk module that isn't playing nice with the new build. There are 2 main things you can do:
1. Flash the new factory untouched boot image. You will of course lose root, and all modules will be disabled. However, it should at least get you able to boot back up quickly and have a working phone if you're in a bind.
2. I would recommend checking Tulsadiver's thread: https://forum.xda-developers.com/pixel-4-xl/how-to/magisk-modules-disabler-booting-magisk-t3990557
Instead of reverting to stock boot image, fastboot boot (NOT FLASH) Tulsadiver's boot image. This will boot your phone in Magisk Core-Only Mode, with all modules disabled but root retained. From here you can open Magisk Manager and disable suspect modules. Before rebooting, go to Magisk Manager's settings and disable Magisk Core-Only Mode. Once you disable the incompatible module, the phone should boot back up.
- See this post (or thread) for more tips / context / an example: https://forum.xda-developers.com/showpost.php?p=82509691&postcount=16
Since Magisk v21.x, Core Only mode has been replaced by using Android's built-in Safe Mode. Booting into Safe Mode should essentially boot you back into your system but with all modules disabled (as well as Magisk Hide). Keep in mind that even after you reboot, modules will remain disabled, unless you re-enable them first. Also remember to re-enable Magisk Hide if you had it enabled before.
Please see @Didgeridoohan's guide for more details: https://www.didgeridoohan.com/magisk/MagiskModuleIssues#hn_Core_Only_Mode
It's also worth mentioning, his guide is extremely well-made and contains a lot of useful information that could benefit all Magisk users and modders. I highly recommend looking through it anyway!
I've tried this but it keeps rebooting into fastboot mode with "no valid slot to boot". Also tried other kernels but can only boot to the unpached boot img.
neomasterpt said:
I've tried this but it keeps rebooting into fastboot mode with "no valid slot to boot". Also tried other kernels but can only boot to the unpached boot img.
Click to expand...
Click to collapse
Did you try flashing the patched img to both slots?
Code:
fastboot flash boot magisk_patched.img --slot all
worked like a charm. thanks
The update itself worked with your method. However since then my phone keeps freezing after I try to unlock it. Ergo it boots up normally, I see the start screen but when I try to unlock it by writing down my pin, the phone freezes and instandly restarts. I already tried booting to safemode and disabling all magisk modules, but it seems that this did not work.
This is my method works all the time.
patched boot.img via magisk
fastboot flash bootloader<bootloader.img>
fastboot reboot bootloader
fastboot flash radio<radio.img>
fastboot reboot bootloader
fastboot --skip-reboot update<image.zip>
fastboot reboot bootloader
fastboot flash boot<patchedboot.img>
fastboot reboot
neomasterpt said:
I've tried this but it keeps rebooting into fastboot mode with "no valid slot to boot". Also tried other kernels but can only boot to the unpached boot img.
Click to expand...
Click to collapse
Did you get this sorted out?
Morgrain said:
The update itself worked with your method. However since then my phone keeps freezing after I try to unlock it. Ergo it boots up normally, I see the start screen but when I try to unlock it by writing down my pin, the phone freezes and instandly restarts. I already tried booting to safemode and disabling all magisk modules, but it seems that this did not work.
Click to expand...
Click to collapse
I would try flashing the stock boot image and see if you can get in.
Maybe can also try flashing the full factory image with the -w removed in the script file. Just run stock first (don't replace the boot.img with the Magisk patched boot) to make sure it's not Magisk related.
I hate to bring potential bad news, but I had something similar happen, twice now. Though not exactly as described. Both times I had to full wipe too... First time, I woke up to my phone being completely out of space, and while I could unlock, I would only have a few seconds (seemingly random) to use the phone before it would freeze and reboot. I thought maybe it had to do with the phone running out of space at the time.
When it happened again a few months later, my phone had plenty of space. But like last time, phone would boot up, I would unlock, and then it would run like crap until eventually forced rebooting. Trying all combinations of stock / Magisk / modified boot images, flashing full firmware (with -w removed), rolling back to previous firmware... Nothing worked and eventually it just got stuck at the G logo. Had to full wipe at that point, but luckily I had backups of my important stuff.
First time happened on Android 10, second time happened on Android 11. Weird. There's actually a thread I read a while back with people describing the same issue, and ultimately seems like only a full wipe fixed it.
Oh and one last thing - for me, while I can't prove it, both times it happened shortly after I installed the Storage Isolation / Redirect (Riru) app / module... Didn't occur to me until later that maybe that somehow messed with some permissions related to System UI that even disabling the module later wouldn't fix. I use it on my other devices without issue, but I have since never installed it back on my P4XL and no problems in months. Also both times, Magisk Manager was also acting crazy, and I couldn't flash new modules or anything. It kept saying it didn't have storage permissions, even though it did, and no amount of uninstalling / reinstalling / etc would bring it back to a working state. Again why I somewhat suspect Storage Isolation was causing some weird stuff to happen...
But since it only happened to you after updating, hopefully it's something else, and hopefully going stock can maybe get you back running. Maybe one of the partitions failed to update or something, and flashing the full image can help. Just remember to remove the "-w" flag in the batch / shell file or it'll wipe your data!!!
Edit: oh, this is probably pretty important, were you already running Magisk v22.0? Magisk Manager is completely revamped in 22.0, and I wouldn't be surprised if you would have problems if running older Magisk Manager with Magisk 22.0. If you were still on 21.x and Manager 8.x, I would flash last months firmware (-w removed, blah blah), update to Magisk 22.0, and then run the OTA... Best of luck, I hope it all works out for you!
Booted my old ssd with windows 10 just to update from feb to march.
Everything fine so far using your files no idea whats wrong with my new Windows ssd tho lol
I'm also getting the "no valid slot to boot" both with the self patched boot image and the one posted here.
Tried this command "fastboot flash boot magisk_patched.img --slot all" did not work.
Jesus1988 said:
Did you try flashing the patched img to both slots?
Code:
fastboot flash boot magisk_patched.img --slot all
Click to expand...
Click to collapse
Nope! did not work!
I can boot with Cleanstate kernel also. Just not Magisk. also tried to patch cleanstate but the patched version wont boot.
neomasterpt said:
Nope! did not work!
I can boot with Cleanstate kernel also. Just not Magisk. also tried to patch cleanstate but the patched version wont boot.
Click to expand...
Click to collapse
Were you already on Magisk 22.0 before updating?
Either way, flash this month's factory dtbo and boot images to their respective partitions. See if you can boot. Could be working the way you described because another installation patched your dtbo and it needs to be reverted.
If you were on Magisk 21.x before updating, upgrade Magisk Manager (now just Magisk.apk) to 22.0. Make sure to follow all warnings on Magisk's changelog (if Magisk Manager app package was hidden before, unhide before updating).
Flash the Magisk 22.0 patched boot image. Flash either the one in the OP or patch it yourself using Magisk (Manager) 22.0. Boot the phone. If it works, flash kernel in EX / FR KM.
Also please let me know if you were on Magisk 22.0 or 21.x before updating. I wanna know if this could cause problems as I mentioned previously.
i5lee8bit said:
Were you already on Magisk 22.0 before updating?
Either way, flash this month's factory dtbo and boot images to their respective partitions. See if you can boot. Could be working the way you described because another installation patched your dtbo and it needs to be reverted.
If you were on Magisk 21.x before updating, upgrade Magisk Manager (now just Magisk.apk) to 22.0. Make sure to follow all warnings on Magisk's changelog (if Magisk Manager app package was hidden before, unhide before updating).
Flash the Magisk 22.0 patched boot image. Flash either the one in the OP or patch it yourself using Magisk (Manager) 22.0. Boot the phone. If it works, flash kernel in EX / FR KM.
Also please let me know if you were on Magisk 22.0 or 21.x before updating. I wanna know if this could cause problems as I mentioned previously.
Click to expand...
Click to collapse
Still does not work.
And yes I was on v22.
neomasterpt said:
Still does not work.
And yes I was on v22.
Click to expand...
Click to collapse
But you can boot stock? Did you try booting in safe mode yet?
If you can't even boot to safe mode while Magisk patched boot is installed, as a last resort, and may be overkill because unfortunately I don't physically have access or know your whole setup, download the Feb 2021 full factory image. Flash it with the "-w" flag removed so you don't lose data. Install Magisk 22.0 apk, patch the stock boot file (for Feb 2021) and flash it. Hopefully it boots back to your previous state on Feb 2021 firmware before attempting upgrade.
Now we can try 2 different directions. Overkill version: open Magisk Manager and (complete) uninstall. Now take the OTA as per OP instructions and hopefully it boots now. You should be rooted but now with no modules installed.
Or, try disabling any potential modules that may be causing problems before updating again. Reboot once fully after disabling before doing upgrade. I would recommend disabling anything that targets SystemUI, as well as Ed/LS-posed. Or perhaps it could be an Xposed module itself.
Good luck.
I had to do a full wipe before getting root to work and boot. Probably due to something with Magisk updating to v.22
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 followed this guide exactly: https://topjohnwu.github.io/Magisk/ota.html
Before starting the guide, I had a pretty new Pixel 7 Pro with the latest version of Magisk successfully installed (with bootloader UNLOCKED) and some small Magisk modules to tweak things (iOS emojis). I made sure to restore boot images and got the "restoration complete" toast message.
I saw the notification for the November update, downloaded and installed it. I did NOT reboot after that. I then went into the Magisk app and tapped "install to inactive slot (after OTA)" and rebooted from within the Magisk app.
My device rebooted, and showed me the bootloader unlocked screen, then showed me the "your device is corrupt" warning and said "press power button to continue". I pressed the power button and my device is now stuck on the Google logo.
Has this happened to anyone else? And is there any way to fix this (preferably without data loss)?
Pritster5 said:
I followed this guide exactly: https://topjohnwu.github.io/Magisk/ota.html
Before starting the guide, I had a pretty new Pixel 7 Pro with the latest version of Magisk successfully installed (with bootloader UNLOCKED) and some small Magisk modules to tweak things (iOS emojis). I made sure to restore boot images and got the "restoration complete" toast message.
I saw the notification for the November update, downloaded and installed it. I did NOT reboot after that. I then went into the Magisk app and tapped "install to inactive slot (after OTA)" and rebooted from within the Magisk app.
My device rebooted, and showed me the bootloader unlocked screen, then showed me the "your device is corrupt" warning and said "press power button to continue". I pressed the power button and my device is now stuck on the Google logo.
Has this happened to anyone else? And is there any way to fix this (preferably without data loss)?
Click to expand...
Click to collapse
That´s a bug within AVB. Unfortunately it can happen on Pixel 6 and 7 devices.
There´s one thing that can clear it:
I know this sounds a bit counter intuitive, but download october factory image, extract init_boot.img, flash it via fastboot on your device with nov firmware.
fastboot flash init_boot init_boot.img
Try to let it boot, if it fails or crashes go back to bootloader via long press power and volume down. (can take up to 30 seconds on p7pro)
If it boots already don´t forgot to flash init_boot from november firmware still.
Then download november factory image, extract init_boot.img, flash it via fastboot as well. This might get you out of the loop.
If you want you can use a magisk_patched init_boot.img as well so you´re rooted.
That last step should get you out of the corruption loop, as flashing outdated init_boot and then correct init_boot will somehow clear avb.
I´ll attach patched init_boot.img from november firmware TD1A.221105.001, Nov 2022 for you.
I see. Thank you so much for this info. I will try and report back my results. Has this bug been fixed in newer versions of Magisk or Android? I feel like it's a high priority bug given that it soft-bricks peoples devices.
EDIT: And does this process result in data loss?
Freak07 said:
That´s a bug within AVB. Unfortunately it can happen on Pixel 6 and 7 devices.
There´s one thing that can clear it:
I know this sounds a bit counter intuitive, but download october factory image, extract init_boot.img, flash it via fastboot on your device with nov firmware.
fastboot flash init_boot init_boot.img
Try to let it boot, if it fails or crashes go back to bootloader via long press power and volume down. (can take up to 30 seconds on p7pro)
If it boots already don´t forgot to flash init_boot from november firmware still.
Then download november factory image, extract init_boot.img, flash it via fastboot as well. This might get you out of the loop.
If you want you can use a magisk_patched init_boot.img as well so you´re rooted.
That last step should get you out of the corruption loop, as flashing outdated init_boot and then correct init_boot will somehow clear avb.
I´ll attach patched init_boot.img from november firmware TD1A.221105.001, Nov 2022 for you.
Click to expand...
Click to collapse
Glad you're on our forum Freak!
Pritster5 said:
I see. Thank you so much for this info. I will try and report back my results. Has this bug been fixed in newer versions of Magisk or Android? I feel like it's a high priority bug given that it soft-bricks peoples devices.
EDIT: And does this process result in data loss?
Click to expand...
Click to collapse
Remove "-w" from the flashall.bat, I believe that ensures you keep data.
I'm also a bit confused by this step: "flash it via fastboot on your device with nov firmware." Are you saying that I should flash october init_boot.img onto my phone, which already has the Nov firmware installed? Or do I have to merge the Oct init_boot.img into the Nov firmware (full factory image TD1A.221105.001)
Pritster5 said:
I'm also a bit confused by this step: "flash it via fastboot on your device with nov firmware." Are you saying that I should flash october init_boot.img onto my phone, which already has the Nov firmware installed? Or do I have to merge the Oct init_boot.img into the Nov firmware (full factory image TD1A.221105.001)
Click to expand...
Click to collapse
yes, you flash the old outdated init_boot via fastboot on november firmware.
afterwards you flash back the correct one for november. that will hopefully clear the avb bug you´re experiencing.
You flash only this img, not anything else. do precisely the steps I described. you don´t have to flash the full firmware, as you already updated to november if I read your initial post correctly and OTA to november was successful.
Pritster5 said:
I see. Thank you so much for this info. I will try and report back my results. Has this bug been fixed in newer versions of Magisk or Android? I feel like it's a high priority bug given that it soft-bricks peoples devices.
EDIT: And does this process result in data loss?
Click to expand...
Click to collapse
no it has not been fixed.
no, with the steps detailed there´s no data loss.
I wouldn´t recommend updating your phone with the magisk flash to inactive slot method. That´s not working for most people on p6 and p7 devices.
Pain-N-Panic said:
Remove "-w" from the flashall.bat, I believe that ensures you keep data.
Click to expand...
Click to collapse
the method I described doesn´t involve using that script. no data will be lost.
I then went into the Magisk app and tapped "install to inactive slot (after OTA)" and rebooted from within the Magisk app.
Click to expand...
Click to collapse
How do you expect this to work for p7p? The Magisk code has not been updated yet to flash init_boot partition instead of boot partition on p7p. Of course, it will corrupt your boot partition.
Update Magisk using the method outlined in the main thread for OTA and Magisk: https://forum.xda-developers.com/t/...-safetynet-all-relevant-links.4502805/page-61
Freak07 said:
yes, you flash the old outdated init_boot via fastboot on november firmware.
afterwards you flash back the correct one for november. that will hopefully clear the avb bug you´re experiencing.
You flash only this img, not anything else. do precisely the steps I described. you don´t have to flash the full firmware, as you already updated to november if I read your initial post correctly and OTA to november was successful.
no it has not been fixed.
no, with the steps detailed there´s no data loss.
I wouldn´t recommend updating your phone with the magisk flash to inactive slot method. That´s not working for most people on p6 and p7 devices.
the method I described doesn´t involve using that script. no data will be lost.
Click to expand...
Click to collapse
devsk said:
How do you expect this to work for p7p? The Magisk code has not been updated yet to flash init_boot partition instead of boot partition on p7p. Of course, it will corrupt your boot partition.
Update Magisk using the method outlined in the main thread for OTA and Magisk: https://forum.xda-developers.com/t/...-safetynet-all-relevant-links.4502805/page-61
Click to expand...
Click to collapse
If what @devsk states is true, you also need to flash back stock boot.img from november firmware via fastboot @Pritster5.
fastboot flash boot boot.img
Since magisk can patch init_boot.img´s, I assumed it would account for pixel 7 pro, having ramdisk inside init_boot instead of boot.img. It´s a bad design choice by magisk app to show this option to users on Pixel 7 pro in that case. :/ but even on pixel 6, the forums are full of people running into issues with that method.
devsk said:
How do you expect this to work for p7p? The Magisk code has not been updated yet to flash init_boot partition instead of boot partition on p7p. Of course, it will corrupt your boot partition.
Update Magisk using the method outlined in the main thread for OTA and Magisk: https://forum.xda-developers.com/t/...-safetynet-all-relevant-links.4502805/page-61
Click to expand...
Click to collapse
Where can I see what devices are supported for that method? I assumed that the guide worked for anyone with A/B partitioning. It would be helpful if there was a notice of this somewhere on the guide or any other obvious place.
The easiest way to recover is to follow that guide and flash the whole ROM (it will fix both the boot and init_boot partitions). *Make sure* to remove -w from the flash-all.bat or flash-all.sh, whichever one you are using. This part is important. "-w" command line argument wipes your data and you don't want that.
I just updated my p7p using this method this afternoon and it worked fine.
Pritster5 said:
Where can I see what devices are supported for that method? I assumed that the guide worked for anyone with A/B partitioning. It would be helpful if there was a notice of this somewhere on the guide or any other obvious place.
Click to expand...
Click to collapse
That link is specifically for p7p
devsk said:
That link is specifically for p7p
Click to expand...
Click to collapse
Oh I meant where can I see what devices support the Magisk "Install to inactive slot" guide.
You said "The Magisk code has not been updated yet to flash init_boot partition instead of boot partition on p7p. Of course, it will corrupt your boot partition."
How are you aware of this? Did you find this out by reading the code itself or was there a notice of this somewhere?
Pritster5 said:
Oh I meant where can I see what devices support the Magisk "Install to inactive slot" guide.
You said "The Magisk code has not been updated yet to flash init_boot partition instead of boot partition on p7p. Of course, it will corrupt your boot partition."
How are you aware of this? Did you find this out by reading the code itself or was there a notice of this somewhere?
Click to expand...
Click to collapse
Actually, this got me thinking and I looked at the code. Looks like the magisk code (the bash function find_boot_image) seems to be doing the right thing by treating init_boot ahead of boot partition.
Do you have the logs from that run of "Install to inactive slot"?
devsk said:
Actually, this got me thinking and I looked at the code. Looks like the magisk code (the bash function find_boot_image) seems to be doing the right thing by treating init_boot ahead of boot partition.
Do you have the logs from that run of "Install to inactive slot"?
Click to expand...
Click to collapse
I don't believe so, as I can only connect to my phone via PC over fastboot mode right now, so I'll have to check for logs after fixing my device.
One other question though, the guide you linked mentioned disabling magisk modules before flashing the factory image. I was never able to do that because I used the inactive slot guide which made no mention of it. Will the enabled magisk modules prevent me from using the guide you linked?
I am also unable to do this step as I can't transfer files from my pc to my p7p when I cant access the phone aside from fastboot mode: "Copy the init_boot.img from the PC to the phone's internal storage." Can I skip this step?
EDIT: Should I just use the Android flash tool instead if I don't have access to ADB? Or should I instead just follow Freak07's steps since his steps don't require adb access?
Pritster5 said:
I don't believe so, as I can only connect to my phone via PC over fastboot mode right now, so I'll have to check for logs after fixing my device.
One other question though, the guide you linked mentioned disabling magisk modules before flashing the factory image. I was never able to do that because I used the inactive slot guide which made no mention of it. Will the enabled magisk modules prevent me from using the guide you linked?
I am also unable to do this step as I can't transfer files from my pc to my p7p when I cant access the phone aside from fastboot mode: "Copy the init_boot.img from the PC to the phone's internal storage." Can I skip this step?
Click to expand...
Click to collapse
Just restore your device by flashing the whole ROM. This will get rid of magisk and you should have no problem booting back into the system. You will have lost the root at that point. Once inside, transfer the init_boot.img into /sdcard and run magisk and ask it to patch that. Bring the patched file to your PC, and flash it to init_boot partition like the guide says. At that point, you should be able to boot back into the system and root should be good.
I did not disable Magisk modules and it worked fine. I have magiskhide props, shmiko, systemless hosts, zygisk - lsposed, universal safety net fix.
If you have trouble with Magisk modules, you can recover by booting into Safe Mode (restart and press down volume and keep it pressed). Magisk detects the Safe Mode and disables the modules. Done that many times.
Pritster5 said:
I don't believe so, as I can only connect to my phone via PC over fastboot mode right now, so I'll have to check for logs after fixing my device.
One other question though, the guide you linked mentioned disabling magisk modules before flashing the factory image. I was never able to do that because I used the inactive slot guide which made no mention of it. Will the enabled magisk modules prevent me from using the guide you linked?
I am also unable to do this step as I can't transfer files from my pc to my p7p when I cant access the phone aside from fastboot mode: "Copy the init_boot.img from the PC to the phone's internal storage." Can I skip this step?
EDIT: Should I just use the Android flash tool instead if I don't have access to ADB? Or should I instead just follow Freak07's steps since his steps don't require adb access?
Click to expand...
Click to collapse
in the end it doesn´t matter how you do it.
Flashing the complete firmware with -w removed or using the web flasher might be easier as it´s kind of a one click solution.
However simply flashing entire november firmware, might not get you out of the avb corruption loop. It might but, but it might not depending on what went wrong. If it´s the bug that I think it is, avb gets cleared when flashing an older outdated init_boot.img.
You can try to just flash the entire nov firmware with any of the methods suggested. If it doesn´t clear the avb corruption bug, flash back older init_boot from oct firmware, followed by current init boot as I originally suggested.
Freak07 said:
That´s a bug within AVB. Unfortunately it can happen on Pixel 6 and 7 devices.
There´s one thing that can clear it:
I know this sounds a bit counter intuitive, but download october factory image, extract init_boot.img, flash it via fastboot on your device with nov firmware.
fastboot flash init_boot init_boot.img
Try to let it boot, if it fails or crashes go back to bootloader via long press power and volume down. (can take up to 30 seconds on p7pro)
If it boots already don´t forgot to flash init_boot from november firmware still.
Then download november factory image, extract init_boot.img, flash it via fastboot as well. This might get you out of the loop.
If you want you can use a magisk_patched init_boot.img as well so you´re rooted.
That last step should get you out of the corruption loop, as flashing outdated init_boot and then correct init_boot will somehow clear avb.
I´ll attach patched init_boot.img from november firmware TD1A.221105.001, Nov 2022 for you.
Click to expand...
Click to collapse
Ok so I did this part:
"I know this sounds a bit counter intuitive, but download october factory image, extract init_boot.img, flash it via fastboot on your device with nov firmware.
fastboot flash init_boot init_boot.img
Try to let it boot, if it fails or crashes go back to bootloader via long press power and volume down. (can take up to 30 seconds on p7pro)
If it boots already don´t forgot to flash init_boot from november firmware still."
And it works, however when I go to "About Phone" the build number is still the October version. Is this expected, given that I flashed the october init_boot.img onto a phone with November firmware? Or did my phone perhaps reboot into the older partition which the phone ran before switching to the inactive slot?
EDIT: Even after flashing the november init_boot.img after temporarily reverting to the october init_boot.img, it's still showing that I have build TD1A.220804.031 installed.
"followed by current init boot as I originally suggested."
Should I reboot back into fastboot mode again to do this?
Thank you guys so much for the help so far btw, I'm already back up and running and just need to finish the steps you mentioned.
@devsk Here are the logs you wanted:
I don't wanna risk the on device ota via restoring images through magisk again
Does the following check out?
I'd greatly appreciate if someone, perhaps @V0latyle could look over it, you already helped me a lot the last time.
Download ota, as well as firmware and check if boot.img got updated (or perhaps someone on an updated phone can check but idk how to even check your boot version)
Either patch new boot.img or keep the old one at hand if it didn't get updated
Disable all magisk modules and reboot
Go to magisk -> uninstall -> restore images and reboot
Go in sideload mode and sideload the ota
Reboot to system so the ota can complete
Turn off and boot again from magisk patched boot.img
Direct install through magisk and enable modules
Reboot so modules work and done
All those reboots might not be necessary but I don't know if f.e. magisk modules immediately stop affecting the system after disabling them or if a reboot is required to fully disable them, same with unrooting, even after restoring images the current system has still root so I might need to reboot before sideloading.
I know that technically I don't need to unroot at all for sideloading to work but I really want to make this as safe as it can get.
G5-User7080 said:
I don't wanna risk the on device ota via restoring images through magisk again
Does the following check out?
I'd greatly appreciate if someone, perhaps @V0latyle could look over it, you already helped me a lot the last time.
Download ota, as well as firmware and check if boot.img got updated (or perhaps someone on an updated phone can check but idk how to even check your boot version)
Either patch new boot.img or keep the old one at hand if it didn't get updated
Disable all magisk modules and reboot
Go to magisk -> uninstall -> restore images and reboot
Go in sideload mode and sideload the ota
Reboot to system so the ota can complete
Turn off and boot again from magisk patched boot.img
Direct install through magisk and enable modules
Reboot so modules work and done
All those reboots might not be necessary but I don't know if f.e. magisk modules immediately stop affecting the system after disabling them or if a reboot is required to fully disable them, same with unrooting, even after restoring images the current system has still root so I might need to reboot before sideloading.
I know that technically I don't need to unroot at all for sideloading to work but I really want to make this as safe as it can get.
Click to expand...
Click to collapse
No need to unroot or restore images. You can disable modules if you want. Just sideload the OTA, and live boot the old patched image, then perform Direct Install in Magisk.
By the way, instead of creating a new thread, you could have asked this question in an existing one...
V0latyle said:
By the way, instead of creating a new thread, you could have asked this question in an existing one...
Click to expand...
Click to collapse
Perhaps I could have, I am hoping that this way it might be easier to find for others than having to look somewhere on the 30th post of a thread that is about a bricked device after ota.
V0latyle said:
No need to unroot or restore images. You can disable modules if you want. Just sideload the OTA, and live boot the old patched image, then perform Direct Install in Magisk.
Click to expand...
Click to collapse
mhh I see, I'm just a little scared of the ota process after what happened the last time so I wanna be like extra sure nothing can go wrong.
Doesn't help that I don't really understand what OTA's do exactly..
That I don't have to unroot when flashing factory makes sense as I'm just overwriting boot anyway.
Is an OTA the same thing essentially? Like is it basically a bunch or partitions in a zip that get flashed over whatever is there previously?
Meaning all things that could go wrong or get checked happen through the system update app rather than through the OTA itself?
Also you are saying "unroot or restore images", is that not the same thing?
And let's say boot gets updated and I live boot the older outdated image, does that not matter at all?
why do you wanna take the OTA route if you already downloaded the complete firmware package anyway? i’ll do a firmware flash (instead of OTA) without wiping each month and that’s it, i’ll even patch boot.img before flashing (and flash it directly together with the rest of the new firmware). works just fine.
frank93 said:
why do you wanna take the OTA route if you already downloaded the complete firmware package anyway? i’ll do a firmware flash (instead of OTA) without wiping each month and that’s it, i’ll even patch boot.img before flashing (and flash it directly together with the rest of the new firmware). works just fine.
Click to expand...
Click to collapse
This sounds like the "Quick Method" mentioned here:
https://www.xda-developers.com/how-to-install-ota-updates-keep-root-google-pixel-phone/
You're doing that?
frank93 said:
why do you wanna take the OTA route if you already downloaded the complete firmware package anyway? i’ll do a firmware flash (instead of OTA) without wiping each month and that’s it, i’ll even patch boot.img before flashing (and flash it directly together with the rest of the new firmware). works just fine.
Click to expand...
Click to collapse
As far as I understood sideloading OTA is the most safe and uncomplicated way
media-fort said:
This sounds like the "Quick Method" mentioned here:
https://www.xda-developers.com/how-to-install-ota-updates-keep-root-google-pixel-phone/
You're doing that?
Click to expand...
Click to collapse
yes, sounds like that’s "my way" of doing it. originally got this from a magisk-issue-comment here, basically it’s a "complete firmware flash with an already patched boot.img, no wipe", and that’s it. never done an OTA/sideload for years tbh.
G5-User7080 said:
Perhaps I could have, I am hoping that this way it might be easier to find for others than having to look somewhere on the 30th post of a thread that is about a bricked device after ota.
Click to expand...
Click to collapse
Well, I had thought there were existing guides in this section, but either I was mistaken or they've been buried.
G5-User7080 said:
mhh I see, I'm just a little scared of the ota process after what happened the last time so I wanna be like extra sure nothing can go wrong.
Doesn't help that I don't really understand what OTA's do exactly..
Click to expand...
Click to collapse
Maybe explaining it could help you. I'll do so in response to your questions below.
G5-User7080 said:
That I don't have to unroot when flashing factory makes sense as I'm just overwriting boot anyway.
Click to expand...
Click to collapse
Exactly.
G5-User7080 said:
Is an OTA the same thing essentially? Like is it basically a bunch or partitions in a zip that get flashed over whatever is there previously?
Click to expand...
Click to collapse
Regardless of whether installed through system update or via sideload, the OTA package always installs to the other slot - if you're currently running on slot A, it installs to slot B, and vice versa. See A/B (Seamless) System Updates
G5-User7080 said:
Meaning all things that could go wrong or get checked happen through the system update app rather than through the OTA itself?
Click to expand...
Click to collapse
OTA through system update doesn't always seem to work for rooted users; some have suggested that it may be necessary to restore images in Magisk to pass verification checks in order for the update to succeed. Others, like me, don't bother with the OTA updates anymore because 1) OTA through system updates just don't seem to work and 2) Magisk patching inactive slot still seems to have issues. I personally prefer to use the factory images, but the OTA method is technically safer.
OTA sideload should always work, and AFAIK it doesn't matter what state your device is in. It overwrites whatever is on the currently inactive slot; there's no need to remove modules or restore images or unroot as the boot image gets overwritten with the new boot image.
G5-User7080 said:
Also you are saying "unroot or restore images", is that not the same thing?
Click to expand...
Click to collapse
No, they aren't.
When your device boots, it loads the contents of the /boot partition into memory - ramdisk and kernel. This remains in memory while the system is running.
Hence, if the boot image has been patched, you'll boot with root.
When you perform "Restore Images" in Magisk, this uses root access to restore the unpatched image to /boot. But, since the patched boot image was already loaded into RAM, you still have root.
If you reboot at this point, you'll lose root because the now unpatched boot image is loaded into memory.
G5-User7080 said:
And let's say boot gets updated and I live boot the older outdated image, does that not matter at all?
Click to expand...
Click to collapse
Yes and no.
After an OTA update, you want to let the system boot with the new boot image. This is because the boot image has a signature that matches the system image; if these don't match, the update engine determines that the update was a failure, and will recycle you back to the original slot. So, the boot image that the system loads after the update has to be the new one. It doesn't matter if it's been patched or not - you could, for example, download the factory image, extract the boot image from it, patch the boot image in Magisk, then sideload the OTA, force your phone to boot into bootloader, and flash the new patched image.
Patching to inactive slot in Magisk is supposed to avoid all this, and can only be used if you update through system. It works like this:
You're rooted on the February release on slot A.
You restore images in Magisk, but do not reboot.
You install the OTA through system updates. This installs to slot B
When it prompts you to reboot to finish the update, instead you go back to Magisk and use Patch Inactive Slot - this uses root access to perform the Magisk patch on the new boot image in /boot_b
You then reboot, and the system switches to slot B, and loads with root because you patched the boot image.
However, this doesn't seem to be working for everyone. Some phones don't even "see" the OTA update is available for some reason.
Therefore, this is the method I recommend you use to install the OTA update:
Download the OTA update for your device from Pixel OTA Images
In Magisk, go to Reboot > Reboot to recovery
Once in recovery mode, hold Power and click Volume Up. Then, select "Apply update from ADB" and connect your phone to your computer.
On your PC, open a command line in your ADB Platform Tools folder, and type adb sideload <path to OTA zip> - to make this easier, just drag and drop the OTA zip into the command window.
Once the update completes, let your phone boot to system. You will not have root, so it won't matter if you didn't disable Magisk modules.
Let the system complete the post-update work (there's a notification with a gear icon) and get stabilized. Wait a few minutes.
Assuming you still have USB debugging enabled, use ADB to reboot to bootloader: adb reboot bootloader or you can just do it manually - reboot your device and hold Volume Down
You can now live boot an older patched boot image: fastboot boot <drag and drop patched boot image>
You should boot with root. Note: if your phone bootloops, see my note below)
In Magisk, go to Install > Direct Install. This uses the "temporary root" of the patched image you've loaded into memory to patch the new boot image
Reboot once more. You should now be on the new boot image with root.
If your phone boot loops, double check to make sure you're still on the latest update. You can check this in Settings > About, but it's also displayed on the notification windowshade under the Quick Settings tiles. Make sure this matches the OTA image you just installed. If it doesn't, this means that your device has recycled back to the "old" slot for some reason, and you'll have to start over.
If you want to play it safe, you can use this guide to extract the new boot.img from the OTA payload. You'd then patch this manually in Magisk, and after installing the update, you'd reboot to bootloader and flash to /boot.
If you still bootloop on the new boot image after patching, you probably need to disable Magisk modules. You can do this via command line:
adb --wait-for-device shell magisk -remove-images
frank93 said:
yes, sounds like that’s "my way" of doing it. originally got this from a magisk-issue-comment here, basically it’s a "complete firmware flash with an already patched boot.img, no wipe", and that’s it. never done an OTA/sideload for years tbh.
Click to expand...
Click to collapse
Damn, I tried this and it seems that my PC cannot write the image to the Pixel 6a?!
Do I have old ADB drivers or whats the reason for that?
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Edit:
Sry, I'm not involved here all the time. Figured it out myself. Reason for the failure were the freakin' platform_tools_r34. Switched to r33 and worked straight away..
https://forum.xda-developers.com/t/...el-7-pro-support-thread.4505287/post-88134573
V0latyle said:
Well, I had thought there were existing guides in this section, but either I was mistaken or they've been buried.
Click to expand...
Click to collapse
Not in the 6a forum as far as I'm aware, there might be more in the Pixel 6 forum, but I've already seen your guide that covers all kinds of methods.
V0latyle said:
the OTA package always installs to the other slot
Click to expand...
Click to collapse
Wouldn't it make sense to restore the unrooted boot partition on the currently active slot given that OTA will switch me to the currently inactive slot?
So that after the OTA procedure I'm in the same situation as now, being on a rooted slot with having the original unrooted slot as sort of "backup".
V0latyle said:
there's no need to remove modules or restore images or unroot as the boot image gets overwritten with the new boot image.
Click to expand...
Click to collapse
I think it was on the magisk ota guide but im not sure, that it said that it's important to disable all system modifying modules before attempting an update.
While all modules I use should by systemless,.. I think?.. I still think it's just easier to disable them all and re-enable them later, just to avoid trouble and make it easier to write in a guide, as in "just disable them and don't bother checking if theyre really all systemless".
V0latyle said:
After an OTA update, you want to let the system boot with the new boot image.
Click to expand...
Click to collapse
Yes, that was my intention, let it boot normally without touching anything to complete the OTA.
Didn't know I would have to wait a few minutes after already being in the system tho to wait for the notification, I'll look out for that.
V0latyle said:
In Magisk, go to Reboot > Reboot to recovery
Once in recovery mode, hold Power and click Volume Up. Then, select "Apply update from ADB" and connect your phone to your computer.
Click to expand...
Click to collapse
Is this equivalent to the way you described in your Pixel 6 guide?
As in doing adb reboot sideload to go to sideload mode, followed by adb sideload ota.zip
V0latyle said:
If your phone boot loops, double check to make sure you're still on the latest update.
Click to expand...
Click to collapse
If it bootloops how would I even get back into system?
Why would it even bootloop, if there is a known cause can't I just avoid whatever is causing it to begin with?
I mean I don't assume I'll bootloop following the steps carefully but this time I'll post and wait for replies before just nuking everything like last time ^^
V0latyle said:
If you want to play it safe, you can use this guide to extract the new boot.img from the OTA payload.
Click to expand...
Click to collapse
Yes, I'd prefer to make it as safe as possible.
Is the boot.img extracted from the OTA the same as the one from the according firmware?
Would be easier to just extract that on PC.
Oh and two more question that came to mind.
When restoring images through magisk it replaces the rooted boot partition with the stock one.
But root only disappears on next reboot.
So can I restore images and then directly do adb reboot sideload followed by doing the OTA?
Meaning I don't need to do one reboot back to system to sort of "complete the unrooting preocedure"?
Is that the same for magisk modules?
If I want to disable them just in case, do I need to reboot once after for them to like get removed from the system or are they instantly disabled the moment I press the "disable module" switch?
G5-User7080 said:
Not in the 6a forum as far as I'm aware, there might be more in the Pixel 6 forum, but I've already seen your guide that covers all kinds of methods.
Wouldn't it make sense to restore the unrooted boot partition on the currently active slot given that OTA will switch me to the currently inactive slot?
So that after the OTA procedure I'm in the same situation as now, being on a rooted slot with having the original unrooted slot as sort of "backup".
Click to expand...
Click to collapse
Not if you're going to sideload the OTA. There's no point to doing so.
G5-User7080 said:
I think it was on the magisk ota guide but im not sure, that it said that it's important to disable all system modifying modules before attempting an update.
While all modules I use should by systemless,.. I think?.. I still think it's just easier to disable them all and re-enable them later, just to avoid trouble and make it easier to write in a guide, as in "just disable them and don't bother checking if theyre really all systemless".
Click to expand...
Click to collapse
Yeah, this is the "safe" option. I just use MHPC + USNF mod + systemless hosts so I don't bother disabling, but those who use Xposed or other more "invasive" system mods might want to.
G5-User7080 said:
Yes, that was my intention, let it boot normally without touching anything to complete the OTA.
Didn't know I would have to wait a few minutes after already being in the system tho to wait for the notification, I'll look out for that.
Click to expand...
Click to collapse
This is because it seems to take a few minutes for the system to "get happy" and decide that all is well, and if you live boot an older boot image before it does so, it will assume the update failed and recycle back to the old slot.
G5-User7080 said:
Is this equivalent to the way you described in your Pixel 6 guide?
As in doing adb reboot sideload to go to sideload mode, followed by adb sideload ota.zip
Click to expand...
Click to collapse
Yep. The commands and the method is exactly the same for all Pixel devices. The only thing that is different are the files. Only the Pixel 7 / 7 Pro are slightly different in that we have to patch init_boot instead of boot.
G5-User7080 said:
If it bootloops how would I even get back into system?
Click to expand...
Click to collapse
Use the command I gave you: adb --wait-for-device shell magisk --remove-modules while booting
G5-User7080 said:
Why would it even bootloop, if there is a known cause can't I just avoid whatever is causing it to begin with?
Click to expand...
Click to collapse
There isn't a known cause, the exception being trying to boot an old boot image without letting the system complete the update post-reboot as described above
G5-User7080 said:
I mean I don't assume I'll bootloop following the steps carefully but this time I'll post and wait for replies before just nuking everything like last time ^^
Yes, I'd prefer to make it as safe as possible.
Is the boot.img extracted from the OTA the same as the one from the according firmware?
Would be easier to just extract that on PC.
Click to expand...
Click to collapse
Yes. It's just packaged differently.
Since Payload Dumper requires Python, I've found it simpler to just use the factory image - although if you're at that point, you may as well just flash the factory image anyway.
G5-User7080 said:
Oh and two more question that came to mind.
When restoring images through magisk it replaces the rooted boot partition with the stock one.
But root only disappears on next reboot.
So can I restore images and then directly do adb reboot sideload followed by doing the OTA?
Meaning I don't need to do one reboot back to system to sort of "complete the unrooting preocedure"?
Click to expand...
Click to collapse
I never suggested you'd need to reboot after restoring images. Once you've restored the original boot image, that's what is in the boot partition. It takes effect immediately. What doesn't take immediate effect is what's currently running in memory, which is why I pointed out that upon a reboot, your device will load the unpatched image because that's what's in the partition. But, as I explained above, there's no point to restoring the original boot image if you're sideloading the OTA. The only time this ever appears to be necessary is when you're taking OTA through system update.
G5-User7080 said:
Is that the same for magisk modules?
If I want to disable them just in case, do I need to reboot once after for them to like get removed from the system or are they instantly disabled the moment I press the "disable module" switch?
Click to expand...
Click to collapse
I am honestly not sure about this one, but since we are talking about OTAs, the point is moot - when the update completes and the phone reboots, it's booting an unpatched boot image, meaning there's no way for the modules to load. It doesn't matter if you've made changes to system, either, because the system partition also has two slots - system_a and system_b
The only thing that MIGHT matter is when you boot the patched image, because if you haven't disabled modules, they will load during boot, and if one of them causes a bootloop for whatever reason....It still shouldn't matter because in this case, the device -should- try to boot the same slot again, and since you never patched the new boot image, it will boot without root.
V0latyle said:
I am honestly not sure about this one, but since we are talking about OTAs, the point is moot - when the update completes and the phone reboots, it's booting an unpatched boot image, meaning there's no way for the modules to load. It doesn't matter if you've made changes to system, either, because the system partition also has two slots - system_a and system_b
Click to expand...
Click to collapse
yea it seems like its the same as restoring images, it disables them but obviously they are already loaded for the current session and probably don't get "unloaded", they just won't load again from the next boot on, so I don't think there would be any need to reboot, except when you want to do something in system that requires modules to be disabled.
So it seems like we'll have to wait til like the 20th for the march update, so I'll just go straight for the april one.
Considering what you said, would this be the correct procedure, just to confirm?
Extract boot.img from factory image and patch it, then move it to pc.
In Magisk app, disable all modules.
On pc do adb reboot sideload and after rebooting in download mode adb sideload ota.zip
Choose "reboot system" from menu or use adb reboot... does that command work in download mode?
Let it reboot, unlock, wait for the update completed notification to appear.
Confirm that adb debugging is still enabled and the version number below quick tiles matches the update, then do adb reboot bootloader.
Live boot the new magisk patched boot.img with fastboot boot patched_boot.img.
Magisk app -> Install -> Direct Install, then re-enable all modules and reboot.
done
Additionally, I'm wondering what all the different "menus" are for.
Like first there is bootloader where you can flash partitions through the fastboot command and enter recovery or boot system.
Then there is the recovery that... doesn't really do anything when it's stock?
Then there is sideload or download mode that is accessed from the recovery.
Then there is adb fastboot, does that bring you to the fastbootd screen? I have no idea what that is for.
G5-User7080 said:
yea it seems like its the same as restoring images, it disables them but obviously they are already loaded for the current session and probably don't get "unloaded", they just won't load again from the next boot on, so I don't think there would be any need to reboot, except when you want to do something in system that requires modules to be disabled.
So it seems like we'll have to wait til like the 20th for the march update, so I'll just go straight for the april one.
Considering what you said, would this be the correct procedure, just to confirm?
Extract boot.img from factory image and patch it, then move it to pc.
In Magisk app, disable all modules.
On pc do adb reboot sideload and after rebooting in download mode adb sideload ota.zip
Choose "reboot system" from menu or use adb reboot... does that command work in download mode?
Click to expand...
Click to collapse
ADB commands work in recovery mode, yes.
G5-User7080 said:
Let it reboot, unlock, wait for the update completed notification to appear.
Confirm that adb debugging is still enabled and the version number below quick tiles matches the update, then do adb reboot bootloader.
Live boot the new magisk patched boot.img with fastboot boot patched_boot.img.
Magisk app -> Install -> Direct Install, then re-enable all modules and reboot.
done
Click to expand...
Click to collapse
If you're going to download the factory image, why not just use Pixel Flasher to perform a factory flash? Contrary to popular belief, flashing the factory image itself does not wipe data. OTA updates are still the "safest" way but I've been using the factory image for a couple years now on my Pixel 5 and have never had a problem.
G5-User7080 said:
Additionally, I'm wondering what all the different "menus" are for.
Like first there is bootloader where you can flash partitions through the fastboot command and enter recovery or boot system.
Then there is the recovery that... doesn't really do anything when it's stock?
Then there is sideload or download mode that is accessed from the recovery.
Then there is adb fastboot, does that bring you to the fastbootd screen? I have no idea what that is for.
Click to expand...
Click to collapse
Bootloader is used for flashing bootloader, modem, and boot.
Recovery mode is a small kernel in of itself that can perform functions that the bootloader can't, and provides a software interface to perform a "safe" recovery should the device stop working - like flashing an OTA.
Sideload mode is part of that recovery software interface - it allows you to serve OTA files over ADB
Fastbootd is "userspace fastboot" that allows advanced flashing functions.
More information on fastbootd
V0latyle said:
If you're going to download the factory image, why not just use Pixel Flasher to perform a factory flash? Contrary to popular belief, flashing the factory image itself does not wipe data. OTA updates are still the "safest" way but I've been using the factory image for a couple years now on my Pixel 5 and have never had a problem.
Click to expand...
Click to collapse
cause I'd need to remove the -w from the update command in the flashall.bat as well as possibly add --skip-reboot
I can see the day coming when I simply forget doing that and wipe my device by accident.
Or when using pixel flasher I might just forget to untick the wipe option.
I want to use a method that ideally I only have to prepare once, say if I could just make a "flash factory without wipe" script that works every time, but due to changing version numbers I have to use the new script every time.
G5-User7080 said:
cause I'd need to remove the -w from the update command in the flashall.bat as well as possibly add --skip-reboot
Click to expand...
Click to collapse
You don't have to use the script. Learn to do the commands manually. You don't have to skip reboot either, but if you want to flash a patched boot image, it helps.
G5-User7080 said:
I can see the day coming when I simply forget doing that and wipe my device by accident.
Or when using pixel flasher I might just forget to untick the wipe option.
Click to expand...
Click to collapse
Pixel Flasher settings are persistent....
G5-User7080 said:
I want to use a method that ideally I only have to prepare once, say if I could just make a "flash factory without wipe" script that works every time, but due to changing version numbers I have to use the new script every time.
Click to expand...
Click to collapse
You seem to misunderstand how flashing the factory image works. You don't have to use the script. Learn to use ADB and fastboot commands manually. You can follow my guide for the 6 Pro here; the commands are all the same.
Otherwise, you can use Pixel Flasher. All you have to do is set it up once, and the settings persist even after updates. This is what I've gone to as a means to simply free myself for other tasks while my phone is updating; I used to do it manually.
frank93 said:
yes, sounds like that’s "my way" of doing it. originally got this from a magisk-issue-comment here, basically it’s a "complete firmware flash with an already patched boot.img, no wipe", and that’s it. never done an OTA/sideload for years tbh.
Click to expand...
Click to collapse
If you flash a full factory image via fastboot (without wiping the device in that process), is it safe and possible to leave your login information for screen unlock (password, fingerprint) installed before flashing?
And can I stay logged into my Google Account on the device before flashing as well?
I don't want to brick my device, therefore I've always deleted these Login infos before full flashing process.
But after each full flash, it's always very annoying to add all that info again, for each banking app, for Google pay and so on....
media-fort said:
If you flash a full factory image via fastboot (without wiping the device in that process), is it safe and possible to leave your login information for screen unlock (password, fingerprint) installed before flashing?
And can I stay logged into my Google Account on the device before flashing as well?
Click to expand...
Click to collapse
i never logged out or deleted anything before flashing. it "feels" like an OTA, i just flash (without wipe) and after the next boot the device is ready to be used.
media-fort said:
If you flash a full factory image via fastboot (without wiping the device in that process), is it safe and possible to leave your login information for screen unlock (password, fingerprint) installed before flashing?
And can I stay logged into my Google Account on the device before flashing as well?
Click to expand...
Click to collapse
Flashing a full firmware w/o wiping = OTA update. Since an OTA won't delete anything of your settings/data, a full firmware flash w/o wiping will do the same.
All settings, data and apps are stored on /userdata. When saying "without wiping", then it means "do not erase /userdata".
WoKoschekk said:
Flashing a full firmware w/o wiping = OTA update. Since an OTA won't delete anything of your settings/data, a full firmware flash w/o wiping will do the same.
All settings, data and apps are stored on /userdata. When saying "without wiping", then it means "do not erase /userdata".
Click to expand...
Click to collapse
Almost, but not quite.
Flashing the full factory firmware installs it to the currently active slot and can be done regardless of what version you're already on; if you try to flash the system update alone, it'll complain if it doesn't see the right bootloader and radio version but you can use --force to get around that
Flashing the OTA installs it to the currently INACTIVE slot and can only be done when you're on an OLDER version.
V0latyle said:
Almost, but not quite.
Flashing the full factory firmware installs it to the currently active slot and can be done regardless of what version you're already on; if you try to flash the system update alone, it'll complain if it doesn't see the right bootloader and radio version but you can use --force to get around that
Flashing the OTA installs it to the currently INACTIVE slot and can only be done when you're on an OLDER version.
Click to expand...
Click to collapse
yes, that's right. but regarding to the question
media-fort said:
is it safe and possible to leave your login information for screen unlock (password, fingerprint) installed before flashing?
Click to expand...
Click to collapse
it doesn't matter which slot is active.