yashsingh1/xdaforums huggingface dataset:
[Google Pixel 7 Pro] capntrips:
It allows the device to boot with modified partitions. A certain amount of that is allowed by simply unlocking the bootloader. Where exactly the line is drawn seems to be a bit hazy with the Pixel 7, as some modifications with verity and verification enabled require a data wipe and others don't.

Simply unlocking the bootloader will trip SafetyNet, so you'll need the fix in any case.

Installing a custom kernel is optional, which is why it isn't rolled into the rooting instructions. Since you're already going to have to wipe to unlock the bootloader, you may as well go ahead and disable verity and verification while you're at it.

You can enable verity and verification without a wipe, but if you enable them (or forget to disable them during an upgrade), you'll have to wipe again to disable them.

Disabling verity and verification aside, it is probably easier to root first then install the kernel, since you can just flash the kernel zip with an app.

Since you're going to wipe the device after unlocking the bootloader, just skip through the initial setup the first time to get to the box to allow oem unlocking, then go through the actual setup the second time, after wiping for the bootloader unlock and disabling verity and verification.
[Google Pixel 7 Pro] Schroeder09:
does it make the phone any less secure per say though? this reminds me of people getting stuff to work by disabling SELinux, and while people did it, it was not recommended because it made the phone more vulnerable from a security standpoint.

will they stay persisted as disabled so long as i flash each month without the "-w" or will i need to remember to disable them every month when flashing security updates?

but to do this I should disable verity and verification at the onset with the fastboot commands before root is installed because if I install root and then disable these, isnt the root and everything I just did undone?
[Google Pixel 7 Pro] capntrips:
I would say unlocking the bootloader is a much higher security risk. As I said above, what exactly you can get away with changing without a data wipe by only unlocking the bootloader vs also disabling verification is still a bit of an unknown on the Pixel 7. On the Pixel 6, I would have said there was zero additional security risk, since you could flash whatever you wanted, so long as you didn't break a verity device (and you could and still can freely disable verity alone without wiping).

You will have to remember to disable them with every update. If you ever forget and boot without them, you'll be forced to wipe to disable them again.

Root is persistent through a data wipe, but any changes you make (system setup, app installation, magisk modules, etc) will be lost. That said, yes, if you're going to install a custom kernel, you should disable verity and verification immediately after unlocking the bootloader, since you'll have to do a data wipe after either operation.
[Google Pixel 7 Pro] T.A.R.D.I.S.:
Hello

I have a fail on the magisk_patched.img flash :

FAILED (remote: partition (init_boot) not found)

I take the last platform tool (r33.0.3), usb drivers on Android studio, flashing factory firmware as it said on tuto (november one).

So, what am i forgetting please?

Edit :

I tested this :

fastboot flash init_boot_b magisk_patched-25200_T9evv.img

And that's pass!!
[Google Pixel 7 Pro] badabing2003:
replace init_boot_b with init_boot
[Google Pixel 7 Pro] T.A.R.D.I.S.:
init_boot doesn't pass because i was blocked on slot b. So it passes with init_boot_b command.

When i try to flash factory firmware on the second slot, i have a "failed" too.

That the solution i try to flash the patched init_boot on slot b.
[Google Pixel 7 Pro] capntrips:
I saw your edit in your first post. Did you resolve this? If not, I just wanted to note another user had the exact same error message last month here. The issue ended up being an old version of fastboot on their PATH.
[Google Pixel 7 Pro] Fentadroid:
Just one question.

First time you disable verity and verification this way, you need to wipe.... right? (or maybe not..).
[Google Pixel 7 Pro] capntrips:
Yes, a wipe is required. Also, if you ever boot into the system without them disabled (e.g. after an update without the flags or if the device switches to an unpatched slot), you would be required to wipe to disable them.
[Google Pixel 7 Pro] Lughnasadh:
Correct.

EDIT: Oops, seems I've been Ninja'd once again 😅
[Google Pixel 7 Pro] Fentadroid:
So, editing flash-all.bat this way:

fastboot --disable-verity --disable-verification update image-cheetah-t1b3.221003.008.zip

is good only if you already have them disabled...

Maybe, if i want to disable verity and verification for the first time and wipe is mandatory, i can leave the "-w", right?

What happen if i don't wipe? system won't boot?
[Google Pixel 7 Pro] capntrips:
No, it works even the first time. I was simply noting that you have to remember to do it every time and that you might consider doing it on both slots the first time.

The system will prompt you to wipe data, so there's no need to leave the wipe flag (though it won't hurt anything).
[Google Pixel 7 Pro] T.A.R.D.I.S.:
I have last pltforms tools (r33.0.3) , adb and google last drivers versions (on android studio sdk), on w11. I flash the last firmware, bl unlocked and i'm not a newbie too.

I've found a solution to bypass my uncapacity to flash on slot b, so i've posted my solution to help others members 😉
[Google Pixel 7 Pro] simplepinoi177:
I'm doing the flash-all.bat firmware update and I'm at the point where it's in FastbootD, but my command prompt (not powershell) is "waiting for any device". My phone is being detected in Device Manager as Android Bootloader Interface. I've even unplugged and replugged the cable on both ends. I even went through the trouble of Disabling it in Device Manager and Enabling it right back. I can't get it to detect it.

Should I manually end the script/process? It doesn't seem to have begun writing sparse product_b yet, so I can't imagine it wrecking anything as the phone could still be using the firmware "stuff" that's established still as it should be untouched. Should I reboot to bootloader using the manual selection option?

I've seen many people soft-brick there devices at this stage...

It's unfortunate because I just updated and flashed my wife's P7P so I know what it looks like to go without a hitch!

UPDATE

Okay...crisis resolved... PHEW!!! What a relief. I've seen it go pretty bad for people at that point....

My assumption was right and since no image was extracted and no sparse was read or written, I just manually ended the script/process (command prompt), rebooted directly back to the bootloader, and ran the flash-all.bat again. I gained a bit of confidence in that bet after seeing KyleSEES run into the same thing, but he seemed to just end it and try it again. I think the problem was that I was using the same old command prompt I had used to update my wife's P7P two days ago. I don't know why that freaked it out -- I was hoping by using the same command prompt that did everything without a hitch, I might be able to rub some luck off on this go as well; boy was I wrong -- but apparently when I opened a brand new command prompt, it also went without a hitch this time. Now I'm back up and running and am now re-enabling all the modules and hoping this fixes a lot of my carrier & wifi issues...
[Google Pixel 7 Pro] badabing2003:
I'm surprised (although happy for you), that aborting at that stage it worked,

By that point all of the following are already overwritten

bootloader
radio
boot
init_boot
dtbo
pvmfw
vbmeta
vbmeta_system
vbmeta_vendor
vendor_boot
vendor_kernel_boot

I suppose they were still compatible with the older system / product ...

Considering that the script was expecting the phone to be in fastbootd mode, yet the phone was still in bootloader mode, I suspect if you issued the command:

fastboot reboot fastboot

The phone would have been put to fastbootd mode and the script continued.

Of course this is only a speculation.

I personally don't think the issue is at all related to using the same command prompt again.

Unless somehow in that command prompt, path to another Android platform tools was added.

In any case, great that you got it all sorted out.
[Google Pixel 7 Pro] slubgob:
I have a Google unlcoked phone. Previously rooted on the October update.

Went to update to November, and flashed the Verizon update rather than the unlocked because I'm on Verizon and wasn't thinking. Followed the guite, including removing -w, turning off Magisk modules etc. Booted up fine. Did not apply the patched boot image as I realized my mistake before that step.

So, I'm guessing it's probably a good idea to use the non-branded factory image. And I'm guessing if I booted OK, I'm probably good to just flash again using the correct images.

But I wanted to check in first and see if anyone has made a similar error in the past and make sure that I haven't really made a big mistake, or would be making a big mistake if I flashed again.
[Google Pixel 7 Pro] Homeboy76:
What mistake?

You have a Google Pixel 7 Pro with an unlockable bootloader, and the bootloader is unlocked.

Your carrier is Verizon.

You can use the Verizon or Global November 2022 factory image.

You've already flashed the Verizon November 2022 factory image, so just stay with it this month. If you want to root it, just patch the init_boot.img and flash it: fastboot flash init_boot magisk_patched...img

Next month flash the Global factory image. Then you'll know which factory image works best for you. :)
[Google Pixel 7 Pro] simplepinoi177:
you should consider keeping and continue flashing the Verizon images...

As stated by roirraW "edor" ehT above, there are "some tweaks/optimizations for particular carriers" that are included in them....it might be helpful...

it's why I went ahead and even dirty flashed the Verizon image over the global one I had inadvertently flashed first....
[Google Pixel 7 Pro] masri1987:
so i disabled verity and flashed the kernel using kernel flasher now i'm getting system corrupt error msg.

been a while since i've been doing this so i know i messed up, not sure where, i flashed to the mounted slot :\
[Google Pixel 7 Pro] capntrips:
Did you disable both verity and verification? Do you have the kernel flash log?
[Google Pixel 7 Pro] masri1987:
ah, i did not disable verification. just verity, thanks.
[Google Pixel 7 Pro] n:o:more:
Hello.

If I only unlock the bootloader, do I stop receiving OTAs automatically?

Thnks
[Google Pixel 7 Pro] Lughnasadh:
You should still receive them.
[Google Pixel 7 Pro] amtrak23:
I just unlocked the bootloader and was about to download the factory image when I noticed I have the Verizon build on the phone (TD1A.221105.003). I bought the Unlocked version from the Google store, so did I get sent the wrong version or did it do an OTA and update it to that at some point?

I set the phone up when I initially received and used it for a few days, but wiped it soon after.
[Google Pixel 7 Pro] simplepinoi177:
How long have you had the phone?

Do you run your phone on a Verizon line? Or run on their MVNO like Xfinity, Total Wireless, Spectrum Mobile, etc.?

I'm thinking, at the very least, you don't mistakenly have a Verizon Pixel that they give out on their contract as you would have their bloatware and would have been able to unlock the bootloader -- so at least there's that...! Depending on how long you've had your phone and when you unlocked your bootloader, maybe it did do the November OTA, and somehow recognized you were on Verizon's line and gave it that image -- although I can't imagine it being easy to miss your phone doing a full OTA update automatically without any prompt on your part.

But, if you are on a Verizon line, then being on TD1A.221105.003 would be more helpful and apply to your phone anyway. So I can't imagine there's anything to be concerned about. The only concern would be if you purchased your phone through the Google Store, and either they sent you a Verizon variant or somehow locked down your bootloader for being on Verizon's line -- which has never happened before -- and in any case you weren't able to unlock the bootloader on your phone. If that were the case, that would be the only drawback.

But if you're still curious/concerned, I would run your IMEI through IMEI checkers and/or Verizon's BYOD (Bring Your Own Device) IMEI checker and it should display what variant your IMEI is.
[Google Pixel 7 Pro] whitewallman:
Hello,

This is probably a noob question, but what is the advantage of the optional flashing of 2nd slot? I never have in the past. I just flash the active slot and root.

Thanks.
[Google Pixel 7 Pro] Lughnasadh:
It just makes sure that the inactive slot is bootable in case something happens that makes your current slot unbootable. Also, if you flash the firmware to your inactive slot and boot into that, then you know your former current slot is also bootable.
[Google Pixel 7 Pro] whitewallman:
Thank you! And to clarify, I don't root the 2nd slot, correct?
[Google Pixel 7 Pro] Lughnasadh:
You don't need to. Some like to root both slots but I prefer to have my inactive slot unrooted just to eliminate any possibilities of a bootloop caused by a Magisk mod or the like.
[Google Pixel 7 Pro] badabing2003:
I on the other hand have them both rooted.

I always alternate, ie each month I flash to the inactive slot (similar to what OTA does)

My thought process is that, if my current slot is bootable and functional (even rooted)

If I flash to inactive slot, one of two things can happen.

1- It works, which is the typical scenario, and wonderful :)

2- It fails to boot, something is not right (thankfully does not happen often), in which case the system will boot back to the previously active slot, which we know is still good, and gives me chance to figure out what might be going wrong.

I do understand the possibility of adding a Magisk module that could break booting to both slots, as /data/adb/magisk/modules is common to both, but I personally don't play with too many modules, and if this actually happens, I know I can flash stock boot to one of the slot and get out of it.

If I have to keep one slot stock, the process is quite lengthier if I also want to alternate slots.

Just my two cents,
[Google Pixel 7 Pro] whitewallman:
Thank you.

I'm a bit confused..

To flash both partitions, after flashing the active partition, which is a, before flashing the 2nd partition, do I use the command:

fastboot --set-active=other or fastboot --set-active=b?

Then, once 2nd partition is flashed, do I go back to partition a via fastboot --set-active=a?

My ultimate goal is to stay on a which is how it came out of the box.

I've never flashed a monthly update before on anything other than the active partition, so this optional step is new to me, so pardon my ignorance here. 😊
[Google Pixel 7 Pro] badabing2003:
both methods would work, make sure you do fastboot reboot bootloader after switching the slot.

and you don't have to go back to a, considering that both a and b are now identical.

I understand that you want to stay on a, but truly there is no difference if the current slot is a or b if they have the same content.

Let's say that you do that, you go back to a

Next month you flash a, and it all goes well, and you do this for several months, and one day something goes wrong during flashing a, and the system boots you to b

your b is several months behind a, whereas if you alternate each month (ie just flash to inactive slot) then your other slot is at most one month behind, which is better if things go wrong.

Of course, if you find switching slots too much effort, you're still good flashing only a, as long as you make sure b is functional.
[Google Pixel 7 Pro] whitewallman:
Thanks for your clarification! Since I've been updating only the active partition (a) and applying magisk_patched each month, I assume then that partition b is the factory image that the phone came with.. So I see the advantage of flashing both, or alternatively each month so the "emergency" partition isn't too outdated. So then, the fastboot --set-active=other is a part of the monthly update task after the normal update process. And just to make sure, fastboot --set-active=other command alternates between partitions rather than specifying a or b, correct?
[Google Pixel 7 Pro] badabing2003:
Just to be super clear.

if your device has never taken an OTA update, then most likely your device's b partition is still in the state it shipped from the factory, which probably means it's not bootable.

So one time only, make sure you flash both slots.

You just have to add

--slot all

to flash_all script on every line that there is fastboot, put it right after the fastboot (with space)

Moving forward (next month)

You first do

fastboot --set-active=other
fastboot reboot bootloader

Before doing the flash_all, so that flash_all applies to the inactive slot (doing it after is no good)
[Google Pixel 7 Pro] whitewallman:
Thanks again, and thank you for your patience!
[Google Pixel 7 Pro] whitewallman:
And before I run the script, Once, the flash-all bat should read:

PATH-XPATHX;"%SYSTEMROOT%\System32"

fastboot --slot all flash bootloader bootloader-cheetah-cloudripper-1.8-9070028.img

fastboot --slot all reboot-bootloader

ping -n 5 127.0.0.1 >nul

fastboot --slot all flash radio radio-cheetah-g5300g-220908-220908-b-9840061.img

fastboot --slot all reboot-bootloader

ping -n 5 127.0.0.1 >nul

fastboot --slot all update image-cheetah-td1a.220804.031.zip

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

exit
[Google Pixel 7 Pro] badabing2003:
I don't know what this line is doing

PATH-XPATHX;"%SYSTEMROOT%\System32"

You can remove the --slot-all from reboot command, although it is harmless if you keep it in.

I personally remove the exit line, so that in case anything goes wrong and I touch the keyboard, the window does not disappear on my and I get to review the errors.
[Google Pixel 7 Pro] Lughnasadh:
Does the --slot all command work on this device while updating the whole image? For the Pixel 6 series we couldn't put the --slot all command in the update line of the flash-all.bat file because we would get an error saying the file was too large (or something to that effect). The command worked for flashing individual images/partitions, but not when flashing/updating the whole system.

Have things changed with the Pixel 7 series?
[Google Pixel 7 Pro] whitewallman:
Excellent! Thanks again! And it's cool to remove the -w (which I did) to avoid a wipe on both partitions, correct?
[Google Pixel 7 Pro] badabing2003:
You're right, I forgot all about that, sorry I'm guilty, I don't manually modify the script ;)

@whitewallman

You can't add --slot-all to the update image line

Your can refer to this as template, this one works to flash both slot.

In fact it even allows you to flash the patched file before rebooting to system

@ECHO OFF

PATH=%PATH%;"%SYSTEMROOT%\System32"
fastboot.exe --slot all flash bootloader bootloader-xxx.img
fastboot.exe reboot-bootloader
ping -n 5 127.0.0.1 >nul
fastboot.exe --slot all flash radio radio-xxx.img
fastboot.exe reboot-bootloader
ping -n 5 127.0.0.1 >nul
fastboot.exe --skip-reboot update image-xxx.zip
echo Switching active slot to the other ...
fastboot.exe --set-active=other
echo rebooting to bootloader ...
fastboot.exe reboot bootloader
ping -n 5 127.0.0.1 >nul
fastboot.exe --skip-reboot update image-xxx.zip
echo rebooting to bootloader ...
fastboot.exe reboot bootloader
ping -n 5 127.0.0.1 >nul
echo flashing Magisk patched image ...
fastboot.exe --slot all flash init_boot magisk_patched_xxx.img
echo rebooting to system ...
fastboot.exe reboot
[Google Pixel 7 Pro] simplepinoi177:
So, I'm like whitewallman and have never done a flash-all to an inactive slot on my Pixel 2 XL or Pixel 5, so I also am unfamiliar with the practice and the benefits until now.

I have never taken an OTA, but I did flash the .031 in September and then the November full factory image a couple of weeks ago; does that count as taking the OTA and my inactive slot is still not bootable as it's still in the "state it shipped from the factory"?

If I never did the slot-all when I initially flashed the .031 full factory image, would anything bad happen if I were to do the slot-all with the next update (December)? Or would it be better to start with the flashing alternate slots and flash the December full factory image onto the other/inactive slot?--or would that be bad since I never did the slot-all initially before the first .031 update?
[Google Pixel 7 Pro] badabing2003:
No it does not count as OTA, I asked about OTA because OTA flashes to inactive slot, unlike flash_all script which flashes to the active slot.

One slot at a time issue discussed above is only applicable to Pixel 6 and newer devices, for your older devices, you can safely flash both slots with --slot-all option if you wanted to.

I suggest you do slot-all option instead of inactive option, because for inactive option you need to boot to it, and if your system is not bootable on that slot, it won't work.

once you do flash to both slots, then you can start doing the inactive flashing on subsequent months.

And yes you can wait for next Month's release and do it then, you don't have to do it now.
[Google Pixel 7 Pro] renzgy:
@xike456 hello, what method did you used through Magisk or changing device sku only?
[Google Pixel 7 Pro] xike456:
I only changed device SKU. After that the camera app will show option to turn off shutter sound
[Google Pixel 7 Pro] renzgy:
Okay. same HarryShan did. Anyway what app hex editor did you used because I have also Japan version and I want to do the same like you did. I hope you can help me I know already how to root the phone or unlock bootloader only my problem this shutter sound option in camera. And I never try using any hex editor application in PC. And which SKU model did you change?
[Google Pixel 7 Pro] xike456:
Mine changed from GFE4J to GE2AE. I use vscode with hex editor extension on PC. Just search and replace string in Hex editor
[Google Pixel 7 Pro] renzgy:
ok. Thank you!

I will try flashing the SKU. And one question if we change SKU still we can receive OTA update from Google?
[Google Pixel 7 Pro] whitewallman:
Thank you for all your assistance!

So... Starting with the next update, if I start with:

fastboot --set-active=other

fastboot reboot bootloader

Before my monthly update ritual, I'm basically replicating the OTA process in that I'm alternating partitions each month and my backup partition should always be a month behind, and a known working setup. Does that sound correct?

I'm just trying to simplify the monthly update process to avoid forgetting a step.

Thanks again!
[Google Pixel 7 Pro] badabing2003:
Correct
[Google Pixel 7 Pro] Larakali:
Yeah okay i think they havent uploaded any non-OTA ones.

Guess we wait then.

EDIT:

haha flash tool :D
[Google Pixel 7 Pro] emrexcem:
I don't understand why the boot.img is not available yet. Like wtf I can't even install netflix now because the first thing I always do is unlock the bootloader. Mildly annoying for an otherwise great experience.
[Google Pixel 7 Pro] Larakali:
Bc technically its supposed to release in 2 Days

Whatever @roirraW "edor" ehT said
[Google Pixel 7 Pro] roirraW "edor" ehT:
Because the factory image always comes out when the phone is officially released, which is tomorrow.
[Google Pixel 7 Pro] emrexcem:
Oh I didn't know that. Why do we have it then lol ? I think I pre ordered without knowing the benefits
[Google Pixel 7 Pro] roirraW "edor" ehT:
The most obvious reason for pre-ordering is the speed with which you get the new phone (first!) if you care about that kind of thing, but also sometimes pre-ordering comes with other advantages such as the $200 Google Store credit (or free Pixel Watch in some places in the world - I prefer the $200) plus the excellent trade-in value of my Pixel 6 Pro. The $200 and the trade-in value are my biggest reasons for pre-ordering.

After the phone is officially released tomorrow, those deals could change.

LOL, we're allowed to give different information. :D