Hello,
Today I made an attempt to update my Nexus 5 to Android 6, manually.
So I put it into USB debugging mode, connected to my PC, and run "flash-all.bat" from firmware archive.
For some reason it ended up with message FAILED, but Android 6 was installed on my phone.
I wonder, what has failed, and should I worry about it, should I do something about it?
Update log:
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.
e:\Software\Android-SDK-Unlock\Android_v6>flash-all.bat
target reported max download size of 1073741824 bytes
sending 'bootloader' (3120 KB)...
OKAY [ 0.313s]
writing 'bootloader'...
OKAY [ 0.567s]
finished. total time: 0.880s
rebooting into bootloader...
OKAY [ 0.117s]
finished. total time: 0.117s
target reported max download size of 1073741824 bytes
sending 'radio' (45425 KB)...
OKAY [ 1.812s]
writing 'radio'...
OKAY [ 3.183s]
finished. total time: 4.995s
rebooting into bootloader...
OKAY [ 0.102s]
finished. total time: 0.102s
target reported max download size of 1073741824 bytes
archive does not contain 'boot.sig'
archive does not contain 'recovery.sig'
archive does not contain 'system.sig'
--------------------------------------------
Bootloader Version...: HHZ12k
Baseband Version.....: M8974A-2.0.50.2.27
Serial Number........: 0......................8
--------------------------------------------
checking product...
OKAY [ 0.092s]
checking version-bootloader...
OKAY [ 0.101s]
checking version-baseband...
OKAY [ 0.107s]
sending 'boot' (9156 KB)...
OKAY [ 0.541s]
writing 'boot'...
OKAY [ 0.781s]
sending 'recovery' (10016 KB)...
OKAY [ 0.603s]
writing 'recovery'...
OKAY [ 0.849s]
erasing 'system'...
OKAY [ 2.142s]
sending 'system' (1019261 KB)...
OKAY [ 37.004s]
writing 'system'...
OKAY [ 86.957s]
erasing 'userdata'...
OKAY [ 38.990s]
formatting 'userdata' partition...
Creating filesystem with parameters:
Size: 29236371456
Block size: 4096
Blocks per group: 32768
Inodes per group: 8192
Inode size: 256
Journal blocks: 32768
Label:
Blocks: 7137786
Block groups: 218
Reserved block group size: 1024
Created filesystem with 11/1785856 inodes and 156120/7137786 blocks
malloc: Not enough space
Cannot generate image.
FAILED ()
finished. total time: 170.121s
Press any key to exit...
Click to expand...
Click to collapse
I'm wondering if you didn't flash the img meant for the 64 and you have a 32GB? If it booted up and the system, bootloader, and radios are all updated, then nothing to be concerned about.
Hello
I compiled android for Volantis ( after downloading the sources from official google repo )
when trying to flash it i have this message
i added the "-S 256M" after finding it online , it didn't work without it too , i think that it doesn't flash the whole image since the image size is 1.5G .
I successfully flash the stock image though .
Code:
fastboot flash -S 256M system system.img
gives this output :
Code:
Invalid sparse file format at header magi
erasing 'system'...
OKAY [ 0.954s]
sending sparse 'system' (233172 KB)...
OKAY [ 11.755s]
writing 'system'...
(bootloader) Device State : Unlocked
OKAY [ 7.615s]
sending sparse 'system' (255959 KB)...
OKAY [ 12.817s]
writing 'system'...
(bootloader) Device State : Unlocked
OKAY [ 8.801s]
sending sparse 'system' (62570 KB)...
OKAY [ 3.364s]
writing 'system'...
(bootloader) Device State : Unlocked
OKAY [ 2.531s]
finished. total time: 47.838s
If anyone has had this problem before and knows the solution , i would be grateful
My Nexus 6P got stuck on a boot loop in the middle of a resource-intensive game. It was on the angler-opm6.171019.030.e1 firmware with a recent-ish version of Lineage OS.
In this state, I can get into the bootloader by keeping the volume down key pressed. However, I can't get into recovery from the bootloader, or do a factory reset, or do anything else. Choosing any option in the bootloader simply causes the phone to reboot.
However, while the bootloader is open, I am able to connect the phone to my computer via USB and run fastboot. At first I tried reflashing individual partitions like the bootloader, the vendor image, the recovery (TWRP) and eventually boot, in the hopes that reflashing one of them would fix the issue. Eventually, I downloaded the latest stock image from Google and reflashed the entire thing using the vendor-provided script:
Code:
fastboot flash bootloader bootloader-angler-angler-03.79.img
fastboot reboot-bootloader
sleep 5
fastboot flash radio radio-angler-angler-03.87.img
fastboot reboot-bootloader
sleep 5
fastboot -w update image-angler-opm6.171019.030.k1.zip
It was very thorough. As you can see by the mkfs, it even reformatted my storage (RIP dog pics):
Code:
$ ./flash-all.sh
Sending 'bootloader' (3552 KB) OKAY [ 0.128s]
Writing 'bootloader' OKAY [ 0.209s]
Finished. Total time: 0.366s
rebooting into bootloader OKAY [ 0.125s]
Finished. Total time: 0.126s
< waiting for any device >
Sending 'radio' (48728 KB) OKAY [ 1.303s]
Writing 'radio' OKAY [ 2.178s]
Finished. Total time: 3.512s
rebooting into bootloader OKAY [ 0.005s]
Finished. Total time: 0.006s
extracting android-info.txt (0 MB) to RAM...
--------------------------------------------
Bootloader Version...: angler-03.79
Baseband Version.....: angler-03.87
Serial Number........: 84B7N15A04004581
--------------------------------------------
Checking product OKAY [ 0.021s]
Checking version-bootloader OKAY [ 0.020s]
Checking version-baseband OKAY [ 0.020s]
extracting boot.img (11 MB) to disk... took 0.122s
archive does not contain 'boot.sig'
archive does not contain 'dtbo.img'
archive does not contain 'dt.img'
archive does not contain 'odm.img'
archive does not contain 'product.img'
extracting recovery.img (18 MB) to disk... took 0.084s
archive does not contain 'recovery.sig'
extracting system.img (1912 MB) to disk... took 11.444s
archive does not contain 'system.sig'
archive does not contain 'vbmeta.img'
extracting vendor.img (188 MB) to disk... took 1.259s
archive does not contain 'vendor.sig'
mke2fs 1.43.3 (04-Sep-2016)
Creating filesystem with 6694270 4k blocks and 1676080 inodes
Filesystem UUID: b506d1ce-64e3-40fc-a7ed-cb63d08a0704
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000
Allocating group tables: done
Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done
mke2fs 1.43.3 (04-Sep-2016)
Creating filesystem with 25600 4k blocks and 25600 inodes
Allocating group tables: done
Writing inode tables: done
Creating journal (1024 blocks): done
Writing superblocks and filesystem accounting information: done
Sending 'boot' (12089 KB) OKAY [ 0.338s]
Writing 'boot' OKAY [ 0.181s]
Sending 'recovery' (18961 KB) OKAY [ 0.510s]
Writing 'recovery' OKAY [ 0.275s]
Sending sparse 'system' 1/5 (482664 KB) OKAY [ 12.736s]
Writing sparse 'system' 1/5 OKAY [ 7.243s]
Sending sparse 'system' 2/5 (475570 KB) OKAY [ 12.729s]
Writing sparse 'system' 2/5 OKAY [ 6.745s]
Sending sparse 'system' 3/5 (474890 KB) OKAY [ 13.047s]
Writing sparse 'system' 3/5 OKAY [ 7.821s]
Sending sparse 'system' 4/5 (476548 KB) OKAY [ 12.622s]
Writing sparse 'system' 4/5 OKAY [ 6.947s]
Sending sparse 'system' 5/5 (49108 KB) OKAY [ 1.259s]
Writing sparse 'system' 5/5 OKAY [ 0.712s]
Sending 'vendor' (192565 KB) OKAY [ 5.124s]
Writing 'vendor' OKAY [ 3.262s]
Erasing 'userdata' OKAY [ 0.326s]
Sending 'userdata' (4412 KB) OKAY [ 0.163s]
Writing 'userdata' OKAY [ 0.095s]
Erasing 'cache' OKAY [ 0.024s]
Sending 'cache' (96 KB) OKAY [ 0.032s]
Writing 'cache' OKAY [ 0.030s]
Rebooting
Finished. Total time: 106.097s
Suffice to say this didn't fix the issue. The phone is still on a boot loop.
What else is there to try?
I suspect a hardware issue but I can't run any diagnostics since fastboot doesn't give me shell access.
Thanks in advance!
Bug In Rom
joeymallone said:
My Nexus 6P got stuck on a boot loop in the middle of a resource-intensive game. It was on the angler-opm6.171019.030.e1 firmware with a recent-ish version of Lineage OS.
In this state, I can get into the bootloader by keeping the volume down key pressed. However, I can't get into recovery from the bootloader, or do a factory reset, or do anything else. Choosing any option in the bootloader simply causes the phone to reboot.
However, while the bootloader is open, I am able to connect the phone to my computer via USB and run fastboot. At first I tried reflashing individual partitions like the bootloader, the vendor image, the recovery (TWRP) and eventually boot, in the hopes that reflashing one of them would fix the issue. Eventually, I downloaded the latest stock image from Google and reflashed the entire thing using the vendor-provided script:
Code:
fastboot flash bootloader bootloader-angler-angler-03.79.img
fastboot reboot-bootloader
sleep 5
fastboot flash radio radio-angler-angler-03.87.img
fastboot reboot-bootloader
sleep 5
fastboot -w update image-angler-opm6.171019.030.k1.zip
It was very thorough. As you can see by the mkfs, it even reformatted my storage (RIP dog pics):
Code:
$ ./flash-all.sh
Sending 'bootloader' (3552 KB) OKAY [ 0.128s]
Writing 'bootloader' OKAY [ 0.209s]
Finished. Total time: 0.366s
rebooting into bootloader OKAY [ 0.125s]
Finished. Total time: 0.126s
< waiting for any device >
Sending 'radio' (48728 KB) OKAY [ 1.303s]
Writing 'radio' OKAY [ 2.178s]
Finished. Total time: 3.512s
rebooting into bootloader OKAY [ 0.005s]
Finished. Total time: 0.006s
extracting android-info.txt (0 MB) to RAM...
--------------------------------------------
Bootloader Version...: angler-03.79
Baseband Version.....: angler-03.87
Serial Number........: 84B7N15A04004581
--------------------------------------------
Checking product OKAY [ 0.021s]
Checking version-bootloader OKAY [ 0.020s]
Checking version-baseband OKAY [ 0.020s]
extracting boot.img (11 MB) to disk... took 0.122s
archive does not contain 'boot.sig'
archive does not contain 'dtbo.img'
archive does not contain 'dt.img'
archive does not contain 'odm.img'
archive does not contain 'product.img'
extracting recovery.img (18 MB) to disk... took 0.084s
archive does not contain 'recovery.sig'
extracting system.img (1912 MB) to disk... took 11.444s
archive does not contain 'system.sig'
archive does not contain 'vbmeta.img'
extracting vendor.img (188 MB) to disk... took 1.259s
archive does not contain 'vendor.sig'
mke2fs 1.43.3 (04-Sep-2016)
Creating filesystem with 6694270 4k blocks and 1676080 inodes
Filesystem UUID: b506d1ce-64e3-40fc-a7ed-cb63d08a0704
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000
Allocating group tables: done
Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done
mke2fs 1.43.3 (04-Sep-2016)
Creating filesystem with 25600 4k blocks and 25600 inodes
Allocating group tables: done
Writing inode tables: done
Creating journal (1024 blocks): done
Writing superblocks and filesystem accounting information: done
Sending 'boot' (12089 KB) OKAY [ 0.338s]
Writing 'boot' OKAY [ 0.181s]
Sending 'recovery' (18961 KB) OKAY [ 0.510s]
Writing 'recovery' OKAY [ 0.275s]
Sending sparse 'system' 1/5 (482664 KB) OKAY [ 12.736s]
Writing sparse 'system' 1/5 OKAY [ 7.243s]
Sending sparse 'system' 2/5 (475570 KB) OKAY [ 12.729s]
Writing sparse 'system' 2/5 OKAY [ 6.745s]
Sending sparse 'system' 3/5 (474890 KB) OKAY [ 13.047s]
Writing sparse 'system' 3/5 OKAY [ 7.821s]
Sending sparse 'system' 4/5 (476548 KB) OKAY [ 12.622s]
Writing sparse 'system' 4/5 OKAY [ 6.947s]
Sending sparse 'system' 5/5 (49108 KB) OKAY [ 1.259s]
Writing sparse 'system' 5/5 OKAY [ 0.712s]
Sending 'vendor' (192565 KB) OKAY [ 5.124s]
Writing 'vendor' OKAY [ 3.262s]
Erasing 'userdata' OKAY [ 0.326s]
Sending 'userdata' (4412 KB) OKAY [ 0.163s]
Writing 'userdata' OKAY [ 0.095s]
Erasing 'cache' OKAY [ 0.024s]
Sending 'cache' (96 KB) OKAY [ 0.032s]
Writing 'cache' OKAY [ 0.030s]
Rebooting
Finished. Total time: 106.097s
Suffice to say this didn't fix the issue. The phone is still on a boot loop.
What else is there to try?
I suspect a hardware issue but I can't run any diagnostics since fastboot doesn't give me shell access.
Thanks in advance!
Click to expand...
Click to collapse
Hi there,
Well since it's a recent firmware there might be a slight chance that it's a bug that caused your bootloop.
I think you're better of installing another custom ROM without any bugs.
If there are BUGS do tell the developers of that ROM so they will be able to fix it.
And I am 50% sure that it might not be a Hardware Issue that you are able to connect the phone onto your PC and thus the PC recognises it. But keep trying different stock versions of that phone.
If that didn't work install a updated TWRP and then load your another custom ROM on to your SD card or use ADB and flash the ROM. See if that works.
Meant to say bootloader said recovery big difference LOL I have the same issue with Pixel experience,Lineage,omni rom there are no errors in terminal or on phone here is the output from my terminal window i just find it odd any answers would be much appreciated thanks.
fastboot flash boot /home/no/pixelimages/PixelExperience_Plus_sofiar-10.0-20
200918-0058-UNOFFICIAL/boot.img *
target reported max download size of 536870912 bytes
sending 'boot_a' (65536 KB)...
OKAY [ *1.795s]
writing 'boot_a'...
OKAY [ *0.506s]
finished. total time: 2.301s
fastboot flash system /home/no/pixelimages/PixelExperience_Plus_sofiar-10.0-
20200918-0058-UNOFFICIAL/system.img *
target reported max download size of 536870912 bytes
sending sparse 'system_a' 1/2 (524284 KB)...
OKAY [ 14.571s]
writing 'system_a' 1/2...
OKAY [ *2.775s]
sending sparse 'system_a' 2/2 (473856 KB)...
OKAY [ 12.986s]
writing 'system_a' 2/2...
OKAY [ *2.572s]
finished. total time: 32.905s
fastboot flash product /home/no/pixelimages/PixelExperience_Plus_sofiar-10.0
-20200918-0058-UNOFFICIAL/product.img *
target reported max download size of 536870912 bytes
sending sparse 'product_a' 1/3 (524284 KB)...
OKAY [ 14.380s]
writing 'product_a' 1/3...
OKAY [ *2.776s]
sending sparse 'product_a' 2/3 (524284 KB)...
OKAY [ 14.388s]
writing 'product_a' 2/3...
OKAY [ *2.841s]
sending sparse 'product_a' 3/3 (167696 KB)...
OKAY [ *4.603s]
writing 'product_a' 3/3...
OKAY [ *1.170s]
finished. total time: 40.157s
fastboot flash vbmeta /home/no/pixelimages/PixelExperience_Plus_sofiar-10.0-
20200918-0058-UNOFFICIAL/vbmeta.img *
target reported max download size of 536870912 bytes
sending 'vbmeta_a' (4 KB)...
OKAY [ *0.001s]
writing 'vbmeta_a'...
OKAY [ *0.058s]
finished. total time: 0.058s
fastboot -w
wiping userdata...
Erase successful, but not automatically formatting.
File system type raw not supported.
erasing 'userdata'...
OKAY [ *0.069s]
finished. total time: 0.069s
Weeaboodesu said:
Meant to say bootloader said recovery big difference LOL I have the same issue with Pixel experience,Lineage,omni rom there are no errors in terminal or on phone here is the output from my terminal window i just find it odd any answers would be much appreciated thanks.
fastboot flash boot /home/no/pixelimages/PixelExperience_Plus_sofiar-10.0-20
200918-0058-UNOFFICIAL/boot.img *
target reported max download size of 536870912 bytes
sending 'boot_a' (65536 KB)...
OKAY [ *1.795s]
writing 'boot_a'...
OKAY [ *0.506s]
finished. total time: 2.301s
fastboot flash system /home/no/pixelimages/PixelExperience_Plus_sofiar-10.0-
20200918-0058-UNOFFICIAL/system.img *
target reported max download size of 536870912 bytes
sending sparse 'system_a' 1/2 (524284 KB)...
OKAY [ 14.571s]
writing 'system_a' 1/2...
OKAY [ *2.775s]
sending sparse 'system_a' 2/2 (473856 KB)...
OKAY [ 12.986s]
writing 'system_a' 2/2...
OKAY [ *2.572s]
finished. total time: 32.905s
fastboot flash product /home/no/pixelimages/PixelExperience_Plus_sofiar-10.0
-20200918-0058-UNOFFICIAL/product.img *
target reported max download size of 536870912 bytes
sending sparse 'product_a' 1/3 (524284 KB)...
OKAY [ 14.380s]
writing 'product_a' 1/3...
OKAY [ *2.776s]
sending sparse 'product_a' 2/3 (524284 KB)...
OKAY [ 14.388s]
writing 'product_a' 2/3...
OKAY [ *2.841s]
sending sparse 'product_a' 3/3 (167696 KB)...
OKAY [ *4.603s]
writing 'product_a' 3/3...
OKAY [ *1.170s]
finished. total time: 40.157s
fastboot flash vbmeta /home/no/pixelimages/PixelExperience_Plus_sofiar-10.0-
20200918-0058-UNOFFICIAL/vbmeta.img *
target reported max download size of 536870912 bytes
sending 'vbmeta_a' (4 KB)...
OKAY [ *0.001s]
writing 'vbmeta_a'...
OKAY [ *0.058s]
finished. total time: 0.058s
fastboot -w
wiping userdata...
Erase successful, but not automatically formatting.
File system type raw not supported.
erasing 'userdata'...
OKAY [ *0.069s]
finished. total time: 0.069s
Click to expand...
Click to collapse
mine is doing the same thing, ever figure out what the cause is?
CorporalCactus said:
mine is doing the same thing, ever figure out what the cause is?
Click to expand...
Click to collapse
No i found a custom rom that worked keep trying roms till you find one that works havoc os worked for me and make sure you are flashing in fastbootd
I'm experimenting with a CalyxOS (13) fork, and suddenly broke booting (on a quite late stage — getting an NPE caused by my change in UserManagerService creation).
Other partitions, including boot should be fine, as I did no changes to their contents.
Device was stuck in a bootloop for ~3 reboots, then turned off and now does not react to any actions: any keys combination, holding power for about a minute or connecting a charger.
It was fully charged, and I've also tried to leave it connected to the charger for about 12 hours.
Is there some other way to enter the bootloader to flash a fixed fw?
Probably died and needs to be charged. Charge it and reflash factory firmware to both slots and wipe data using pixel flasher
ne0ns4l4m4nder said:
Probably died and needs to be charged. Charge it and reflash factory firmware to both slots and wipe data using pixel flasher
Click to expand...
Click to collapse
That's strange, because before bootloop it was fully charged, I don't think it could fully discharge in 2-3 minutes.
And I've also already tried to charge it, it doesn't react to charger even after being connected for 12 hours.
tibl37 said:
I'm experimenting with a CalyxOS (13) fork, and suddenly broke booting (on a quite late stage — getting an NPE caused by my change in UserManagerService creation).
Other partitions, including boot should be fine, as I did no changes to their contents.
Device was stuck in a bootloop for ~3 reboots, then turned off and now does not react to any actions: any keys combination, holding power for about a minute or connecting a charger.
It was fully charged, and I've also tried to leave it connected to the charger for about 12 hours.
Is there some other way to enter the bootloader to flash a fixed fw?
Click to expand...
Click to collapse
Did you have the A13 bootloader flashed to both slots? Symptoms are similar to when the new ARB bricks the Pixel 6 devices, whereby user only had the A13 bootloader on 1 slot, phone got into a bootloop, then reverted to the opposite slot which had the A12 bootloader on it, leading to a brick that so far has been unrecoverable except to RMA it.
Lughnasadh said:
Did you have the A13 bootloader flashed to both slots? Symptoms are similar to when the new ARB bricks the Pixel 6 devices, whereby user only had the A13 bootloader on 1 slot, phone got into a bootloop, then reverted to the opposite slot which had the A12 bootloader on it, leading to a brick that so far has been unrecoverable except to RMA it.
Click to expand...
Click to collapse
Hmm, looks like slot b still contained the original Android 12 bootloader
Here is the last fastboot log:
Bash:
Setting current slot to 'a' OKAY [ 0.072s]
Sending 'boot_a' (65536 KB) OKAY [ 1.749s]
Writing 'boot_a' OKAY [ 0.249s]
Sending 'dtbo_a' (16384 KB) OKAY [ 0.420s]
Writing 'dtbo_a' OKAY [ 0.063s]
Sending 'pvmfw_a' (1024 KB) OKAY [ 0.026s]
Writing 'pvmfw_a' OKAY [ 0.007s]
Sending 'vbmeta_a' (8 KB) OKAY [ 0.000s]
Writing 'vbmeta_a' OKAY [ 0.002s]
Sending 'vbmeta_system_a' (4 KB) OKAY [ 0.000s]
Writing 'vbmeta_system_a' OKAY [ 0.002s]
Sending 'vbmeta_vendor_a' (4 KB) OKAY [ 0.000s]
Writing 'vbmeta_vendor_a' OKAY [ 0.002s]
Sending 'vendor_boot_a' (65536 KB) OKAY [ 1.648s]
Writing 'vendor_boot_a' OKAY [ 0.244s]
Rebooting into fastboot OKAY [ 0.000s]
< waiting for any device >
Sending 'super' (4 KB) OKAY [ 0.001s]
Updating super partition OKAY [ 0.024s]
Resizing 'product_a' OKAY [ 0.003s]
Resizing 'system_a' OKAY [ 0.003s]
Resizing 'system_ext_a' OKAY [ 0.002s]
Resizing 'system_b' OKAY [ 0.002s]
Resizing 'vendor_a' OKAY [ 0.002s]
Resizing 'vendor_dlkm_a' OKAY [ 0.002s]
Resizing 'vendor_b' OKAY [ 0.002s]
Invalid sparse file format at header magic
Resizing 'product_a' OKAY [ 0.005s]
Sending sparse 'product_a' 1/5 (262120 KB) OKAY [ 7.131s]
Writing 'product_a' OKAY [ 1.034s]
Sending sparse 'product_a' 2/5 (262120 KB) OKAY [ 7.232s]
Writing 'product_a' OKAY [ 1.023s]
Sending sparse 'product_a' 3/5 (262120 KB) OKAY [ 7.282s]
Writing 'product_a' OKAY [ 1.095s]
Sending sparse 'product_a' 4/5 (262128 KB) OKAY [ 7.214s]
Writing 'product_a' OKAY [ 1.017s]
Sending sparse 'product_a' 5/5 (207840 KB) OKAY [ 5.494s]
Writing 'product_a' OKAY [ 0.865s]
Invalid sparse file format at header magic
Resizing 'system_a' OKAY [ 0.004s]
Sending sparse 'system_a' 1/4 (262112 KB) OKAY [ 7.134s]
Writing 'system_a' OKAY [ 1.031s]
Sending sparse 'system_a' 2/4 (262120 KB) OKAY [ 7.087s]
Writing 'system_a' OKAY [ 1.089s]
Sending sparse 'system_a' 3/4 (262140 KB) OKAY [ 7.302s]
Writing 'system_a' OKAY [ 1.002s]
Sending sparse 'system_a' 4/4 (104872 KB) OKAY [ 2.835s]
Writing 'system_a' OKAY [ 0.501s]
Invalid sparse file format at header magic
Resizing 'system_ext_a' OKAY [ 0.004s]
Sending sparse 'system_ext_a' 1/2 (262124 KB) OKAY [ 7.442s]
Writing 'system_ext_a' OKAY [ 1.075s]
Sending sparse 'system_ext_a' 2/2 (89968 KB) OKAY [ 2.581s]
Writing 'system_ext_a' OKAY [ 0.357s]
Resizing 'system_b' OKAY [ 0.003s]
Sending 'system_b' (340 KB) OKAY [ 0.010s]
Writing 'system_b' OKAY [ 0.038s]
Invalid sparse file format at header magic
Resizing 'vendor_a' OKAY [ 0.005s]
Sending sparse 'vendor_a' 1/2 (262116 KB) OKAY [ 7.207s]
Writing 'vendor_a' OKAY [ 1.103s]
Sending sparse 'vendor_a' 2/2 (254340 KB) OKAY [ 7.116s]
Writing 'vendor_a' OKAY [ 0.965s]
Resizing 'vendor_dlkm_a' OKAY [ 0.004s]
Sending 'vendor_dlkm_a' (39444 KB) OKAY [ 1.102s]
Writing 'vendor_dlkm_a' OKAY [ 0.196s]
Rebooting OKAY [ 0.001s]
Finished. Total time: 122.552s
tibl37 said:
Not sure.
Here is the last fastboot log:
Bash:
Setting current slot to 'a' OKAY [ 0.072s]
Sending 'boot_a' (65536 KB) OKAY [ 1.749s]
Writing 'boot_a' OKAY [ 0.249s]
Sending 'dtbo_a' (16384 KB) OKAY [ 0.420s]
Writing 'dtbo_a' OKAY [ 0.063s]
Sending 'pvmfw_a' (1024 KB) OKAY [ 0.026s]
Writing 'pvmfw_a' OKAY [ 0.007s]
Sending 'vbmeta_a' (8 KB) OKAY [ 0.000s]
Writing 'vbmeta_a' OKAY [ 0.002s]
Sending 'vbmeta_system_a' (4 KB) OKAY [ 0.000s]
Writing 'vbmeta_system_a' OKAY [ 0.002s]
Sending 'vbmeta_vendor_a' (4 KB) OKAY [ 0.000s]
Writing 'vbmeta_vendor_a' OKAY [ 0.002s]
Sending 'vendor_boot_a' (65536 KB) OKAY [ 1.648s]
Writing 'vendor_boot_a' OKAY [ 0.244s]
Rebooting into fastboot OKAY [ 0.000s]
< waiting for any device >
Sending 'super' (4 KB) OKAY [ 0.001s]
Updating super partition OKAY [ 0.024s]
Resizing 'product_a' OKAY [ 0.003s]
Resizing 'system_a' OKAY [ 0.003s]
Resizing 'system_ext_a' OKAY [ 0.002s]
Resizing 'system_b' OKAY [ 0.002s]
Resizing 'vendor_a' OKAY [ 0.002s]
Resizing 'vendor_dlkm_a' OKAY [ 0.002s]
Resizing 'vendor_b' OKAY [ 0.002s]
Invalid sparse file format at header magic
Resizing 'product_a' OKAY [ 0.005s]
Sending sparse 'product_a' 1/5 (262120 KB) OKAY [ 7.131s]
Writing 'product_a' OKAY [ 1.034s]
Sending sparse 'product_a' 2/5 (262120 KB) OKAY [ 7.232s]
Writing 'product_a' OKAY [ 1.023s]
Sending sparse 'product_a' 3/5 (262120 KB) OKAY [ 7.282s]
Writing 'product_a' OKAY [ 1.095s]
Sending sparse 'product_a' 4/5 (262128 KB) OKAY [ 7.214s]
Writing 'product_a' OKAY [ 1.017s]
Sending sparse 'product_a' 5/5 (207840 KB) OKAY [ 5.494s]
Writing 'product_a' OKAY [ 0.865s]
Invalid sparse file format at header magic
Resizing 'system_a' OKAY [ 0.004s]
Sending sparse 'system_a' 1/4 (262112 KB) OKAY [ 7.134s]
Writing 'system_a' OKAY [ 1.031s]
Sending sparse 'system_a' 2/4 (262120 KB) OKAY [ 7.087s]
Writing 'system_a' OKAY [ 1.089s]
Sending sparse 'system_a' 3/4 (262140 KB) OKAY [ 7.302s]
Writing 'system_a' OKAY [ 1.002s]
Sending sparse 'system_a' 4/4 (104872 KB) OKAY [ 2.835s]
Writing 'system_a' OKAY [ 0.501s]
Invalid sparse file format at header magic
Resizing 'system_ext_a' OKAY [ 0.004s]
Sending sparse 'system_ext_a' 1/2 (262124 KB) OKAY [ 7.442s]
Writing 'system_ext_a' OKAY [ 1.075s]
Sending sparse 'system_ext_a' 2/2 (89968 KB) OKAY [ 2.581s]
Writing 'system_ext_a' OKAY [ 0.357s]
Resizing 'system_b' OKAY [ 0.003s]
Sending 'system_b' (340 KB) OKAY [ 0.010s]
Writing 'system_b' OKAY [ 0.038s]
Invalid sparse file format at header magic
Resizing 'vendor_a' OKAY [ 0.005s]
Sending sparse 'vendor_a' 1/2 (262116 KB) OKAY [ 7.207s]
Writing 'vendor_a' OKAY [ 1.103s]
Sending sparse 'vendor_a' 2/2 (254340 KB) OKAY [ 7.116s]
Writing 'vendor_a' OKAY [ 0.965s]
Resizing 'vendor_dlkm_a' OKAY [ 0.004s]
Sending 'vendor_dlkm_a' (39444 KB) OKAY [ 1.102s]
Writing 'vendor_dlkm_a' OKAY [ 0.196s]
Rebooting OKAY [ 0.001s]
Finished. Total time: 122.552s
Click to expand...
Click to collapse
After initially flashing or updating to A13, whether it be a custom rom or stock firmware, did you ever flash an A13 build to the opposite (inactive) slot? Or flash the A13 bootloader to the opposite slot? Or did you ever take an OTA after updating to A13, resulting in A13 being put on the opposite slot? If not, then you likely still had the A12 bootloader on your opposite (inactive) slot.
Once updating to A13, the A13 bootloader needs to be flashed to both slots to avoid potentially bricking your device due to the new ARB. Your symptoms sound exactly the same as when users have bricked their devices because of this. They only had the A13 bootloader on one slot, got into a bootloop therefore causing the device to revert to the opposite slot which still had the A12 bootloader on it and thus bricking your device.
Android 13's anti-rollback protection has already bricked at least one Pixel 6
Some Pixel 6 users running Android 13 are stuck between a rock and a hard place with Google's anti-rollback protection.
www.androidpolice.com
Lughnasadh said:
After initially flashing or updating to A13, whether it be a custom rom or stock firmware, did you ever flash an A13 build to the opposite (inactive) slot? Or flash the A13 bootloader to the opposite slot? Or did you ever take an OTA after updating to A13, resulting in A13 being put on the opposite slot? If not, then you likely still had the A12 bootloader on your opposite (inactive) slot.
Once updating to A13, the A13 bootloader needs to be flashed to both slots to avoid potentially bricking your device due to the new ARB. Your symptoms sound exactly the same as when users have bricked their devices because of this. They only had the A13 bootloader on one slot, got into a bootloop therefore causing the device to revert to the opposite slot which still had the A12 bootloader on it and thus bricking your device.
Click to expand...
Click to collapse
I've probably upgraded to A13 OTA (not sure, because I had multiple Pixels and not sure if this one was updated OTA or by flashing with fastboot), but I'm sure that I didn't flash slot b manually.
tibl37 said:
I've probably upgraded to A13 OTA (not sure, because I had multiple Pixels and not sure if this one was updated OTA or by flashing with fastboot), but I'm sure that I didn't flash slot b manually.
Click to expand...
Click to collapse
If you didn't flash A13 to slot b manually, and you didn't take an OTA after initially updating to A13, then the likely scenario is that you bricked your device due to the anti-rollback protections implemented in the A13 bootloader because you still had the A12 bootloader (and firmware) on slot b.
All I can say is that your symptoms sound exactly like what happens when people brick their devices because of this. They get into a bootloop, phone turns off, can't turn it back on, buttons do nothing and charging does nothing. It's basically unresponsive and when connecting to the computer there might be a very short recognition, but that's it. They can't get into fastboot and the computer basically doesn't recognize the phone.
If this is indeed the case, from what I've observed, Google has been very good at replacing users devices when they have bricked their devices due to this.
@Lughnasadh I appreciate your time and effort in explaining the reason for boot failure to all of those who are experiencing hardbricks on their devices.
I'm really close to getting a good fix for our phone and probably going to open a combined forum for a combined reference on restoring the P6, P6P, P7, and P7P devices from a hard brick.
It's mainly related to a corruption of the correct memory address for bl1 resulting in the internal SOC requesting a new init_boot. If anyone can retrieve the header information for that file and possible a sparce layout for it(from any of the 4 devices) then I'll have a solution for restoring the phone for Windows, Unix, Linux, Android, and Darwin/MacOS users alike.
I bricked my P6a...well actually google took that HUGE liberty themselves! Compromised bootloader or not, I paid CASH in full for my phone. Effectively breaking my phone constitutes destruction of personal property....at $450 value, it's $50 short of being a felony iirc! Anyways...op it does sound like a 'e-fuse=blown' aka ARB brick. My was repaired under warranty but arrived back with a replaced screen w/ that peel-off screen protector and an unconnected fingerprint scanner! I was by then (15 days later) I was livid cuz my phone WAS in flawless condition. After raising all hell they broke down and sent me a NEW replacement, lol. So if ur not under warranty, take it to a local repair shop...you'll be glad u did. U can learn more about the infamous ARB 'e-fuse' in the 6a section's warning announcement post thread fwiw.
NonStickAtom785 said:
@Lughnasadh I appreciate your time and effort in explaining the reason for boot failure to all of those who are experiencing hardbricks on their devices.
I'm really close to getting a good fix for our phone and probably going to open a combined forum for a combined reference on restoring the P6, P6P, P7, and P7P devices from a hard brick.
It's mainly related to a corruption of the correct memory address for bl1 resulting in the internal SOC requesting a new init_boot. If anyone can retrieve the header information for that file and possible a sparce layout for it(from any of the 4 devices) then I'll have a solution for restoring the phone for Windows, Unix, Linux, Android, and Darwin/MacOS users alike.
Click to expand...
Click to collapse
What tools would be needed for that? I'm willing to help also even though my device isn't bricked.
I use a 6a so I sadly might not be of any use
I also have two Pixel 6 devices, one is bricked, another one is good, so if I can help somehow, ping me.
tibl37 said:
I also have two Pixel 6 devices, one is bricked, another one is good, so if I can help somehow, ping me.
Click to expand...
Click to collapse
It'd be bice if you could access the proprietary files on device. The soc uses exynos bootrom
Plz if you ever manage to get it fixed tag me. My pixel 6 is just catching dust here and I'm feeling really bad. You'd be an absolute life saver if you could find a solution.