[CLOSED]Rooting Android 12 on SD765G and Tensor Pixels

[V0latyle]

Update 12/15/21: Magisk Canary 23016 includes a fix for the vbmeta header that addresses this issue. Requesting mods close this thread.

Spoiler: Information about the issue, if you care to read it

***This is not a guide, please refer to your device forum for root instructions! Do not ask support questions here!***

Users of the Pixel 4a 5g, 5, 5a, and 6 series have all discovered a similar issue: Permanent root on Android 12 seems to require a data wipe.

Some points of note:

Previously, on Android 11 and prior, root was simple. Patch the boot image with Magisk, then flash it. No other steps were required.

However, when the Android 12 Beta launched, users of the Pixel 4a 5g, 5, and 5a discovered that Magisk patched boot images caused a "failure to load/verify boot images" message in bootloader.
This was successfully avoided on 12 Beta by disabling DM-verity and vbmeta verification, accomplished by flashing /vbmeta with these flags:

fastboot flash vbmeta --disable-verity --disable-verification vbmeta.img

With the 12 Stable release, we have found a new issue:
If verity and verification are disabled on an existing system, the device will boot into Rescue Party, with the message "Can't load Android system. Your data may be corrupt". At this point, the user must either reflash both /boot and /vbmeta to stock, or perform a factory reset. A patched boot image can be live booted as long as both partitions are stock; this can be used for temporary root.

Alternatively, a clean install performed with the factory image, either via Android Flash Tool, or via ADB using the following command:

fastboot update -w --disable-verity --disable-verification update codename-image.zip

will also allow successful boot of a patched boot image.

If /vbmeta is reflashed without disable flags at any point, and the device is allowed to boot, disabling it again will cause the device to boot into Rescue Party.

So, it would seem users of Android 12 on the Snapdragon 765G and Tensor devices have a choice after upgrading to Android 12:

• Retain data and either go without root, or use temporary root
• Wipe data for permanent root

Both the verified boot issue as well as the data wipe issue affect the Pixel 6 /P6 Pro as well.

As mentioned above, a patched boot image can be live booted for temporary root even if verity/verification are not disabled and /boot is stock.

Reference threads:
Verified Boot information
Update + Magisk thread
OTA sideload thread
Upgrade results and discussion thread
Pixel 6 Pro root thread

 

[V0latyle]

Device side actually.
Combination of hardware firmware and software.

Android 11 introduced boot header v3.
This is the start of GKI (Generic Kernel Image) support and the introduction of the vendor boot image.

The device (vendor) specific info is moved into the vendor_boot.img instead of the main boot.img.

On boot everything is combined to hopefully boot the device.

Android 12 introduces boot header v4.
This is the same as v3 with the addition of support for multiple ramdisks in the vendor boot image.
Again everything is combined on boot.

Since the 4a (5G), 5 and 5a were released with Android 11, they will use header v3 unless Google takes the time to update the build tree, kernel tree and blobs for each device to support v4.
So next year when Android 13 comes out, they will most likely still be using boot header v3.

The 6 and 6 Prop are released with Android 12 so, they will use header v4.
Again unless Google takes the time to update the trees and blobs to support a new boot header version.

One of the security updates in Android 12 (SDK31) causes the boot failure when a different boot image is installed without a data wipe.
I thought I read something about it but, I can not find where I read it.
Something about a change to the way the hash value is verified on devices using boot header v3 and newer.


Sad to say it is not a Magisk issue even though it affects Magisk.

Just unpacking and repacking the original boot image (no modification) will give the corruption error and force a data wipe if you install the repacked boot image.

Cheers.

@ipdev does this mean that we may potentially have to wipe /data every single time vbmeta is flashed, unless we follow the OTA sideload method? As far as that goes, why does it only seem to succeed after the OTA is sideloaded?

For the monthly updates, you've to flash the OTA packages via recovery and boot into fastboot immediately to keep vbmeta disabled. Secure boot will then remain turned off, allowing a patched boot image to be booted/flashed.

I've tested this between the betas and stable version. My last test was from Beta 5 to stable where I flashed the OTA via recovery, rebooted to bootloader, ran the fastboot command, and rebooted device. As a result, no data was lost as a wipe wasn't required.

I mean this is better than not having a workaround.

 

[pndwal]

Ref to the GitHub issue for those wanting to keep an eye on progress (of Magisk colaborators):
https://github.com/topjohnwu/Magisk/issues/4343

PW

 

[mkhcb]

Ref to the GitHub issue for those wanting to keep an eye on progress (of Magisk colaborators):
https://github.com/topjohnwu/Magisk/issues/4343

PW

It is a locked thread. Not much more to come from it that we don't already know.

 

[pndwal]

It is a locked thread. Not much more to come from it that we don't already know.

... That's why I said 'progress of Magisk colaborators'... Others will just have to post here! PW

 

[ipdev]

@ipdev does this mean that we may potentially have to wipe /data every single time vbmeta is flashed, unless we follow the OTA sideload method? As far as that goes, why does it only seem to succeed after the OTA is sideloaded?

I mean this is better than not having a workaround.

I have been waiting for the November update to test updating Android 12.
We will find out in a few days when it is released.

Currently I think we have a good chance to update from the Android 12 October build to the November build without having to wipe data.
As long as you disabled verity, verification and wiped data when initially updating to (or clean flash) Android 12.

I have mentioned before (in a different thread), I update using the full factory image and modify the flash-all script.

This is what I plan to try.

fastboot --disable-verity --disable-verification --skip-secondary --skip-reboot update image-redfin-NameOfUpdate.zip
fastboot reboot bootloader

The skip-reboot option will leave the device in fastboot_d so I add a reboot to bootloader.
If nothing else needs to be flashed after the update, I just fastboot reboot.

Long (still continuing) story short.

Once Android 12 is installed, verity and verification are disabled and data is wiped.

You can flash the boot partition as much as you want on Android 12.​

​

You can dirty-flash Android 12 again using the above fastboot command without having to wipe data again.​

The --skip-secondary is not needed, I just included it to speed up the flash a bit. ​

I still do not know what the trigger is for the corruption error.

---

As I mentioned in the post you quoted.

The corruption issue has to do with verifying the boot partition on Android 12.
Unless data is wiped after disabling verity and verification.

Since Magisk lives in boot, it unpacks, modifies, repacks and flashes the modified boot image to the boot partition.

It is not Magisk itself that triggers the corruption error, it is simply just a different boot image installed.

The same happens with a repacked (non modified) version of the stock boot image.

I used AIK to unpack and repack the stock boot image with no modification.​

Cheers.

PS.
@osm0sis
I know you are aware of this issue with Magisk but, it also affects AIK and probably AK3.
Basically anything that modifies the installed boot partition.

[ip@lost AIK-Linux]$ ./unpackimg.sh redfin-sp1a.210812.015-boot.img 
 
Android Image Kitchen - UnpackImg Script
by osm0sis @ xda-developers
 
Supplied image: redfin-sp1a.210812.015-boot.img
 
Setting up work folders...
 
Image type: AOSP
 
Signature with "AVBv2" type detected.
 
Splitting image to "split_img/"...
ANDROID! magic found at: 0
BOARD_KERNEL_CMDLINE 
BOARD_PAGE_SIZE 4096
BOARD_OS_VERSION 12.0.0
BOARD_OS_PATCH_LEVEL 2021-10
BOARD_HEADER_VERSION 3
BOARD_HEADER_SIZE 1580
 
Unpacking ramdisk (as root) to "ramdisk/"...
 
Compression used: lz4-l
4937 blocks
 
Done!
[ip@lost AIK-Linux]$ ./repackimg.sh --original --origsize
 
Android Image Kitchen - RepackImg Script
by osm0sis @ xda-developers
 
Repacking with original ramdisk...
 
Getting build information...
kernel = redfin-sp1a.210812.015-boot.img-kernel
ramdisk = redfin-sp1a.210812.015-boot.img-ramdisk.cpio.lz4
cmdline = 
os_version = 12.0.0
os_patch_level = 2021-10
header_version = 3
 
Building image...
 
Using format: AOSP
 
Padding to original size...
 
Done!

Also the modified boot image can not boot into fastboot_d while failing verification.
We are droped back to bootloader or recovery's Rescue Party when verification fails.
As noted above, the only way to disable verity and verification includes wiping data.

PPS.
Quick note for those trying to following along.
fastboot_d is part of the boot image (not the bootloader) and is the boot mode used to flash critical partitions.

The successor to fastboot flashing unlock_critical​

 

[osm0sis]

AIK not yet supporting hdr_v4 aside, it also can't AVBv2 sign anything (yet...), so thar also be dragons trying to flash anything unsigned on a device that wants all partitions signed.

 

[V0latyle]

@ipdev the problem is, as I stated, verity and verification are only disabled when vbmeta is flashed using those command line

I have been waiting for the November update to test updating Android 12.
We will find out in a few days when it is released.

Currently I think we have a good chance to update from the Android 12 October build to the November build without having to wipe data.
As long as you disabled verity, verification and wiped data when initially updating to (or clean flash) Android 12.

It doesn't seem to matter what you did initially, though. Case in point: I'm currently running permanent root on the 210812.015 build; I did a factory clean install on Saturday. If I flash vbmeta again, whether via the update or manually, it will require me to wipe data.

I have mentioned before (in a different thread), I update using the full factory image and modify the flash-all script.

This is what I plan to try.

fastboot --disable-verity --disable-verification --skip-secondary --skip-reboot update image-redfin-NameOfUpdate.zip
fastboot reboot bootloader

The skip-reboot option will leave the device in fastboot_d so I add a reboot to bootloader.
If nothing else needs to be flashed after the update, I just fastboot reboot.

It sounds like this is similar to sideloading the OTA, then entering fastboot and flashing /vbmeta and /boot manually. It's worked before of course but we aren't really worried about the update not working...

Long (still continuing) story short.

Once Android 12 is installed, verity and verification are disabled and data is wiped.

You can flash the boot partition as much as you want on Android 12.​

​

You can dirty-flash Android 12 again using the above fastboot command without having to wipe data again.​

The --skip-secondary is not needed, I just included it to speed up the flash a bit. ​

I still do not know what the trigger is for the corruption error.

Unfortunately, I can state for a fact that this isn't true. If you dirty flash the factory image with the --disable flags, you will get put into Rescue Party. As I stated previously, disabling dm-verity and vbmeta verification must be done every time vbmeta is flashed - it is not permanent. But the particularly nasty thing here is that if you flash vbmeta again, even with the disable flags, you will still get thrown into Rescue Party. It's not flashing /boot that requires the data wipe; it's /vbmeta. If you disable verity and verification but leave the boot image stock, you still wind up in Rescue Party.

The corruption issue has to do with verifying the boot partition on Android 12.
Unless data is wiped after disabling verity and verification.

Since Magisk lives in boot, it unpacks, modifies, repacks and flashes the modified boot image to the boot partition.

It is not Magisk itself that triggers the corruption error, it is simply just a different boot image installed.

The same happens with a repacked (non modified) version of the stock boot image.

I used AIK to unpack and repack the stock boot image with no modification.​

I still don't quite understand why this suddenly became an issue. Unlocking the bootloader was supposed to disable Android Verified Boot. It shouldn't be necessary for us to do anything else; flashing vbmeta is a relatively minor inconvenience compared to having to wipe and set up again every time you update.

Also the modified boot image can not boot into fastboot_d while failing verification.
We are dropped back to bootloader or recovery's Rescue Party when verification fails.
As noted above, the only way to disable verity and verification includes wiping data.

PPS.
Quick note for those trying to following along.
fastboot_d is part of the boot image (not the bootloader) and is the boot mode used to flash critical partitions.

The successor to fastboot flashing unlock_critical​

Yeah, I noticed that....because recovery is part of the boot image.

@topjohnwu do you have any input? Obviously you can't talk about how to circumvent Android security, but perhaps you can provide more insight into this problem and explain the mechanisms involved?

Further, if this is not a Magisk issue, perhaps we should move this thread to another forum?

 

[ipdev]

View attachment 5446899

We finally figured it out.

Turns out that once dm-verity and vbmeta verification are disabled, you CANNOT let the system boot with them enabled. If /vbmeta gets flashed, such as during an OTA or a factory image, and you let it boot into system, disabling verity/verification is going to require a wipe.

Unfortunately, for those of you upgrading from Android 11, there is simply no way around this - for permanent root, verity/verification must be disabled, and to disable verity/verification, /data must be clean.

I will be updating my guides shortly.

This is what I was referring to in my previous post.

As long as you disabled verity, verification and wiped data when initially updating to (or clean flash) Android 12.

This is what I plan to try.

fastboot --disable-verity --disable-verification --skip-secondary --skip-reboot update image-redfin-NameOfUpdate.zip
fastboot reboot bootloader

Once Android 12 is installed, verity and verification are disabled and data is wiped.

You can flash the boot partition as much as you want on Android 12.​

You can dirty-flash Android 12 again using the above fastboot command without having to wipe data again.​

The --skip-secondary is not needed, I just included it to speed up the flash a bit. ​

Just to clerify this last quote. I was dirty-flashing the full factory image disabling verity and verification during the update flash.
This only worked because I had already wiped data when I initially installed Android 12 clearing the the trigger.

Cheers.

Edit:
PS.
I had no issues updating to redfin-sp1a.211105.003.

Modified flash-all script.

#!/bin/sh

# Copyright 2012 The Android Open Source Project
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#      http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.

if ! [ $($(which fastboot) --version | grep "version" | cut -c18-23 | sed 's/\.//g' ) -ge 3103 ]; then
  echo "fastboot too old; please download the latest version at https://developer.android.com/studio/releases/platform-tools.html"
  exit 1
fi
fastboot flash bootloader bootloader-redfin-r3-0.4-7617468.img
fastboot reboot-bootloader
sleep 5
fastboot flash radio radio-redfin-g7250-00147-210811-b-7631450.img
fastboot reboot-bootloader
sleep 5
# fastboot -w update image-redfin-sp1a.211105.003.zip
fastboot --disable-verity --disable-verification --skip-secondary --skip-reboot update image-redfin-sp1a.211105.003.zip
fastboot reboot bootloader

 

[V0latyle]

Yeah. I sideloaded the OTA first, but then I dirty flashed the factory image, with only the disable options checked. Everything is good.

 

[hfam]

Thanks @ipdev and @V0latyle for the great posts, this looks like you've sorted this issue out as a solid workaround!

I'm on a Pixel 5a 5G/A11/Magisk 23, and want to go to A12. Since the Pixel 2 I too did all my updates via full system image and flash-all (del -w) using platform-tools and don't know much about OTA while maintaining root, I never needed it. @ipdev post gives me some hope because I understand that approach using the flash-all and full system images for updates because it's very familiar.

That said, can you confirm I have fully grasped the way forward based on your posts and code above?

- using latest platform-tools, update from A11 to A12 with full system image with supplied stock flash-all, leave in -w to allow the data wipe, and let it finish, of course removes root and is essentially a clean A12 (Is this correct or do I need to use the OTA for A12 instead? Do I need any disable flags on this first run?)

- using platform-tools, install the same full system image (because we don't have a newer monthly yet, so same image) again only this time use the edits in flash-all @ipdev shared (modified with the correct image name) which does a dirty full system flash (without -w, preserving /data), sets the appropriate disable flags, and will then allow using Magisk 23 to patch boot.img from the system image, and proceed to reflash it to boot as we used to do before A12 without failing.

- from that point forward, for the monthlies we can continue to update using full system image using the edited fastboot lines in @ipdev example (has no -w flag) to apply the monthly update in a way that will keep A12 from rejecting the patched boot.img to regain root.

Sorry for the lengthy post, but I really want to get this right, and I'm pretty excited and relieved that it appears we can do this all using full system images as I always have, no OTAs are required. I'm extremely grateful for this thread and the quick work of @ipdev @V0latyle @osm0sis and all the good folks working to get this sorted out.

Thanks all,
hfam

 

[ipdev]

Thanks @ipdev and @V0latyle for the great posts, this looks like you've sorted this issue out as a solid workaround!

I'm on a Pixel 5a 5G/A11/Magisk 23, and want to go to A12. Since the Pixel 2 I too did all my updates via full system image and flash-all (del -w) using platform-tools and don't know much about OTA while maintaining root, I never needed it. @ipdev post gives me some hope because I understand that approach using the flash-all and full system images for updates because it's very familiar.

That said, can you confirm I have fully grasped the way forward based on your posts and code above?

- using latest platform-tools, update from A11 to A12 with full system image with supplied stock flash-all, leave in -w to allow the data wipe, and let it finish, of course removes root and is essentially a clean A12 (Is this correct or do I need to use the OTA for A12 instead? Do I need any disable flags on this first run?)

- using platform-tools, install the same full system image (because we don't have a newer monthly yet, so same image) again only this time use the edits in flash-all @ipdev shared (modified with the correct image name) which does a dirty full system flash (without -w, preserving /data), sets the appropriate disable flags, and will then allow using Magisk 23 to patch boot.img from the system image, and proceed to reflash it to boot as we used to do before A12 without failing.

- from that point forward, for the monthlies we can continue to update using full system image using the edited fastboot lines in @ipdev example (has no -w flag) to apply the monthly update in a way that will keep A12 from rejecting the patched boot.img to regain root.

Sorry for the lengthy post, but I really want to get this right, and I'm pretty excited and relieved that it appears we can do this all using full system images as I always have, no OTAs are required. I'm extremely grateful for this thread and the quick work of @ipdev @V0latyle @osm0sis and all the good folks working to get this sorted out.

Thanks all,
hfam

Hi.

You need to wipe data once after disabling verity and verification on Android 12.

After that, you can update Android 12 without wiping data as long as you keep verity and verification disabled.

I only use the full factory images to update.
Same as I have since the Nexus days.
Factory Images for Nexus and Pixel Devices - WebSite - developers.google - Link

I am not sure what works using the incremental (OverTheAir) updates.

---

To clean flash a12 and disable both verity and verification add the disable flags.

fastboot -w --disable-verity --disable-verification update image-redfin-sp1a.211105.003.zip

The fastboot options control how the fastboot command(s) work.
-w Wipe userdata. (This is done at the end of update).
--disable-verity Sets disable-verity when flashing vbmeta.
--disable-verification Sets disable-verification when flashing vbmeta.

After the initial install and wipe, you can update (dirty flash) without the -w option.

fastboot --disable-verity --disable-verification update image-redfin-sp1a.211105.003.zip

You can add..
--skip-reboot Don't reboot device after flashing.
This will leave you in the last boot mode.

fastboot_d on newer devices.
I mentioned somewhere, I use this option and add a reboot to bootloader to the flash-all script.

If you just want to manually reboot the device or modify something before boot.
Example booting a Magisk patched boot image.​

--skip-secondary Don't flash secondary slots in flashall/update.
This will only flash the update to the current (active) slot.

Since the introduction of virtual A/B I have not noticed any advantage to flashing the opposite slot.
Only true A/B has saved me from bad flashes. ​

When testing and trouble shooting, I still flash to both slots on virtual A/B devices.
Just incase.

Hope it helps more than confuse.

Cheers.

 

[hfam]

Hi.

You need to wipe data once after disabling verity and verification on Android 12.

After that, you can update Android 12 without wiping data as long as you keep verity and verification disabled.

I only use the full factory images to update.
Same as I have since the Nexus days.
Factory Images for Nexus and Pixel Devices - WebSite - developers.google - Link

I am not sure what works using the incremental (OverTheAir) updates.

---

To clean flash a12 and disable both verity and verification add the disable flags.

fastboot -w --disable-verity --disable-verification update image-redfin-sp1a.211105.003.zip

The fastboot options control how the fastboot command(s) work.
-w Wipe userdata. (This is done at the end of update).
--disable-verity Sets disable-verity when flashing vbmeta.
--disable-verification Sets disable-verification when flashing vbmeta.

After the initial install and wipe, you can update (dirty flash) without the -w option.

fastboot --disable-verity --disable-verification update image-redfin-sp1a.211105.003.zip

You can add..
--skip-reboot Don't reboot device after flashing.
This will leave you in the last boot mode.

fastboot_d on newer devices.​

I mentioned somewhere, I use this option and add a reboot to bootloader to the flash-all script.​

If you just want to manually reboot the device or modify something before boot.​

Example booting a Magisk patched boot image.​

--skip-secondary Don't flash secondary slots in flashall/update.
This will only flash the update to the current (active) slot.

Since the introduction of virtual A/B I have not noticed any advantage to flashing the opposite slot.​

Only true A/B has saved me from bad flashes. ​

When testing and trouble shooting, I still flash to both slots on virtual A/B devices.
Just incase.

Hope it helps more than confuse.

Cheers.

Heya @ipdev!

Brother that's SO very helpful, thanks for the thoughtful and thorough reply!! As soon as I read you took the full system image approach to doing updates and saw you mention editing the flash-all to achieve success I knew I was home!! It has worked flawlessly and predictably for so many years, never even wanted to try OTA etc, and regaining root was a snap. This feels....comfortable and familiar!

This info, and the post previous from you where you shared the edits made to the flash-all in a code box make it really clear for me and I've got the confidence to give it a go once I've backed up what I need to incase it all goes pear-shaped.

My utmost gratitude, @ipdev, thanks so much for the assist, I'll report back when I've had a chance to do the upgrade and thanks again for all your help!

hfam

 

[Lughnasadh]

Hi.

You need to wipe data once after disabling verity and verification on Android 12.

After that, you can update Android 12 without wiping data as long as you keep verity and verification disabled.

I only use the full factory images to update.
Same as I have since the Nexus days.
Factory Images for Nexus and Pixel Devices - WebSite - developers.google - Link

I am not sure what works using the incremental (OverTheAir) updates.

---

To clean flash a12 and disable both verity and verification add the disable flags.

fastboot -w --disable-verity --disable-verification update image-redfin-sp1a.211105.003.zip

The fastboot options control how the fastboot command(s) work.
-w Wipe userdata. (This is done at the end of update).
--disable-verity Sets disable-verity when flashing vbmeta.
--disable-verification Sets disable-verification when flashing vbmeta.

After the initial install and wipe, you can update (dirty flash) without the -w option.

fastboot --disable-verity --disable-verification update image-redfin-sp1a.211105.003.zip

You can add..
--skip-reboot Don't reboot device after flashing.
This will leave you in the last boot mode.

fastboot_d on newer devices.​

I mentioned somewhere, I use this option and add a reboot to bootloader to the flash-all script.​

If you just want to manually reboot the device or modify something before boot.​

Example booting a Magisk patched boot image.​

--skip-secondary Don't flash secondary slots in flashall/update.
This will only flash the update to the current (active) slot.

Since the introduction of virtual A/B I have not noticed any advantage to flashing the opposite slot.​

Only true A/B has saved me from bad flashes. ​

When testing and trouble shooting, I still flash to both slots on virtual A/B devices.
Just incase.

Hope it helps more than confuse.

Cheers.

I've been pretty much doing it the same as you since the Nexus 5, except removing the -w from the flash-all.bat file and using the flash-all command.

So basically, for updating & dirty flashing now (I'm on the Pixel 6 Pro) we can do the same (after already factory resetting when 1st disabling those flags from the vbmeta.img in a prior flash of course), remove the -w from the flash-all.bat file but replace it with --disable-verity --disable-verification . And everything else in that line stays the same and just use the flash-all command. Boot, patch the boot image and go back and flash that.

Or alternatively also add --skip-reboot to that line as well and flash the patched boot image after using the flash-all command, if you decided to patch the new boot.img beforehand.

Is this correct?

 

[hfam]

heya @ipdev I'm about to do this and a question occurred to me as I'm re-reading your last few posts before I take the dive. Hopefully I've got this right, but a confirmation would be really appreciated.

Once updated doing the initial wipe with the 2 required disable flags...

fastboot -w --disable-verity --disable-verification update image-barbet-sp1a.211105.003.zip

...can I just install the Magisk apk, patch a boot.img and flash that just like we always have using ADB to get to bootloader, etc, OR is there a timing element that also requires that every time I want to flash a patched boot.img, I must first do a dirty system flash using the 2 disable flags (ie. after dirty flashing system using the 2 disable flags AND before rebooting A12) that must be adhered to when flashing a patched boot.img?

Thanks again for all the help!
hfam

 

[hfam]

Yeah. I sideloaded the OTA first, but then I dirty flashed the factory image, with only the disable options checked. Everything is good.

Oh HELL @V0latyle I have been rereading the posts in this thread over and over and I just now randomly saw "....I will be updating my guide shortly" and it finally clicked...I had no idea!! Feel like I've been typing all around ya in this thread!! Heading to your guide now! LOL!

Thanks again to all of ya!

hfam

 

[ipdev]

I've been pretty much doing it the same as you since the Nexus 5, except removing the -w from the flash-all.bat file and using the flash-all command.

So basically, for updating & dirty flashing now (I'm on the Pixel 6 Pro) we can do the same (after already factory resetting when 1st disabling those flags from the vbmeta.img in a prior flash of course), remove the -w from the flash-all.bat file but replace it with --disable-verity --disable-verification . And everything else in that line stays the same and just use the flash-all command. Boot, patch the boot image and go back and flash that.

Or alternatively also add --skip-reboot to that line as well and flash the patched boot image after using the flash-all command, if you decided to patch the new boot.img beforehand.

Is this correct?

Hi.

You seem to have it correct.

If you decide to add the --skip-reboot option the device will be left in bootloader_d since it is the last boot mode of update on newer devices.
So you will want to add a reboot to bootloader line after the update line.
You might also want to keep Windows from closing the command window after the batch script runs.

-- Intermission. --

Before I recommend something I try to test and double check it as much as I can.
It has been a while since I used Windows and wanted to test a few things.
Took longer than I thought it would.

After some updates (sdk and platform tools), and installing some new device drivers.
Trusty Windows 7 Pro (dual boot) on my trusty 2013 MackBook Air was ready to go. ​

I do not have a 6 Pro [raven] so I just used my 5 [redfin] to test.
I have a 6 [oriole] on order, should be delivered by Monday.

I edit the update script with Notepad++ since I know it is recommended to use for script files.
It does not include the Windows line ending junk.

This is what I ended up with to do a dirty reflash on my Pixel 5.
Along with keeping the command window open.

Note: For those stumbling across this post.
This is after the initial flash of Android 12 that included disabling verity, verification and wiping user data.​

Modified flash-all.bat

@ECHO OFF
:: Copyright 2012 The Android Open Source Project
::
:: Licensed under the Apache License, Version 2.0 (the "License");
:: you may not use this file except in compliance with the License.
:: You may obtain a copy of the License at
::
::	http://www.apache.org/licenses/LICENSE-2.0
::
:: Unless required by applicable law or agreed to in writing, software
:: distributed under the License is distributed on an "AS IS" BASIS,
:: WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
:: See the License for the specific language governing permissions and
:: limitations under the License.

PATH=%PATH%;"%SYSTEMROOT%\System32"
fastboot flash bootloader bootloader-redfin-r3-0.4-7617468.img
fastboot reboot-bootloader
ping -n 5 127.0.0.1 >nul
fastboot flash radio radio-redfin-g7250-00147-210811-b-7631450.img
fastboot reboot-bootloader
ping -n 5 127.0.0.1 >nul
:: fastboot -w update image-redfin-sp1a.211105.003.zip

:: echo Press any key to exit...
:: pause >nul
:: exit

fastboot --disable-verity --disable-verification --skip-reboot update image-redfin-sp1a.211105.003.zip
fastboot reboot-bootloader
ping -n 5 127.0.0.1 >nul
cmd /k

Probably do not need the extra ping but, why not delay a few seconds.

Then I just booted (fastboot boot) the magisk patched image (that I already patched while on the November build) and used the Direct install option in the Magisk app to install Magisk.

To close the command window (when I was done with it) a single exit command was all that was need.​

---

As for Magisk.

Since about the start of Android 11, I have had issues patching the new boot image beforehand.
Patching the December boot image while still on the November release for example.

So I generally patch the boot image while I am running the corresponding system (rom build).
Patch the December boot image while running the December release.

Then boot the Magisk patched image to make sure it works and nothing is broken.

If everything is good, I then just use the Direct install option in the Magisk app to install Magisk.
You could reboot to bootloader and then flash boot if you prefer.


Hope it helps more than confuse.

Cheers.

 

[Lughnasadh]

Hi.

You seem to have it correct.

If you decide to add the --skip-reboot option the device will be left in bootloader_d since it is the last boot mode of update on newer devices.
So you will want to add a reboot to bootloader line after the update line.
You might also want to keep Windows from closing the command window after the batch script runs.

-- Intermission. --

Before I recommend something I try to test and double check it as much as I can.
It has been a while since I used Windows and wanted to test a few things.
Took longer than I thought it would.

After some updates (sdk and platform tools), and installing some new device drivers.​

Trusty Windows 7 Pro (dual boot) on my trusty 2013 MackBook Air was ready to go. ​

I do not have a 6 Pro [raven] so I just used my 5 [redfin] to test.
I have a 6 [oriole] on order, should be delivered by Monday.

I edit the update script with Notepad++ since I know it is recommended to use for script files.
It does not include the Windows line ending junk.

This is what I ended up with to do a dirty reflash on my Pixel 5.
Along with keeping the command window open.

Note: For those stumbling across this post.​

This is after the initial flash of Android 12 that included disabling verity, verification and wiping user data.​

Modified flash-all.bat

@ECHO OFF
:: Copyright 2012 The Android Open Source Project
::
:: Licensed under the Apache License, Version 2.0 (the "License");
:: you may not use this file except in compliance with the License.
:: You may obtain a copy of the License at
::
::    http://www.apache.org/licenses/LICENSE-2.0
::
:: Unless required by applicable law or agreed to in writing, software
:: distributed under the License is distributed on an "AS IS" BASIS,
:: WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
:: See the License for the specific language governing permissions and
:: limitations under the License.

PATH=%PATH%;"%SYSTEMROOT%\System32"
fastboot flash bootloader bootloader-redfin-r3-0.4-7617468.img
fastboot reboot-bootloader
ping -n 5 127.0.0.1 >nul
fastboot flash radio radio-redfin-g7250-00147-210811-b-7631450.img
fastboot reboot-bootloader
ping -n 5 127.0.0.1 >nul
:: fastboot -w update image-redfin-sp1a.211105.003.zip

:: echo Press any key to exit...
:: pause >nul
:: exit

fastboot --disable-verity --disable-verification --skip-reboot update image-redfin-sp1a.211105.003.zip
fastboot reboot-bootloader
ping -n 5 127.0.0.1 >nul
cmd /k

Probably do not need the extra ping but, why not delay a few seconds.

Then I just booted (fastboot boot) the magisk patched image (that I already patched while on the November build) and used the Direct install option in the Magisk app to install Magisk.

To close the command window (when I was done with it) a single exit command was all that was need.​

---

As for Magisk.

Since about the start of Android 11, I have had issues patching the new boot image beforehand.
Patching the December boot image while still on the November release for example.

So I generally patch the boot image while I am running the corresponding system (rom build).
Patch the December boot image while running the December release.

Then boot the Magisk patched image to make sure it works and nothing is broken.

If everything is good, I then just use the Direct install option in the Magisk app to install Magisk.
You could reboot to bootloader and then flash boot if you prefer.


Hope it helps more than confuse.

Cheers.

Thank you so much for the thoughtful and detailed response. And for taking the time to test it out. Very much appreciated.

You bring up a good point about landing in bootloader_d after using the --skip-reboot command. I hadn't realized that.

After using the flash-all script I do usually then patch the boot image while in the new build and go back into bootloader and flash it so I think I'll just stick with that tried and true method, as you suggested.

I also use notepad++ to edit the flash-all.bat script on my Windows 11 laptop.

I'm glad its turned out as "simple" as just replacing the -w with --disable-verity --disable-verification in the flash-all.bat script.

Big thanks to you and everyone else who has conquered Google's shenanigans once again.

P.S. Good to know you can still do stuff with Windows 7 on a 2013 MacBook Air

 

[V0latyle]

As for Magisk.

Since about the start of Android 11, I have had issues patching the new boot image beforehand.
Patching the December boot image while still on the November release for example.

So I generally patch the boot image while I am running the corresponding system (rom build).
Patch the December boot image while running the December release.

Then boot the Magisk patched image to make sure it works and nothing is broken.

If everything is good, I then just use the Direct install option in the Magisk app to install Magisk.
You could reboot to bootloader and then flash boot if you prefer.

I've actually been thinking about this, it's probably better to patch the boot image post update anyway.

I'll update my guides.

 

[V0latyle]

Magisk Canary 23016 has fixed this issue.

Huge thanks to everyone who helped look into this issue, as well as the developers who effected the actual fixes:
@topjohnwu
@osm0sis
@ipdev
@pndwal

If there's anyone else I'm forgetting, let me know!

Requesting mods close this thread.