How To Guide September 18, 2023 TQ3A.230901.001 Global | .C2 Verizon - Unlock bootloader / Root Pixel 7 Pro [Cheetah] / SafetyNet

[WoKoschekk]

init_boot_b partition size: 8388608, init_boot_b image size: 67108864

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.

 

[Lughnasadh]

That was a mistake on my part. I flashed the patched init_boot and I don't have root. It looks like the command failed. Any ideas on what I'm doing wrong?

anon@dev:~/android/platform-tools$ sudo ./fastboot flash init_boot magisk_patched-25200_IZC7w.img
Warning: skip copying init_boot_b image avb footer (init_boot_b partition size: 8388608, init_boot_b image size: 67108864).
Sending 'init_boot_b' (65536 KB)                   OKAY [  0.491s]
Writing 'init_boot_b'                              FAILED (remote: 'failed to flash partition (init_boot_b)')
fastboot: error: Command failed
anon@dev:~/android/platform-tools$

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

 

[powershift]

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!

anon@dev:~/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
anon@dev:~/android/platform-tools$

 

[humb13]

same thing happened below to @JJT211...i can't believe a bug in platform-tools/fastboot.exe can cause such a hard brick that it would mess up the mobo that it wouldn't even pull power anymore...!
goes to show how vulnerable the pixels are when I'm fastboot(d) and/or in the middle of flashing!

it does seem that, when r34 inevitably causes an error, if you hard reset or keep attempting, it messes up the mobo irreparably (found in both these cases; but only cases I've seen)...

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.

 

[simplepinoi177]

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...

... 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. ...

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

issuetracker.google.com

 

[Dave_247]

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)....

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.

 

[WoKoschekk]

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.

 

[ShadowJP88]

Why does the march update has been removed from their repository?

Images d'usine des appareils Nexus et Pixel | Google Play services | Google for Developers

developers.google.com

 

[WoKoschekk]

Why does the march update has been removed from their repository?

Images d'usine des appareils Nexus et Pixel | Google Play services | Google for Developers

developers.google.com

Switch language to english or the march update isn't displayed. Seems to be a bug or sth else.

 

[WoKoschekk]

 

[pndwal]

... 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...

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

 

[WoKoschekk]

was NOT that "the phone is in the fastboot mode with the screen turned off"...

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.

then hold down vol- while connecting usb to PC to cause device to enter 'download' mode

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.

 

[Lughnasadh]

https://twitter.com/i/web/status/1637902911899410434

 

[humb13]

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

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.

Why does the march update has been removed from their repository?

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.

 

[WoKoschekk]

The problem with this logic is the fact that an older version (33.01) works perfectly whereas the newer one doesn't.

And that's the reason why (changelog 34.0.0 (February 2023)):

fastboot

• Improved flashing: flashall will now skip reboots to userspace if it can.

You can read it also in the log of the repo for ADB/Fastboot:

Log - refs/heads/main - platform/system/core - Git at Google

First entry is 667b1ef, 7 weeks ago.

 

[WhoIsJohnGalt1979]

Had a quick question for all the music aficionados who use a 3.5 mm to USB-C adaptor(small DAC) or use a USB-C DAC to listen to music. I hadn't used one for a while and have been using my Pixel Buds Pro since I got the Pixel 7 pro last year.

I recollect however, that on my Pixel 6 pro, for USB DAC to continue playing music when the screen goes off while using apps like UAPP and Neutron player, I had to set the Default USB configuration to "No Data Transfer". Lo behold, I had to do the same on my Pixel 7 pro too today for the same issue of music stopping on screen off while using a USB DAC. Both apps are set to Unrestricted battery usage.

Is the above the same for everyone else too? Am surprised this functionality hasn't been fixed for Android to handle in natively all this while.

Any comments are welcome in case I am doing something wrong or the issue manifests only in specific DACs.

 

[Displax]

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

So, here is the commit with fix. Waiting to merge.

https://android-review.googlesource.com/c/platform/system/core/+/2495616

 

[WoKoschekk]

So, here is the commit with fix. Waiting to merge.

https://android-review.googlesource.com/c/platform/system/core/+/2495616

This is a commit for "libsparse: Fix allocation failures on 32-bit systems."

 

[simplepinoi177]

Had a quick question for all the music aficionados who use a 3.5 mm to USB-C adaptor(small DAC) or use a USB-C DAC to listen to music. I hadn't used one for a while and have been using my Pixel Buds Pro since I got the Pixel 7 pro last year.

I recollect however, that on my Pixel 6 pro, for USB DAC to continue playing music when the screen goes off while using apps like UAPP and Neutron player, I had to set the Default USB configuration to "No Data Transfer". Lo behold, I had to do the same on my Pixel 7 pro too today for the same issue of music stopping on screen off while using a USB DAC. Both apps are set to Unrestricted battery usage.

Is the above the same for everyone else too? Am surprised this functionality hasn't been fixed for Android to handle in natively all this while.

Any comments are welcome in case I am doing something wrong or the issue manifests only in specific DACs.

The thread below in the Pixel 7 (non-pro) forum express your issue as well -- while also coming up with the same workaround you have -- so you might be able to find/connect some other people there as well...!

Screen off audio with wired headphones bug with march update ( 3/5/2023 ) Updated with workaround

I got the OTA and one of the issues I ran into was actually listening to any media app ( Spotify, Youtube, YT Music, etc. ). Whenever I turn the screen off, the audio stops and when you wake the screen to unlock it has a terrible slowdown. I...

forum.xda-developers.com

 

[simplepinoi177]

So, here is the commit with fix. Waiting to merge.

https://android-review.googlesource.com/c/platform/system/core/+/2495616

Thanks for that oh, great Displax!

The issue is a 32-bit one...??? (please pardon my uber amateur-ish take...)

Here's hoping for r34.0.2 ....!!