How To Guide Platform-Tools v34.0.3 has a different bug - May 1, 2023 TQ2A.230505.002 Global - Unlock bootloader / Root Pixel 7 Pro [Cheetah] / SafetyNet

[roirraW "edor" ehT]

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

I'd wish they would just skip to 35. 34.x has been bad enough, especially for the at least one user whose phone is unrecoverable.

Public congratulations @simplepinoi177!

 

[Lughnasadh]

I'd wish they would just skip to 35. 34.x has been bad enough, especially for the at least one user whose phone is unrecoverable.

Public congratulations @simplepinoi177!

I think I've seen 3 or so people who say their phone was "bricked" because of this. Not good...

 

[simplepinoi177]

I'd wish they would just skip to 35. 34.x has been bad enough, especially for the at least one user whose phone is unrecoverable.

I think I've seen 3 or so people who say their phone was "bricked" because of this. Not good...

I think I've seen the same people (me and @Lughnasadh definitely roam the same threads)...
It's quite incredible that it has led to hard-bricking -- and even one instance where the repair shop (i believe it was even the authorized uBreakiFix) where the system board wasn't pulling any power! -- than just simply bootlooping or "system/partition corrupted" errors! It usually goes when those hard-bricked members re-attempt multiple times, in the same open instance, then manually restart or use the volume-power button selection.

At this point, let's just call r34 a bust and move to r35 like roirraW "edor" ehT suggests...!!!

 

[WoKoschekk]

The issue is a 32-bit one...???

The issue that is linked is related to Windows 32bit, but it's another problem. No related to the issue discussed here regarding the bricked devices.

 

[simplepinoi177]

The issue that is linked is related to Windows 32bit, but it's another problem. No related to the issue discussed here regarding the bricked devices.

Thanks...I had assumed (but wrongly)...

God....I really would've thought that would've been top priority considering all of us that manually flash the update and numerous bricks and bootloops have occurred that THAT would be the issue they would work on foremost and/or report on....
I guess we're all just on "pins and needles" waiting for a positive report from them on this; especially those who have been helping countless members after they brick or bootloop because they've always been taught "download the most latest version of platform-tools..."!

 

[WoKoschekk]

God....I really would've thought that would've been top priority considering all of us

They already do. There're a few devs working on different parts of this repo. Here's the log:

Log - master - platform/system/core - Git at Google

All links related to "flashall", "super", "flashing_plan" and some others.

 

[bluegrass55]

The step to edit the .bat file IS NOT USELESS! I very much caution not to skip this step as this step is what directs the flash-all to NOT wipe your phone back to stock! Especially when doing this each time you flash an update -- probably each month...!
I believe @roirraW "edor" ehT directed to put the init_boot.img file to the platform-tools folder simply for the reason of merely keeping track of the file -- for when you transfer it to your phone for Magisk to patch. You actually can put it anywhere you wish, as long as you can keep track of it for when you transfer it to the phone.
Having the magisk patched init_boot.img file (magisk_patched_######.img) is best in the platform-tools folder so when running the fastboot command, it automatically knows where the file is as it's in the same folder vs. it somewhere else and you would need to specifically type out the whole filename with its folder details in the syntax...

When editing the flash-all line to remove -w what should it look like this after editing?

fastboot -w --skip-reboot update image-cheetah-2023032000.zip

fastboot --skip-reboot update image-cheetah-2023032000.zip ( is this correct)?

 

[simplepinoi177]

When editing the flash-all line to remove -w what should it look like this after editing?

fastboot -w --skip-reboot update image-cheetah-2023032000.zip

fastboot --skip-reboot update image-cheetah-2023032000.zip ( is this correct)?

yes, removal of any (although normally there is just 1 instance) instance of "-w" works best; just keep in mind spacing before and/or after...so the line looks good

Also I'm curious as to why you added "--skip-reboot"?
I've only ever experienced adding that command for when flashing to both slots (although I'm sure there are other reasons to, I just can't recall what they are or seeing them); as a reboot would clumsily boot into the OS after the flash-all and you'd have to go through some trouble to get back into the bootloader and switch slots to flash again...

 

[bluegrass55]

yes, removal of any (although normally there is just 1 instance) instance of "-w" works best; just keep in mind spacing before and/or after...so the line looks good

Also I'm curious as to why you added "--skip-reboot"?
I've only ever experienced adding that command for when flashing to both slots (although I'm sure there are other reasons to, I just can't recall what they are or seeing them); as a reboot would clumsily boot into the OS after the flash-all and you'd have to go through some trouble to get back into the bootloader and switch slots to flash again...

Thanks for the reply.

I didn't add the "--skip-boot" text. This is how it comes in the Flash-all text.
This is from the Graphene OS. After updating the ROM I'll be flashing the Magisk patched boot to re gain root.

 

[roirraW "edor" ehT]

Thanks for the reply.

I didn't add the "--skip-boot" text. This is how it comes in the Flash-all text.
This is from the Graphene OS. After updating the ROM I'll be flashing the Magisk patched boot to re gain root.

Do you mean this is a Flash-All.bat for the Graphene OS?

My stock Android Flash-All.Bat looks like this after removing the -w:

fastboot update image-cheetah-tq2a.230305.008.c1.zip

Hence, the confusion, if we're talking about something other than Google's official firmware.

 

[Displax]

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

The issue that is linked is related to Windows 32bit, but it's another problem. No related to the issue discussed here regarding the bricked devices.

Just click on bugs links in the head of commit...

 

[roirraW "edor" ehT]

To spell it out, @Displax is talking about:

f06debc

which resolves to:

libsparse: Fix allocation failures on 32-bit systems.

libsparse uses mapped files for length computation checks and writing
output data. The platform-tools package for Windows is 32-bit, and if
an embedded file in the stream is large enough, mapping will fail. In
theory, this failure mode could happen on 64-bit systems as well.

As a workaround, map files in chunks of 256MB instead. This is
implemented by adding a new "fd_chunk" callback to the sparse ops
struct.

Bug: 273933042
Bug: 268872725
Test: fastboot update on Windows
Change-Id: Ic40696b34a1d0951787c899db701fc2fa204eb18

 

[WoKoschekk]

To spell it out, @Displax is talking about:

which resolves to:

Yes, but I don't see any connection between this commit and the bug regarding the flashall command.

 

[roirraW "edor" ehT]

Yes, but I don't see any connection between this commit and the bug regarding the flashall command.

I certainly won't find out first hand once the fix is released. I will wait for the positive reports! I don't have time for phone mishaps these days.

 

[Lughnasadh]

Yes, but I don't see any connection between this commit and the bug regarding the flashall command.

This is the error people are getting:

Sending sparse 'super' 1/1 (4194303 KB) FAILED (Sparse file is too large or invalid) fastboot: error: Command failed

Seems like the mapping fails because the file is too big, so they will map files in chunks of 256MB instead.

 

[Schroeder09]

Thanks for the reply.

I didn't add the "--skip-boot" text. This is how it comes in the Flash-all text.
This is from the Graphene OS. After updating the ROM I'll be flashing the Magisk patched boot to re gain root.

People root graphene? I thought that was counterproductive for graphene theory? how's it work as compared to the stock Google ROM for p7p? I've considered it. Using xprivacy Lua has been the closest I've gotten to using privacy-centric apps and ROMs.

 

[WoKoschekk]

This is the error people are getting:

Sending sparse 'super' 1/1 (4194303 KB) FAILED (Sparse file is too large or invalid) fastboot: error: Command failed

Seems like the mapping fails because the file is too big, so they will map files in chunks of 256MB instead.

Let me explain the error in v34.0.0:

As we all know the partition /super contains a few dynamic partitions. These dynamic partitions only can be handled in userspace by fastbootd mode (which is an executable binary inside the recovery's ramdisk). To flash /super there are two existing methods:
1. In bootloader mode by flashing a super.img to /super.
2. In fastbootd mode by flashing the single dynamic partitions inside of /super.

The firmware of a Pixel has got no super.img inside it, but instead of this another zip archiv (imagesXXX.zip) with all dynamic partitions and a super_empty.img. The super_empty.img is only a partition table of /super with all start/end blocks of the dynamic partitions. These start/end blocks may change with every new firmware build and that's why they are called "dynamic".

For flashing the Pixel's firmware the command fastboot flashall is used by Google. The flashing process starts in bootloader mode to flash bootloader.img + radio.img and then the flashing routine behind fastboot flashall has to decide whether to stay in bootloader mode or to switch into fastbootd mode. For Pixel devices fastboot should switch into fastbootd mode to flash the single dynamic partitions. But it won't and that's the error in v34.0.0.!

Instead of this fastboot remains in bootloader mode and tries flashing /super with a super.img. Let's have a look again at the error message that users get:

Sending sparse 'super' 1/1 (4194303 KB)           
FAILED (Sparse file is too large or invalid)
fastboot: error: Command failed

Due to the fact that there's no super.img (neither as a raw image nor as a sparse image) fastboot outputs that error message above. The reason for getting this error you'll find in the source (line 249):

RetCode FastBootDriver::Download(const std::string& partition, struct sparse_file* s, uint32_t size,
                                 size_t current, size_t total, bool use_crc, std::string* response,
                                 std::vector<std::string>* info) {
    prolog_(StringPrintf("Sending sparse '%s' %zu/%zu (%u KB)", partition.c_str(), current, total,
                         size / 1024));
    auto result = Download(s, use_crc, response, info);
    epilog_(result);
    return result;
}
RetCode FastBootDriver::Download(sparse_file* s, bool use_crc, std::string* response,
                                 std::vector<std::string>* info) {
    error_ = "";
    int64_t size = sparse_file_len(s, true, use_crc);
    if (size <= 0 || size > MAX_DOWNLOAD_SIZE) {
        error_ = "Sparse file is too large or invalid";
        return BAD_ARG;
    }

In short: If sparse_file size is 0 Byte or less (= no sparse_file) than output error text "Sparse file is too large or invalid".

Why does this error occure since v34.0.0?

The developer David Anderson thought it was a good idea not to boot into fastbootd mode as much as really, really needed. He wanted to save time during the flashing process (round about 50 sec.). See fully detailed in the spoiler below.

Spoiler: reasons for changing

fastboot: Avoid reboots to userspace when using flashall/update.

Reboots to fastbootd (userspace fastboot) take a long time, particularly
due to the orange AVB screen and the likelihood of devices having uart
enabled. For "flashall", there is rarely a need to actually go into
userspace, because all of super is getting thrown away. We can just
flash super in the bootloader.

In the past we didn't do this because computing super.img is expensive -
both in terms of time (due to reading dependent images) and in terms of
space (it's easily over 5GB).

But we don't actually need to fully compute super.img. We can build a
sparse_file containing the metadata/headers, with additional references
to each image file containing partition data. Liblp provides the API to
do that, and here, we simply need to translate the layout to libsparse.

On Pixel, this reduces flashall time by around 35-50 seconds, or around
20% of total time, depending on whether uart is in use.

There are some caveats, in which case we'll fall back to normal
fastbootd. This does not work on non-A/B devices, on retrofit dynamic
partition devices (Pixel 3), and in some other edge-casey scenarios. If
it fails, -v will add logging information about why.

Bue: 266982466
Test: fastboot flashall on Pixel 5+
Change-Id: Ie040da597d739faa7f834202184cec8f8e412076

(source: https://android.googlesource.com/platform/system/core/+/667b1efadd8ce8d8cf19d0684a871125cce203d3)

But something went wrong during the execution of his code. As a result of this the flashing process ends with an error and without flashing the contents of /super.
Following the log of the repo /android/platform/system/core/refs/heads/master/./fastboot several changes were made till today. But we'll have to wait for the next update, which will (hopefully) be officially released soon.

I hope it is somewhat understandable.

 

[simplepinoi177]

Spoiler

Let me explain the error in v34.0.0:

As we all know the partition /super contains a few dynamic partitions. These dynamic partitions only can be handled in userspace by fastbootd mode (which is an executable binary inside the recovery's ramdisk). To flash /super there are two existing methods:
1. In bootloader mode by flashing a super.img to /super.
2. In fastbootd mode by flashing the single dynamic partitions inside of /super.

The firmware of a Pixel has got no super.img inside it, but instead of this another zip archiv (imagesXXX.zip) with all dynamic partitions and a super_empty.img. The super_empty.img is only a partition table of /super with all start/end blocks of the dynamic partitions. These start/end blocks may change with every new firmware build and that's why they are called "dynamic".

For flashing the Pixel's firmware the command fastboot flashall is used by Google. The flashing process starts in bootloader mode to flash bootloader.img + radio.img and then the flashing routine behind fastboot flashall has to decide whether to stay in bootloader mode or to switch into fastbootd mode. For Pixel devices fastboot should switch into fastbootd mode to flash the single dynamic partitions. But it won't and that's the error in v34.0.0.!

Instead of this fastboot remains in bootloader mode and tries flashing /super with a super.img. Let's have a look again at the error message that users get:

Sending sparse 'super' 1/1 (4194303 KB)       
FAILED (Sparse file is too large or invalid)
fastboot: error: Command failed

Due to the fact that there's no super.img (neither as a raw image nor as a sparse image) fastboot outputs that error message above. The reason for getting this error you'll find in the source (line 249):

RetCode FastBootDriver::Download(const std::string& partition, struct sparse_file* s, uint32_t size,
                                 size_t current, size_t total, bool use_crc, std::string* response,
                                 std::vector<std::string>* info) {
    prolog_(StringPrintf("Sending sparse '%s' %zu/%zu (%u KB)", partition.c_str(), current, total,
                         size / 1024));
    auto result = Download(s, use_crc, response, info);
    epilog_(result);
    return result;
}
RetCode FastBootDriver::Download(sparse_file* s, bool use_crc, std::string* response,
                                 std::vector<std::string>* info) {
    error_ = "";
    int64_t size = sparse_file_len(s, true, use_crc);
    if (size <= 0 || size > MAX_DOWNLOAD_SIZE) {
        error_ = "Sparse file is too large or invalid";
        return BAD_ARG;
    }

In short: If sparse_file size is 0 Byte or less (= no sparse_file) than output error text "Sparse file is too large or invalid".

Why does this error occure since v34.0.0?

The developer David Anderson thought it was a good idea not to boot into fastbootd mode as much as really, really needed. He wanted to save time during the flashing process (round about 50 sec.). See fully detailed in the spoiler below.

Spoiler: reasons for changing

fastboot: Avoid reboots to userspace when using flashall/update.

Reboots to fastbootd (userspace fastboot) take a long time, particularly
due to the orange AVB screen and the likelihood of devices having uart
enabled. For "flashall", there is rarely a need to actually go into
userspace, because all of super is getting thrown away. We can just
flash super in the bootloader.

In the past we didn't do this because computing super.img is expensive -
both in terms of time (due to reading dependent images) and in terms of
space (it's easily over 5GB).

But we don't actually need to fully compute super.img. We can build a
sparse_file containing the metadata/headers, with additional references
to each image file containing partition data. Liblp provides the API to
do that, and here, we simply need to translate the layout to libsparse.

On Pixel, this reduces flashall time by around 35-50 seconds, or around
20% of total time, depending on whether uart is in use.

There are some caveats, in which case we'll fall back to normal
fastbootd. This does not work on non-A/B devices, on retrofit dynamic
partition devices (Pixel 3), and in some other edge-casey scenarios. If
it fails, -v will add logging information about why.

Bue: 266982466
Test: fastboot flashall on Pixel 5+
Change-Id: Ie040da597d739faa7f834202184cec8f8e412076

(source: https://android.googlesource.com/platform/system/core/+/667b1efadd8ce8d8cf19d0684a871125cce203d3)

But something went wrong during the execution of his code. As a result of this the flashing process ends with an error and without flashing the contents of /super.
Following the log of the repo /android/platform/system/core/refs/heads/master/./fastboot several changes were made till today. But we'll have to wait for the next update, which will (hopefully) be officially released soon.

I hope it is somewhat understandable.

without having to go through most of the post and explanation and just having a cursory glance...I really would rather have waited the extra 35 50 seconds in the flash-all process than have this whole mess happening
*again, I haven't read it all in full, so I'm sure there is more reasons for it, I just saw that snippet and wanted to comment on it already...

 

[bluegrass55]

People root graphene? I thought that was counterproductive for graphene theory? how's it work as compared to the stock Google ROM for p7p? I've considered it. Using xprivacy Lua has been the closest I've gotten to using privacy-centric apps and ROMs.

Yes rooting and having an unlocked bootloader is strongly discouraged by the Graphene developers, but I have a call recording app that only works with root.

I migrated to Graphene when Marcel stopped supporting Xprivacy Lua. It is the next best thing and I recommend it. Everything works and they provide regular security updates.

I have not used stock Google OS in a long time so cannot compare it with Graphene.

 

[xunholyx]

I'm curious as to why you added "--skip-reboot"

I know this wasn't meant for me, but I add that to the flash-all myself too. I then add an extra line

fastboot flash init_boot **magisk patched init_boot.img**

Followed with

fastboot reboot