Question How to un-brick Pixel 6? - Google Pixel 6

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.