Xeust said:

Hi! I was on the February update and was trying to update to the March update using the factory images.
While updating I was faced with sparse file too big or invalid error. Then my device was stuck at bootloader. After that, I proceeded to stupidly change my active partition from b to a. Now my device won't boot at all. Is there any way I can recover from this? Or is there a chance at all?

Boot to fastboot mode and install TWRP or any custom recovery on both slots.

Now reboot to recovery and change the active partition.

Xeust said:

Hi! I was on the February update and was trying to update to the March update using the factory images.
While updating I was faced with sparse file too big or invalid error. Then my device was stuck at bootloader. After that, I proceeded to stupidly change my active partition from b to a. Now my device won't boot at all. Is there any way I can recover from this? Or is there a chance at all?

What happens when you turn your device on? Are you able to boot to bootloader? Does the screen turn on at all?

If the file size was wrong, you were probably using the wrong file...although there's been issues with the latest Platform Tools, and bad USB cables can cause problems too.

TheMystic said:

Boot to fastboot mode and install TWRP or any custom recovery on both slots.

Now reboot to recovery and change the active partition.

V0latyle said:

TWRP isn't really relevant to A/B devices unless installing a custom ROM. If he's able to get into bootloader, TWRP isn't going to be any more help than reflashing the factory image.

In case of a bootloop, one can boot into recovery if it is installed on both slots. And from there the active partition can be changed, and this is possible only using custom recovery.

This is my understanding. I could be wrong because it's been a while since I got away from all these stuff, which are also becoming increasingly complex for no proportionate returns.

TheMystic said:

In case of a bootloop, one can boot into recovery if it is installed on both slots. And from there the active partition can be changed, and this is possible only using custom recovery.

This is my understanding. I could be wrong because it's been a while since I got away from all these stuff, which are also becoming increasingly complex for no proportionate returns.

The problem is, the recovery kernel is packaged into the boot image alongside ramdisk and the system kernel. Most A/B devices like Pixels do not have a recovery partition. TWRP does not support the compression that's used for the stock recovery as packaged, and if you flash the TWRP image to /boot, it overwrites everything else - meaning that your system will only boot to TWRP, because that's the only thing in /boot.

You could potentially live boot TWRP since this doesn't flash the boot partition, but again this is generally unnecessary and won't be of much help when you can simply reflash the original boot image

V0latyle said:

The problem is, the recovery kernel is packaged into the boot image alongside ramdisk and the system kernel. Most A/B devices like Pixels do not have a recovery partition. TWRP does not support the compression that's used for the stock recovery as packaged, and if you flash the TWRP image to /boot, it overwrites everything else - meaning that your system will only boot to TWRP, because that's the only thing in /boot.

Are all these done to enhance security or discourage custom mods? Or both?

For a short time when I had rooted my OnePlus 8T, I would flash TWRP on the inactive slot. That's because Oxygen OS would replace any custom recovery with its own recovery during boot, so this allowed me to boot into the inactive slot (which now has TWRP) and then run commands from there, so I don't have to use a PC each time.

TheMystic said:

Are all these done to enhance security or discourage custom mods? Or both?

Neither. It's just compression to reduce the amount of space the recovery kernel takes up in the boot image. If TWRP supported this compression we could potentially replace the stock recovery with TWRP. But, there isn't really much need to do this; most custom ROMs for the Pixel series just flash everything via web ADB.

TheMystic said:

For a short time when I had rooted my OnePlus 8T, I would flash TWRP on the inactive slot. That's because Oxygen OS would replace any custom recovery with its own recovery during boot, so this allowed me to boot into the inactive slot (which now has TWRP) and then run commands from there, so I don't have to use a PC each time.

That's not the case here. The boot slot cannot be changed without booting into TWRP. You could potentially install TWRP to boot_b, then set slot B as active; upon the next boot, the device will load TWRP. You could then do whatever you need to in TWRP, then set slot A as active, but you'd have no way of getting back to TWRP.

Xeust said:

Hi! I was on the February update and was trying to update to the March update using the factory images.
While updating I was faced with sparse file too big or invalid error. Then my device was stuck at bootloader. After that, I proceeded to stupidly change my active partition from b to a. Now my device won't boot at all. Is there any way I can recover from this? Or is there a chance at all?

The likely reason this occurred is because you used Platform Tools 34+. These 34 versions can't boot into fastbootd. For now you should be using Platform Tools 33.0.3.

You can't just switch slots and boot up the slot you switched to. You can only boot into the slot where the last firmware was flashed to. Therefore, when you changed your slot from b to a, you would have to flash the firmware onto slot a before it would boot into that slot.

If you can still get into the bootloader/fastboot mode, try flashing the factory image or using Android Flash Tool.

Lughnasadh said:

The likely reason this occurred is because you used Platform Tools 34+. These 34 versions can't boot into fastbootd. For now you should be using Platform Tools 33.0.3.

You can't just switch slots and boot up the slot you switched to. You can only boot into the slot where the last firmware was flashed to. Therefore, when you changed your slot from b to a, you would have to flash the firmware onto slot a before it would boot into that slot.

If you can still get into the bootloader/fastboot mode, try flashing the factory image or using Android Flash Tool.

For now its not booting at all. My pc can still detect it for a moment while I'm holding the power button but its not booting into bootloader so I can't do anything at the moment afaik.

V0latyle said:

What happens when you turn your device on? Are you able to boot to bootloader? Does the screen turn on at all?

Nope. Nothing and as I mentioned above, my pc only detects it while I hold the power button. Aside from that, its only a black screen.

Is there any way to flash the firmware or change the partition through other means that does not require bootloader/fastboot?

Xeust said:

For now its not booting at all. My pc can still detect it for a moment while I'm holding the power button but its not booting into bootloader so I can't do anything at the moment afaik.

Nope. Nothing and as I mentioned above, my pc only detects it while I hold the power button. Aside from that its only a black screen.

Ah. It sounds like the bootloader can't start, so the device is probably in QUSB mode. Unfortunately your only recourse is to have it repaired, as the files and tools you'd need to fix this are not publicly available. While it's possible to find the software (QPST/QFIL) you won't be able to find the necessary binary images to reflash your device.

Xeust said:

For now its not booting at all. My pc can still detect it for a moment while I'm holding the power button but its not booting into bootloader so I can't do anything at the moment afaik.


Nope. Nothing and as I mentioned above, my pc only detects it while I hold the power button. Aside from that its only a black screen.

There have been several people who have ended up like you after using Platform Tools 34+. None have been able to recover that I know of. The issue is known to Google (they are working on a fix). Can you confirm you were indeed using Platform Tools 34.0.0 or 34.0.1?

Lughnasadh said:

There have been several people who have ended up like you after using Platform Tools 34+. None have been able to recover that I know of. The issue is known to Google (they are working on a fix). Can you confirm you were indeed using Platform Tools 34.0.0 or 34.0.1?

Yes it was the 34.0.1

V0latyle said:

Ah. It sounds like the bootloader can't start, so the device is probably in QUSB mode. Unfortunately your only recourse is to have it repaired, as the files and tools you'd need to fix this are not publicly available. While it's possible to find the software (QPST/QFIL) you won't be able to find the necessary binary images to reflash your device.

If there's nothing I can do on my own, is it still possible to get it repaired? Or my only option is to send it back to google?

Xeust said:

Yes it was the 34.0.1

If there's nothing I can do on my own, is it still possible to get it repaired? Or my only option is to send it back to google?

If you're still under warranty, try to get repair that way. Warranty or no warranty, Google will probably refer you to a repair center like uBreakiFix.