You flashed the boot.img (not the init_boot.img!!) with a size of 67.108.864 Byte (= exactly 64MB) to the partition init_boot. That's wrong.
How To Guide March 13, 2023 TQ2A.230305.008.C1 Global | .A3 WINDTRE/Canada - Unlock bootloader / Root Pixel 7 Pro [Cheetah] / SafetyNet
- Thread starter roirraW "edor" ehT
- Start date
-
- Tags
- bootloader pixel 7 pixel 7 pro root
At first glance it looks like you're using a patched boot.img, not a patched init_boot.img. Says size is 65536 KB. That would be the size of a boot.img. The size of an init_boot.img shoud be around 8192 KB.
EDIT: Ninja'd
That was it and the phone is rooted. I'll plan to do this sober next time lol. Thank you!At first glance it looks like you're using a patched boot.img, not a patched init_boot.img. Says size is 65536 KB. That would be the size of a boot.img. The size of an init_boot.img shoud be around 8192 KB.
EDIT: Ninja'd
Code:
[email protected]:~/android/platform-tools$ sudo ./fastboot flash init_boot magisk_patched-25200_dfucY.img
[sudo] password for anon:
Sending 'init_boot_b' (8192 KB) OKAY [ 0.053s]
Writing 'init_boot_b' OKAY [ 0.016s]
Finished. Total time: 0.069s
[email protected]:~/android/platform-tools$
I agree. It seems this time around the developers who write platform tools managed to do the impossible: fry a phone's motherboard with 34.01. The phone is not in the fastboot mode with the screen turned off. When you plug it into the PC, the PC won't see it at all. There is also no reaction when you plug it into a charger.
I had to bite the bullet and replace the phone. I got refurbished one at Amazon for $638 plus tax plus $40 delivery fee because I couldn't wait a week. When I got it and did that OTA upgrade that takes forever, I noticed it only went to the February release. I decided to cross my fingers and attempt a flash-all.bat update to March, only this time using 33.0.1 platform tools. Everything went perfect, no issues of any kind. This is hard proof that 34.0.1 is the culprit.
I know all this is risky. What bothers me about these developers is that despite the fact that this update is known to fry motherboards, it is still online for download. In fact, it took quite a bit of Googling to find 33.0.1. I refuse to believe the developers don't monitor forums such as this one where I'm not the only one complaining. There is a MAJOR problem with 34.0.1 and they keep silent and refuse to do anything about it. If there were any justice in this world I'd send them the bill for my new phone. Oh well.... just write the old phone off and continue, nothing more to do.
according to the posts below, Google has acknowledged it, but it is weird that it has not been taken down or made any warning on it; but then again, it's not just Pixels and/or Pixel 6 or 7 that uses platform-tools (the problem lies with not getting into fastbootD mode, which is a mode I believe only in Pixel 6 & 7; as I don't recall it in Pixel 5 or Pixel 2), so maybe Google doesn't want to remove it for it being used in all those other cases (as r34 & RC2 do supposedly address other specific fixes on bugs)....
Some minor good news regarding the platform tools bug, it seems someone from Google finally responded that they are aware of the issue and working on a fix. Maybe in 34.0.2 it will work.
Google Issue Tracker
issuetracker.google.com
Google concerning Platform Tools bug:
"Thanks, we've identified the root cause of this issue and are working on a fix."
Edit: Ninja'd
Google Issue Tracker
In theory I believe it should affect any phone that relies on using fastbootd as part of it's update procedure, however as it's still a relatively new feature in the world of Android, where aside from Google themselves everyone else is notoriously slow to adopt things unless forced, I don't know of any other phones that this could affect as Samsung use their own flashing method and all of the others don't seem to be affected else this would have blown up in a much bigger thing, which I assumed to be because they don't use or rely upon the newer userspace fastboot, or maybe there is something else that I have no idea about.
It's the
fastboot flashall command that is used to flash a single ZIP with one single command. Every Pixel firmware has a bootloader.img, radio.img and the firmware ZIP inside the downloaded ZIP. This firmware ZIP needs the flashall command. It's a own flash routine to flash the images on their partitions.Why does the march update has been removed from their repository?
developers.google.com
Images d’usine des appareils Nexus et Pixel | Google Play services | Google Developers
developers.google.com
Switch language to english or the march update isn't displayed. Seems to be a bug or sth else.Why does the march update has been removed from their repository?
Images d’usine des appareils Nexus et Pixel | Google Play services | Google Developers
The point re. 'Working Fastboot is possible with blackscreen' (again, it may well not apply to P7 series devices, but I only posted about the existence of this phenomenon; users will need to test) was NOT that "the phone is in the fastboot mode with the screen turned off"... Rather, some devices (incl. Qualcomm based) can enter fastboot without the user being aware because (due to some corruption) the screen may simply remain black...
The working method to fix such bricked devices (only know of success with older devices however) was to activate the flash before connecting device, then hold down vol- while connecting usb to PC to cause device to enter 'download' mode and drivers to discover and connect device (even while bootlooping or with 'dead' screen) and flashing to commence... This way the user becomes aware that fastboot flashing is working since there is no indication from device, and no indication on PC unless a trick like pressing vol- while plugging USB succeeds...
Clearly P7 series users would need to experiment with similar tricks to activate a fastboot mode 'blind', not simply hope for fastboot mode to be available when connecting device...
Some EDL mode may also be an avenue for P7 series users to explore...
PW
Last edited:
no matter if screen is off... or only shows nothing but is turned on... or is simply dead, it will be recognized when it gets connected to a PC. Otherwise it's not in fastboot mode then. A dead screen and no signal via USB means the device is dead.
A Pixel will boot into fastboot mode that way. Connecting a power source to a turned off device boots the charger mode (not the system by default). However, doing this while keep pressing the Vol- button boots it into fastboot mode.
Till now there's no documentation about sth similar like download/EDL mode on a Tensor SoC. I guess Google didn't implement such option to make the devices more secure since EDL is known to bypass the security features of Qualcomm CPUs.
The problem with this logic is the fact that an older version (33.01) works perfectly whereas the newer one doesn't. Shouldn't it be the other way around? There is no question this is a major bug, and from what I'm seeing I'm not the only one who's been burned by it.
No it hasn't. I just checked and it's still on there. In fact, I upgraded my new Pixel 7 Pro (the one replacing the one the developers fried) with the March update using 33.0.1 and it worked perfectly.
Whatever you do, stick with 33.0.1 for now. Don't even touch 34.0.1.
And that's the reason why (changelog 34.0.0 (February 2023)):
You can read it also in the log of the repo for ADB/Fastboot:
First entry is
667b1ef, 7 weeks ago.
Top Liked Posts
-
2
no matter if screen is off... or only shows nothing but is turned on... or is simply dead, it will be recognized when it gets connected to a PC. Otherwise it's not in fastboot mode then. A dead screen and no signal via USB means the device is dead.
A Pixel will boot into fastboot mode that way. Connecting a power source to a turned off device boots the charger mode (not the system by default). However, doing this while keep pressing the Vol- button boots it into fastboot mode.
Till now there's no documentation about sth similar like download/EDL mode on a Tensor SoC. I guess Google didn't implement such option to make the devices more secure since EDL is known to bypass the security features of Qualcomm CPUs.2
And that's the reason why (changelog 34.0.0 (February 2023)):
You can read it also in the log of the repo for ADB/Fastboot:
First entry is667b1ef, 7 weeks ago.1
The problem with this logic is the fact that an older version (33.01) works perfectly whereas the newer one doesn't. Shouldn't it be the other way around? There is no question this is a major bug, and from what I'm seeing I'm not the only one who's been burned by it.
No it hasn't. I just checked and it's still on there. In fact, I upgraded my new Pixel 7 Pro (the one replacing the one the developers fried) with the March update using 33.0.1 and it worked perfectly.
Whatever you do, stick with 33.0.1 for now. Don't even touch 34.0.1. -
9
https://source.android.com/docs/setup/about/build-numbers#build-ids-defined
First character is the version code of the release of Android, in this case Tiramisu (T) which is Android 13.
The second character is the branch of device platform that the build is from.
- D: Device specific branch, what the device launches with until the next branch merge.
- P: Primary branch, designates release branch for a successive version of Android for the device.
- Q: Quarterly platform release, the feature drops that happen every quarter.
The date roughly corresponds to when it was branched, but is mainly used to distinguish what the security patch level for release builds. Developers builds are closer to the true time it was branched.
The next three digits relate to versions based on that dated branch, and differ when a telecom needs a larger change, for example in the radio firmware or other larger change.
The last two characters are hotfixes, which usually include small changes for telecoms that need something like their APN changed after the date branch.
In this case TQ1A.230205.002 is Android 13 QPR1 that includes security patch 2023-02-05, and TQ2A.230305.008 is Android 13 QPR2 that includes security patch 2023-03-05.7Did my usual prep for the March update and everything went fine.
- Unhid Magisk
- Patched init_boot
- Edited Flash-all.bat by removing -w and adding -disable-verity and -disable-verification.
- Ran edited Flash-all
- Flashed modified init_boot
- Restored AOSPmod
- Hid Magisk
Just waiting for an updated kernel from Kiri5
There's a bug in their bug report...Google concerning Platform Tools bug:
"Thanks, we've identified the root cause of this issue and are working on a fix."
Edit: Ninja'd
Google Issue Tracker
"imporper"5
Have a look at your bootloader.img + radio.img. The device's name of a Pixel 7 Pro is "cheeta" and "bramble" (like yours) is the Pixel 4a 5G.5
tried to flash the latest build of AncientOS with it, did not work. Back to r33.0.3 and it worked fine -
59Pixel 7 Pro [Cheetah]
Note that more than three users have said that 34.0.1 did not work correctly for them. I recommend sticking with 33.0.3 (just below these quotes)
Someone reported it to Google (added a comment about 34.0.1 to the existing 34.0.0 report).
The download links for 33.0.3:
March 13, 2023
Download links working now, and thanks to @Ghisy for making me aware the links were up:
Factory Images for Nexus and Pixel Devices | Google Play services | Google Developers
developers.google.com
13.0.0 (TQ2A.230305.008.A3, Mar 2023, WINDTRE/Canada) Flash Link da1d99156fa03162ee8216277a8ff06b626f16efbc7e8b5d12096c5a10ede1ef 13.0.0 (TQ2A.230305.008.C1, Mar 2023) Flash Link cefc4e564cb920af510a44a9cdb982ba4e8af879f6796490e03128f12f92189e
https://support.google.com/profile/79501506
(revised v1.1 March 8, 2023)Android Security Bulletin—March 2023 | Android Open Source Project
source.android.com
Here there be dragons.
I am not responsible for anything at all. 
VERY IMPORTANT - On the Pixel 7/Pro, we use Magisk to patch
Thanks to @edcsxz, @Lughnasadh, and @AndyYan for news about that and confirming it.init_boot.img, NOT boot.img AND we flash the patched init_boot to the init_boot partition - do not flash it to the boot partition.
Moved @mariusnoor's provided zero-day OTA.zip to Post #8 - Old news from the OP.
INDEX:
- Post #2 - Unlocking Bootloader / Rooting / Updating | SafetyNet | ADB/Fastboot & Windows USB Drivers:
- How to Root the first time / aka How to unlock the Bootloader
- TL;DR - for the seasoned repeat users
- Unlocking Bootloader (required in order to root)
- How to update each month (and also how to root)[requires an unlocked bootloader for updating via this factory image method]
- OPTIONAL: If you want to flash both slots, after this first time, then after do the following
- SafetyNet
- Optional steps when updating - flashing custom kernels
- The two schools of thought on disabling Verity and Verification
- ADB/Fastboot and Windows USB Drivers - direct download links and the most recent changelog
- Post #3 - Other, most important resources:
- A list of other important apps
- TWRP [not made for the Pixel 7 (or 6) Pro yet - will update when or if ever it has - don't hold your breath]
- Factory Images (requires an unlocked bootloader)
- Full OTA Images(doesn't require an unlocked bootloader - you can ask questions in this thread, but I won't be providing the steps necessary, as I always use the factory image)
- @mariusnoor's provided official URL to download the zero-day OTA to
TD1A.220804.031.
- @mariusnoor's provided official URL to download the zero-day OTA to
- Check warranty status
Official Google Pixel Update and Software Repair(reported as of January 23, 2022 to still not be updated for the Pixel 6/Pro - no idea if it has yet now, or if it will be for the 7/Pro)- Official Google Pixel Install fingerprint calibration software (also available at the bottom of the Update and Software Repair page above) - I believe this is only helpful if you've replaced the screen - if it's anything like the Pixel 6 Pro: if you have the screen replaced, then you *must* have the fingerprint reader replaced as well.
- Find problem apps, Magisk, and LSposed Modules by (three different methods)
- Official Google Android Flash Tool (OEM Unlocking needs to be toggled on - you do not have to manually unlock the bootloader - their site will do that on its own)
- How to determine if you already have Verity and Verification disabled (required for custom kernels for now)
- How to unroot
- Post #4 - Build ID definitions
- Post #5 - Blank
- Post #6 - Regarding P7P 5G model numbers and capabilities, and how to determine your hardware version
- Post #7 - My personal advice for how to get your device back up and running as you had it before a factory reset
- Post #8 - Old news from the OP
Thank you to the following users who have all contributed greatly to my knowledge of Pixels since I came back to XDA a year ago after a few years of mostly inactivity. Apologies if I miss anybody. In alphabetical order:
40Unlocking Bootloader / Rooting / Updating | SafetyNet | ADB/Fastboot & Windows USB Drivers
Unlocking Bootloader / Rooting / Updating:
How to Root the first time / aka How to unlock the Bootloader:
Unlocking the bootloader will factory reset your device. There is no way around this. I highly suggest never re-locking your bootloader once you unlock it. If you do ever re-lock the bootloader, only do so after restoring the phone to 100% stock by using the latest Pixel 7 Pro Factory Image or Official Google Android Flash Tool.
Verizon variants:
T-Mobile and AT&T variants:
The direct-from-Google (or other retailers who aren't U.S. Carriers), the factory Carrier Unlocked Pixels:
The rest of the world's carriers:
Other than trying the things I mentioned above, there is nothing else that anyone on XDA can do to help get OEM unlocking to be ungrayed.
Unlocking Bootloader (required in order to root)
How to update each month (and also how to root) [requires an unlocked bootloader for updating via this factory image method]
- These three instructions only apply if you're already rooted and updating from one firmware version to another:
- Made sure all Magisk Modules have been updated.
- Disable all Magisk Modules.
- UNhide Magisk!
- If you are going to use the Official Google Android Flash Tool, then skip the steps I indicate with FAB(Flash-All.Bat).
- If using the Android Flash Tool to update/dirty flash, you should have the following items notselected:
- Deselect Wipe
- Deselect Force Flash all partitions (which will also wipe)
- Deselect re-lock bootloader
- If using the Android Flash Tool to update/dirty flash, you should have the following items notselected:
- Always use the latest ADB/Fastboot (SDK Platform Tools) and Windows USB Drivers.
- Unzip the Platform Tools.
- Download the latest Pixel 7 Pro Factory Image (at the bottom of the "Cheetah" section).
- Unzip the factory image to the same
platform-toolsfolder, i.e. so that flash-all.bat and all other files are in the same folder as ADB and Fastboot from the platform-tools. - * FAB VERY important - Edit the
flash-all.bat(on Windows) orflash-all.sh(on Linux) and remove the-wfrom thefastboot update image-cheetah-etcetera.zipline. This will keep the script from wiping your phone when you run it. - Extract only the
init_boot.imgfile from theimage-cheetah-etcetera.zipto the sameplatform-toolsfolder. - Copy the init_boot.img from the PC to the phone's internal storage.
- On the phone: Apply Magisk Stable to the new stock
init_boot.img. NOTE: It is always possible that an Android Update (Monthly, QPR [Quarterly Platform Release], new major Android versions, and Beta versions) might need a new version of Magisk Stable, Beta, or Canary from GitHub to work correctly. XDA forum for Magisk is here.- Launch the Magisk app.
- Beside "Magisk", click "Install".
- Click "Select and Patch a File", and choose the init_boot.img that you just copied to the phone's storage.
- Copy the Magisk'd init_boot.img (filename similar to
magisk_patched-25200_1a2B3c.img)back over to the computer. - * FAB Run commands:
Code:adb reboot bootloader flash-all.bat (on Windows) or flash-all.sh (on Linux) (Note: At least two Apple Macintosh users had trouble using the flash-all.sh - at least one of those users, everything went smooth once they used a Windows PC for this part of the process)IMPORTANT - The flash-all will take several minutes and reboot on its own several times including to a mode called "FastbootD", and finally reboot into full Android when it's done. Do not interrupt this process. On the FastbootD screen on the phone, do not use any of the manual selection options - let the flash-all script do it's work. Do not unplug your phone until it has fully booted into Android.
Thanks to @PurppleMonkey and @xgerryx for suggesting a warning about this. Thanks to @simplepinoi177 for suggesting the "FastbootD" clarification. - On the phone:
- Wait for the phone to boot normally.
- OPTIONAL: If you want to flash both slots, after this first time, then after do the following:
Code:adb reboot bootloader fastboot --set-active=other flash-all.bat
- On the computer:
- Open a Command Prompt and navigate to the
platform-toolsfolder. - Run command:
Code:adb reboot bootloader - After phone has rebooted into Bootloader (Fastboot) mode, run command:
Code:fastboot flash init_boot magisk_patched-25200_1a2B3c.img fastboot reboot
- Open a Command Prompt and navigate to the
- Unlock the phone.
- Confirm that the phone boots completely normally.
- Cautiously re-enable Magisk Modules.
- Reboot.
- Confirm everything worked fine.
- If the phone won't boot correctly after having enabled Magisk Modules, see either of the two solutions below:
-
- Find problem apps, Magisk, and LSposed Modules by (three different methods) section in my next post. After following that link, you may have to scroll up a little bit and the section title will be highlighted.
-
SafetyNet:
Use whichever of these is newer than the other:
- @Displax Universal SafetyNet Fix Mod on XDA.
- Official Universal SafetyNet Fix released by @kdrag0n available at XDA.
Optional steps when updating - flashing custom kernels:
ADB/Fastboot & Windows USB Drivers:
Platform Tools was updated in August 2022 to v33.0.3 (don't use the newer v34.0.0 - it has issues):
22
Indeed. My MOD is a temporary solution until kdrag0n release accurate fix.
I didn't change the update channel in the module on purpose so that everyone can upgrade to the new official version automatically without any problems.21Other, most important resources
A list of other important apps: - be sure to thank the respective OPs:
- Here's the Magisk section of XDA's forums, for rooting. Magisk on GitHub.
- @[email protected]'s section for Nova Launcher / Nova Launcher Prime - been using this since early 2012!
- @capntrips' thread [DEV] Kernel Flasher
- [KERNEL] CleanSlate |S2S|AdBlock|VIB|BatterySvr - Thanks @tbalden!
- [Kernel] [Android Stable]Kirisakura for Pixel 7/Pro aka "Pantah" - thanks @Freak07!
- [KERNEL]Despair Kernel - Thanks @DespairFactor!
- Multi Timer StopWatch - this multiple timer app is the bomb. Got widgets, customization like crazy, you name it.
- See my review with screenshots about Multi Timer StopWatch here.
- @Chainfire's thread [APP][5.0+][2020.12.22] CF.lumen v3.74 - I used to use this app to enable my phones to go extra dim before Android developed the better native capability for that, and the app has been confirmed to work on the Pixel 7 Pro for color control, too
- @jorrik98's thread [Themes / Apps / Mods] Better Internet Tiles - Bring back Wi-Fi and mobile data toggles! (non-root)
- @VR25's thread Advanced Charging Controller (ACC)
- AccA (Advanced Charging Controller App)
- @siavash79's thread [MOD][Xposed+Magisk][Pre-Release] AOSP Mods - System modifications for AOSP-based Android 12+. This is a big one for me, personally.
- @Quinny899's thread [APP][ROOT][11+][19/07] Classic Power Menu - Power Menu Replacement w/ Wallet, Controls on Android 11, 12, 13+
- Swift Backup
- @j4velin's thread [APP] Wallpaper Changer - been using this since mid-2011!
- @Jawomo's thread [Themes / Apps / Mods] aodNotify - Notification Light / LED - see my post in that thread here for the proper offsets to use the front camera notification circle on the Pixel 7 Pro.
- @Jawomo's thread [APP] dynamicSpot - iPhone 14 Pro Dynamic Island for android!
One of these two options:
- Official Google Android Flash Tool (OEM Unlocking needs to be toggled on - you do not have to manually unlock the bootloader - their site will do that on its own).
Select the options to:- Wipe
- Force flash all partitions
- Re-lock bootloader
- Flash the completely stock init_boot.img from the same firmware version that you're on:
Code:adb reboot bootloader fastboot flash init_boot init_boot.img
TWRP [not made for the Pixel 7 (or 6) Pro yet - will update when or if ever it has - don't hold your breath]
Factory Images (requires an unlocked bootloader)
Full OTA Images (doesn't require an unlocked bootloader - you can ask questions in this thread, but I won't be providing the steps necessary, as I always use the factory image)
Check warranty status - *may* reveal if a phone is refurbished, only if the phone was refurbished through Google - thanks to @Alekos for making me aware of the site.
Official Google Pixel Update and Software Repair(reported as of January 23, 2022 to still not be updated for the Pixel 6/Pro - no idea if it has yet now, or if it will be for the 7/Pro)
Official Google Pixel Install fingerprint calibration software (also available at the bottom of the Update and Software Repair page above) - I believe this is only helpful if you've replaced the screen - if it's anything like the Pixel 6 Pro: if you have the screen replaced, then you *must* have the fingerprint reader replaced as well.
Find problem apps, Magisk, and LSposed Modules by (three different methods):
- Google's Help Page for Find problem apps by rebooting to safe mode - this can be a lifesaver and keep you from having to do a restore to 100% complete stock or even from having to do a factory reset. This will deactivate all Magisk modules, and they'll remain deactivated even after you boot normally after briefly booting to safe mode. You can re-enable the Magisk modules as you wish to try to narrow down the problem if it was caused by a Magisk module. This can even get things working again after a Magisk Module wasn't finished installing and potentially causing a bootloop.
- You can also follow @Jon8RFC's advice:
Worked for me yesterday when I accidentally tried some old version of a Magisk Module. You have to reinstall your Magisk Modules, but if you're using a third-party widget, it won't disable them like Safe mode does. - (May only be for mis-behaving LSposed modules):
Official Google Android Flash Tool (OEM Unlocking needs to be toggled on - you do not have to manually unlock the bootloader - their site will do that on its own)
How to determine if you already have Verity and Verification disabled (required for custom kernels for now)
Alternative two more manual ways of checking:I keep seeing this asked, so I added a Magisk module for it to the linked Github release. With the module installed, you can just run:
Code:su avbctl get-verity avbctl get-verification
I spent way more time debugging that I downloaded Github's HTML of theupdate-binaryscript rather than the raw file than I care to admit.
Off to bed.
- Post #2 - Unlocking Bootloader / Rooting / Updating | SafetyNet | ADB/Fastboot & Windows USB Drivers:
