yashsingh1/xdaforums huggingface dataset:
[Google Pixel 7 Pro] Reedickulus:
Pixel 7 ... on February update (230205) - keep bootlooping when trying to root with Magisk. Using 33.0.3 platform tools doesn't make a difference - still get bootloop stuck ---

I am patching init_boot.img and also flash vbmeta (fastboot flash vbmeta --disable-verity --disable-verification vbmeta.img) - no luck! Still doesn't work. I'm only able to recover my phone using these steps: https://www.droidwin.com/fix-cant-load-android-system-your-data-may-be-corrupt-without-reset/
[Google Pixel 7 Pro] synesthete:
Yeah I Flashed my February images with 33.0.3 and had no problems.
[Google Pixel 7 Pro] pndwal:
I don't have Pixel, but may I ask:

1) Did you extract and patch init_boot.img from the full OTA package you just restored with?

2) have you previously had Magisk or modules installed on this device?

3) If flashing the vbmeta.img to disable verity (I have no idea if this is generally needed), did you extract vbmeta from the same full OTA package before executing

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

and 'formatting the device' w/

fastboot -w

and then flashing the stock firmware (same full OTA package) again?

🤠 PW
[Google Pixel 7 Pro] Reedickulus:
I used full factory image: https://developers.google.com/android/images

Should I use the one from the ota file?
[Google Pixel 7 Pro] pndwal:
Evidently you'll need to do full factory wipe with that, but not with full OTA... Also, your fix-guide specifies OTA build... Nb. You apparently need 'device format' if flashing vbmeta w/ disable switches, but the guide still specifies the OTA package...

... Dunno... what do you think? 🤪😜 PW
[Google Pixel 7 Pro] Reedickulus:
In my 7 hours of trouble shooting I did indeed come across “device format” errors - do you know how to fix this?
[Google Pixel 7 Pro] Reedickulus:
I realize now you mean this step - will this erase/format the phone? I’m trying to avoid that if possible.
[Google Pixel 7 Pro] pndwal:
No real experience with this... The guide you cited gives pretty comprehensive steps however... Did you try following it w/ full OTA ROM?

Re. flashing vbmeta to disable verity, P7 users will have more ideas that me re. it's necessity... PW
[Google Pixel 7 Pro] pndwal:
Again, the guide indicates it's needed, so you've actually skipped two instructions at least... I simply noticed and can't help wondering if that's why issues persist...

P7 users may know better re whether you can avoid full wipes, but it isn't really a great issue since you can still boot to backup data so can restore it after fixes/flashes/wipes... Bootloops with no options to retrieve data are the real worry... 🙃 PW
[Google Pixel 7 Pro] Reedickulus:
Thank you for your help! I actually ended up getting everything working - I did so much haphazard trial and error I'm not exactly sure what did it, it was some combination of:

1) using PixelFlasher (https://xdaforums.com/t/pixelflashe...dating-rooting-managing-pixel-phones.4415453/) rather than the manual attempts I was making

2) booting into safe mode and thus "disabling" magisk modules

3) deleting magisk app (and the hidden magisk app I had previously made)

4) using the command line to delete all magisk modules (found the command somewhere in my googling/on this forum)

Now everything "works" - the only difference is now when I turn on the phone it says my system is corrupt in red, and I have to manually hit the "power" button to proceed with the boot ... but after hours of frustration this is a small price to pay to get everything working...

I didn't even want this update, but I guess I forgot to disable OTA updates in developer settings, and it updated to february 2023 (230205) updated and completely destroyed by root / magisk set-up.

Hope this may somewhat help anyone else similarly affected - I was able to re-root without wiping my data and you likely can too.
[Google Pixel 7 Pro] Lughnasadh:
Sounds like you had a Magisk mod in need of an update that was causing your bootloop when trying to boot up rooted. That red eio dm-verity corruption message should go away the next time you update. The bootloader is looking for an updated OS without any corruption errors. Once it notices this it should switch from eio mode to restart mode. No problem in just ignoring that corruption message.
[Google Pixel 7 Pro] WorldOfJohnboy:
Thank God I checked here before panicking... updated my PC to latest Platform-Tools and was soft bricked. Downgraded back to v33 and all is well! Thanks for keeping this thread updated!!!!
[Google Pixel 7 Pro] roirraW "edor" ehT:
To be clear, my instructions requiring a wipe when disabling Verity and Verification is only the first time you disable them, as long as you continue to disable them each time you flash an update to your phone. If you accidentally flash your phone without disabling them, then you'd have to wipe after disabling them again.

There are actually further details about when you have to wipe relating to flashing vbmeta, but above is the simple version. I can never remember the further details since I don't disable them.
[Google Pixel 7 Pro] Lughnasadh:
You can flash a factory image without wiping by just removing the "-w" from the flash-all.bat script. I think that guide is geared to those who don't have an unlocked bootloader, where sideloading a full OTA image is the only recourse, or for those who can't get into fastboot mode to flash a factory image.
[Google Pixel 7 Pro] Lughnasadh:
Since this is a common complaint in the Pixel 7 series forums, thought I'd just post it here..

Pixel 7 Pro's 'sticky' scrolling may get smoother as Google preps a fix

Hopefully, this update solves the problem for good.

www.androidcentral.com
[Google Pixel 7 Pro] letmedanz:
High time!

Although, there is a slight improvement in the beta compared to November-December stable.
[Google Pixel 7 Pro] roirraW "edor" ehT:
@Displax Universal SafetyNet Fix v2.4.0-MOD_1.2 on XDA or GitHub.
[Google Pixel 7 Pro] simplepinoi177:
Wanted to report (to put another one up on the "tally") that everything went well updating February. I used version r33.0.3. I consider myself rather lucky I checked this thread right before running flash-all because I had just updated to r34... Also, Displax's mod of USNF worked like a charm -- I checked and found that I wasn't passing meets_device_integrity prior to updating the firmware even; curious I was able to run Wallet and get Device is certified and Netflix show up in Play Store even though...

But I also had a question to bring up; Is there any manual way to backup Magisk settings and/or retain the settings after losing root when updating? The last 3 times I did the firmware update, when the phone loaded back up into the OS and I opened Magisk to patch the init_boot.img, an error message pops up showing that I lost root or something. I patch, reboot to the bootloader mode, flash the patched .img, and when I load the OS afterwards, I actually get a request for root access for the Magisk app I renamed when I hid it before. I then find that all my settings are reset and, this last time, much of the apps in my DenyList were no longer ticked. The last 3 updates, I just thought I was doing something wrong myself or it was just this firmware update. It's not too troublesome, but I was wondering & hoping there was an easier way to either retain it through the update process or back it up; I guess I'm getting spoiled and used to AOSP settings being able to backup all the settings and I just import the settings file and it's easy-peasy. Just some additional (possibly pertinent) information; while I do hide Magisk, I follow the OP's directions and make sure to unhide Magisk (I do this in tandem with disabling all modules) before running the flash-all. I guess I could always try to reset Magisk completely and remove the Magisk folder in the root directory and/or run the adb command to delete the modules and/or remove it within the app, but I really rather not go through the trouble of installing all the modules, all the LSPosed modules, and configure the DenyList if I don't have to. Was mostly wondering if any of you out there are currently employing some method that retains/backs up the settings when updating...

*I tried to search the thread to see if this was discussed already, but searching the keywords "magisk" "settings" and possibly "retain" didn't have results of "magisk settings" terms together even and so anytime "magisk" was mentioned, that's what was listed and there are so many numerous posts containing the word.

Thanks all! This thread is the best and has saved me so much grief, trouble, and has given the ultimate guidance!
[Google Pixel 7 Pro] roirraW "edor" ehT:
Cool.

Perhaps I should finally re-order my steps in post 2 so that everyone is directed to run Magisk on the new init_boot.img before using the flash-all.bat, which - along with flashing the Magisk'd init_boot.img before booting the new Android version - is the way to avoid this issue. Sorry about that. I'll change that as soon as I can.

You're welcome and thank you!
[Google Pixel 7 Pro] roirraW "edor" ehT:
@simplepinoi177,

Okay, I think I have Post 2 re-arranged correctly so that issue shouldn't happen anymore.

If anyone notices I messed something up, please don't hesitate to let me know.

Thanks!
[Google Pixel 7 Pro] simplepinoi177:
Aaahhh...I did wonder on that once upon a time (and maybe ran into that sequence of steps suggested somewhere in the forum at some point).... That it might be a better idea to patch the stock init_boot.img and flash it before loading up... I always figured it didn't make much difference to do it before or after -- and might be safer to load up the OS once with everything stock before modifying partitions -- but it seems the difference would be that loading Magisk if you lost root also loses/resets settings! Never occurred to me... Thanks @roirraW "edor" ehT!

But one thing comes to mind...wouldn't running the flash-all after flashing the patched .img just return the init_boot partition to stock (albeit newer stock from the firmware update image)? I know many people go through the trouble of replacing the stock init_boot.img file with the patched one in the image .zip file and in the end kinda "repackage" the image .zip file (i personally am a bit uneasy messing in any way and not keeping pure stock with such a crucial file) *i believe that's the same principle on how badabing2003 sets up how his PixelFlasher patches* -- but I also wonder, to avoid going through these extra steps, to not unlock your phone after the phone reboots to the OS after running flash-all, but reboot back to bootloader/fastboot mode and flash the patched image (again, before unlocking the phone initially after the flash-all successfully runs); or does just loading up the OS -- even without unlocking it initially -- load up Magisk unrooted and reset the settings anyway?

My only suggestion to the OP would be to put a small note as to the reasoning (for those new to rooting and/or who do not know why it's important or set at those steps) as well as it being a bit of a word of warning that some Magisk settings will be reset if done after flash-all and Magisk is loaded unrooted.
[Google Pixel 7 Pro] roirraW "edor" ehT:
You're welcome!

Thank you! It doesn't surprise me that I missed some re-arranging, or re-arranged things a little incorrectly. I think I just fixed it (switched steps #12 and #13). Let me know if I goofed anything else up.

I'm not sure, but possibly.

I think I've negated the possible need for that in my new fix, but let me know if I missed anything.

Cheers!

FYI: If you don't feel like proofreading further, no pressure! :)
[Google Pixel 7 Pro] simplepinoi177:
All looks good! Mostly just for over-cautiousness sake, I just might add to not unlock your phone when doing the adb reboot bootloader (after running flash-all)...

You're the man!
[Google Pixel 7 Pro] roirraW "edor" ehT:
Thanks again for checking! adb reboot bootloader boots into Fastboot mode, so Android isn't booted up and you can't unlock your phone. Maybe you meant fastboot reboot, but the only instance of that in that part of the instructions is after flashing the Magisk'd init_boot.img.

However, I did notice another mistake I made, so I now just swapped steps #13 and #14, so that the optional step of flash-all to the second slot, which is now #13, comes before flashing the Magisk'd init_boot.img.

Thank you!

As always, let me know if there is still anything outstanding. :D

Edit: OH, I see what you mean about before the adb reboot bootloader. I get it! Will do.
[Google Pixel 7 Pro] roirraW "edor" ehT:
OH, I see what you mean about before the adb reboot bootloader. I just moved the "Unlock the phone" from the "Wait for the phone to boot normally" line to its own new step #14 after the optional flash-all to the second slot.

THANKS!
[Google Pixel 7 Pro] radekmazur:
I messed it up last time and don't want to happen it again.

I have P7P pro, rooted, with Kirisakura kernel. I want to update to Feb release and keep root and then flash Kirisakura. How do I do that? Last time I messed up and had to reformat the phone.
[Google Pixel 7 Pro] Lughnasadh:
Suggest using Pixel Flasher and flash Kiri afterwards. Make sure you keep verity and verification disabled so you don't have to wipe.
[Google Pixel 7 Pro] Reedickulus:
I turned off OTA updates in developer tools so I don't have this drive-by update that ruins my root all over again! Still, would like to be able to fix the corruption issue. I'm somewhat hesitant to touch/play with the phone any more, but if there's an "easy" to fix the corruption issue, that would be nice.

It probably did have to do with a Magisk module. Again, it wasn't a planned update for me, otherwise I would have taken precautions. It just OTA downloaded the updated, and I must have accidentally confirmed to install the software at some point. Very strange, because I couldn't even get past the bootloop in order to delete Magisk and it's modules until I used the PixelFlash tool (so there was no way to delete Magisk). I guess I could have deleted the modules with the ./fastboot command I ended up using, but now I'll never really know what did the trick ...
[Google Pixel 7 Pro] Reedickulus:
What does vbmeta do? It's interesting so many guides say it's an optional step ... is that true?
[Google Pixel 7 Pro] roirraW "edor" ehT:
FYI, even with OTA automatic updates turned off in Developer settings, Google does seem to still retain the possibility of pushing an OTA anyway, as it was reported happening at least once on the Pixel 6 Pro when Android 13 got pushed out and prevented downgrading back to 12 in a one-time situation.

It's true that it's optional. Disabling Verity and Verification on the Pixel 7 Pro allows custom kernels to be flashed without causing corruption issues. There were problems with that on the Pixel 6 Pro at first, but then later the clever developers found ways so that custom kernels didn't require them to be disabled. I don't know what the current state of that is on the Pixel 6 Pro, but on the 7 Pro, it evidently became impossible or at least not reasonably possible to use custom kernels without disabling Verity and Verification.

I hope that answers your question.
[Google Pixel 7 Pro] simplepinoi177:
Heh...I kinda meant the exact opposite... I would NOT unlock the phone until AFTER you flash the patched init_boot; just to discourage opening the Magisk app unrooted (thus running into my issue of losing some previous settings) and maybe even causing the OS to run Magisk in the background and tripping some things up because you're still unrooted....

I acknowledge that this might be an over-cautious somewhat-unnecessary step, but it might save some headaches and assists in discouraging (without overly explaining) beginning or novice users from opening the Magisk app unrooted...

Sorry if I'm not being all too clear and/or unnecessary...😬
[Google Pixel 7 Pro] roirraW "edor" ehT:
Oh my goodness, I feel like a slight dingbat. Apologies, but you're exactly right - that's what I meant to do, and I just switched step #14 and #15 so that unlocking the phone yet again comes after flashing the Magisk'd init_boot.img.

LOL!

I really appreciate you hanging in there and pointing out what I've missed, as I get rather cross-eyed looking at my own detailed instructions more often than once a month! 😵😜
[Google Pixel 7 Pro] simplepinoi177:
It's as @Lughnasadh dash says, it's easiest (subjective opinion) to use Pixel Flasher to update the firmware and flash Kiri because it will assist in keeping verity and verification disabled too. It is a chore, but that is the thing in employing a custom kernel (at least it is for now); that you

must

make sure to disable verity and verification

every single time

you update the firmware (and/or when you flash it to stock in some fashion; though I would not think it necessary if you merely factory reset your phone) -- so potentially every month.

It's explained pretty extensively with other resources on the subject in the OP under the section

Optional steps when updating - flashing custom kernels

: in post #2. I don't employ a custom kernel, so I haven't familiarized myself with the reasons and circumstances, but I believe it must have something to do with setting your phone up in a way to "receive" and "employ" said custom kernel, but it just requires a phone wipe to get things set up for it, I guess -- so I guess that's why you need to wipe the first time, but not any subsequent times as long as you continue to keep them both disabled; but therefore would be required to do so again if you accidentally forget to include the command and update the firmware or flash it stock.

So either using Pixel Flasher or making sure to include the optional commands to disable verity and verification in the syntax when flashing (usually when editing the flash-all.bat; though I think I've seen it done where adding the optional command to the flash-all.bat command might work the same -- but I don't know this for sure) is the way to go about it without the need to wipe or "reformat" the phone....
[Google Pixel 7 Pro] simplepinoi177:
Hey...you've written such a great and extensive guide and resource! I'm sure it's easy enough -- especially considering you are re-ordering the steps and adding little tidbits -- to get "cross-eyed" even just looking and keeping things in order & accurate!

But probably all the rooted Pixel users (at least on XDA, if not all everywhere) have used these guides (I know you have them for other previous Pixels) and referenced these (& you) and owe a debt of gratitude for it! So no sweat and thank you again!
[Google Pixel 7 Pro] roirraW "edor" ehT:
Thank you, you are too kind, and I appreciate it. I'm glad I can help.
[Google Pixel 7 Pro] badabing2003:
I wonder if you have multiple Magisk managers, hidden or otherwise, regardless of the order of your steps, this behaviour is not expected.

Negative,

PixelFlasher first flashes the full stock, and before rebooting to system flashes the patched init_boot.
[Google Pixel 7 Pro] WorldOfJohnboy:
This might be fallout from when I was trying to flash February updates with v34, but now my P7Pro is showing the

“Your device is corrupt. It can’t be trusted and may not work properly.”​

Error when it reboots. Any way to easily fix?
[Google Pixel 7 Pro] schmeggy929:
Easy fix is to downgrade platform-tools to v33.0.3 and reflash firmware.
[Google Pixel 7 Pro] roirraW "edor" ehT:
Possible fixes that have worked before for various users including me, but not for at least one other recent user here:

Flash an old stock boot.img (I would do init_boot.img, too), then re-flash the new stock boot.img and init_boot.img.

If that doesn't fix it, waiting until March's update and flashing that should fix it. In the meantime, it just means an extra keypress to get past the corruption screen when you reboot. This is what fixed it for me back on the Pixel 6 Pro. I know it's a PITA in the meantime.
[Google Pixel 7 Pro] Reedickulus:
Thanks!
[Google Pixel 7 Pro] WorldOfJohnboy:
I already downgraded and flashed it (before I read this thread and saw the note) I think my boot.img may have FUBARed as a result of the initial v34 try.

So I'm going to start with a flash of stock boot.img and if still nothing, reflash stock init_boot.img and then flash a (newly) Magisk patched init_boot.img as @roirraW "edor" ehT suggests.
[Google Pixel 7 Pro] simplepinoi177:
I put that afterthought in the wrong place (should have put it higher, before the repackaging example); it was more in reference to patching it before the system loaded than repackaging the image .zip. My bad.

For anyone reading that post, I hope I did not give the wrong impression/info. Thanks badabing2003 for the correction/clarification...
[Google Pixel 7 Pro] WorldOfJohnboy:
So that worked. Flashed January's boot and init_boot, tried to boot (knew it wouldn't), then went back to the bootloader, flashed February boot/init_boot, booted phone and finally flashed my newly patched magisk init_boot and it worked, no more stupid "corrupt" message!
[Google Pixel 7 Pro] roirraW "edor" ehT:
Awesome news! Thanks for sharing that it worked.
[Google Pixel 7 Pro] halfbytecode:
Could you elaborate on how you managed to change the model number?

Did it work by just flashing the stock image, or you had to hex edit the device info (as mentioned in the Pixel 6 thread linked earlier)?
[Google Pixel 7 Pro] xike456:
Yes, you will need to root the device first, then follow step by step to edit device info (using hex editor)
[Google Pixel 7 Pro] halfbytecode:
Thanks for the quick reply. Was there a need to flash the stock image, after hex editing and flashing back the device info, though?
[Google Pixel 7 Pro] xike456:
You just need to change the device info. I don't remember but a restart or factory reset should load new device info.
[Google Pixel 7 Pro] supermansaga:
have the issues from v34 gone away? Sorry for the dumb questions
[Google Pixel 7 Pro] simplepinoi177:
i doubt until there's a version r34.0.1 or something posted/stated like that, the issues will remain -- because it seems that code will need to be reworked versus something "server side" and/or something with the factory images -- although, now that I think of it, maybe if there's a version update in the factory images, then that might be a sign that r34 might work (better) with those images then....
[Google Pixel 7 Pro] roirraW "edor" ehT:
Samsung debuts satellite connectivity for smartphones using the Pixel 7's modem

Samsung has developed the technology for satellite connectivity on smartphones, but using its own Exynos modem technology.

9to5google.com
[Google Pixel 7 Pro] roirraW "edor" ehT:
Google is bringing Magic Eraser to all Pixel owners and Google One members

Google One is about to get a lot better for subscribers, with video HDR, free photo book shipping, and Magic Eraser.

www.xda-developers.com

(including iPhone users of Google One)
[Google Pixel 7 Pro] roirraW "edor" ehT:
Changed post 2 now that @Displax has an independent OP for their Mod version of USNF:
[Google Pixel 7 Pro] roirraW "edor" ehT:
You can finally open Google Maps on your phone while Android Auto is running [U]

Google Maps is now able to open on smartphones while Android Auto is running on the vehicle's display, a welcome change.

9to5google.com
[Google Pixel 7 Pro] amders:
but no use.. if you go back or press the x button.. then the navigation on head unit also cancelled
[Google Pixel 7 Pro] roirraW "edor" ehT:
Interesting, thanks. I haven't checked it out myself yet. I'll keep that in mind. I wonder if that is working as they intended, or if that's a bug they'll fix.

Edit: Confirmed, same behavior here. On the phone, Maps gives a list of the individual navigation instructions, which can be handy for an assistant navigator, but the only choices from there are to either scroll if the instructions are long enough, or cancel navigation, then you can do the normal things.
[Google Pixel 7 Pro] Dr.Pepper:
new 34.0.1 realesed
[Google Pixel 7 Pro] d5aqoep:
Download link still shows 34.0.0
[Google Pixel 7 Pro] Siafall:
change language to English
[Google Pixel 7 Pro] badabing2003:
I don't think it's language related, mine is set to English and I still get 34.0.0