Newly flashed GrapheneOS. Should I be worried about the anti-rollback bug?

hemingway

Hi,
I newly flashed a Pixel 8 Pro with a Dec 2025 stable release of GrapheneOS for the husky without issue. While reading up on configuring the device, I ran into some reports of hard bricks seemingly due to this bug (quote from google):

Warning: The May 2025 update for Pixel 6 (6, 6 Pro, 6a) and Pixel 8 (8, 8 Pro, 8a) devices contains a bootloader update that increments the anti-roll back version for the bootloader. This prevents the device from rolling back to previous vulnerable versions of the bootloader. After flashing the May 2025 update on these devices you won't be able to flash and boot older Android 15 builds.

After taking an May 2025 update and successfully booting the device post update, an Android 15 build resides in the inactive slot (seamless updates for more information on slots) of the device. The inactive slot contains an older bootloader whose anti-rollback version has not been incremented. If the active slot is then flashed with a build that fails to boot, the fallback mechanism of seamless updates kicks in and the device tries to boot from the inactive slot. Since the inactive slot contains the older bootloader, the device enters an unbootable state.

To avoid hitting this state, if you are flashing an impacted Pixel device with the May 2025 update or newer for the first time, flash the bootloader partition to the inactive slot after successfully updating and booting into Android 15 May 2025 at least once. This can be done by following these steps:

After a successful boot into Android 15 May 2025 for the first time, sideload the full OTA image corresponding to that build and reboot the device to ensure that both slots have a bootable image.

My phone before the GOS flash iirc had firmware dated 2023. A quick glance at the GOS flash-all bat script I used, I did see some slot count and mismatch checks but not anything regarding changing the slot for a bootloader (re)flash.

Since I'm very new to the device and would like to avoid a hard brick acenario, how would I go about flashing the bootloader to the other slot (if indeed that's something I should do)?

de0u

hemingway A quick glance at the GOS flash-all bat script I used, I did see some slot count and mismatch checks but not anything regarding changing the slot for a bootloader (re)flash.

In the flash-all.bat script from an installer zip I pulled some time ago, I see various invocations of fastboot --set-active=other and fastboot flash --slot=other ... ...img. I believe I see two flashes of each image component, with a slot swap between. Does the flash-all.bat that you have not contain two flashes of each image component?

I believe that both the web installer and the official GrapheneOS command-line installation instructions result in both slots being fully flashed.

monogram

hemingway I believe the Web Installer already takes care of this, but if you want to be extra safe, just reboot into recovery - not bootloader - and sideload the latest OTA update zip once again.

Oggyo

hemingway
Seems related, discussed here - https://discuss.grapheneos.org/d/28369-wished-i-knew-leaving-bootloader-unlocked-risked-brickinga-warning

hemingway

de0u

You're right - flashing bootloader in both slots is infact implemented in the flash all script I used. Must have missed it.

But on further reading, it appears that on pixel 6 and 8 devices, the reported slot 'identity' is inconsistent between reboots and there is no way of knowing if you're actually flashing to slot a or b. A lot of mentions of hard bricked pixels when performing ota updates on vanilla pixel itself, users aware of the issue still ending up with bricks, google refusing to release software required to unbrick such devices, etc.

The general consensus appears to be to sideload anything touching the bootloader twice. It's been a while since I've rooted phones and with the threat of hard brick I'd love to have some more concrete steps on how to go about this with confidence.

hemingway

monogram

I used the cli install method since it seemed far less complicated. I need a refresher on sideloading. So recovery has an option for sideloading or do I use adb? And I point to the same zip I used for the successful cli install?

de0u

hemingway But on further reading, it appears that on pixel 6 and 8 devices, the reported slot 'identity' is inconsistent between reboots and there is no way of knowing if you're actually flashing to slot a or b. A lot of mentions of hard bricked pixels when performing ota updates on vanilla pixel itself, users aware of the issue still ending up with bricks, google refusing to release software required to unbrick such devices, etc.

I don't think I'm aware of reports of users running the GrapheneOS web installer, or following the GrapheneOS command-line instructions, or running the GrapheneOS automatic system updater, experiencing device bricking due to bootloader rollback protection.

hemingway The general consensus appears to be to sideload anything touching the bootloader twice. It's been a while since I've rooted phones and with the threat of hard brick I'd love to have some more concrete steps on how to go about this with confidence.

This forum isn't focused on support for rooting GrapheneOS, mixing and matching bootloader versions, etc. I believe that sort of content is more prevalent on XDA.

hemingway

de0u This forum isn't focused on support for rooting GrapheneOS

hemingway It's been a while since I've rooted phones

In this case, "rooting phones" is clearly used to indicate (outdated) flashing/fastboot/adb/recovery experience.

de0u mixing and matching bootloader versions

If the hard brick issue can affect stock pixel phones performing a normal update within the OS, it stands to reason that GOS is not immune. If mixing and matching bootloader versions is what is required to prevent a hard brick on a pixel running GOS, it should be within the scope of this forum.

Of course the lack of clarity (to me) on how the rollback feature actually causes hard bricks and whether it pertains to GOS makes it hard to determine whether it is something to be concerned about (every article I read on the issue appears to be written by someone going through early dementia). Would be nice if one could check the bootloader version installed in each slot...

monogram

hemingway Yes, you can follow the instructions here.

hemingway

monogram

Thank you!

hemingway

Oggyo

Thanks! Kinda sad that everyone took turns taking a dump on the user before the thread was locked. To me the fault lies with google for creating a hard brick scenario and pushing the imperative to flashing related forums and activities (including GOS) to appropriately warn users.

de0u

hemingway If the hard brick issue can affect stock pixel phones performing a normal update within the OS, it stands to reason that GOS is not immune.

I have not analyzed reports of device bricking for users running the stock OS, let alone tried to differentiate between bricking due to bootloader anti-rollback versus other ways that devices can get bricked during an update. OS updates involve large amounts of writing to flash storage, which can cause a marginal device to go bad. Overall, sending an OTA update to millions of devices may well result in some of them bricking due to the content of the update, some bricking in the course of the update, and also some just happening to brick that day. Also, since reports live a long time on the Internet, a report of a Pixel 4 breaking due to a problem with bootloader anti-rollback involving some bootloader bug that is no longer shipped might be 100% true but 0% relevant today.

I am not trying to suggest that GrapheneOS mathematically can't run into a problem with bootloader anti-rollback. What I wrote was "I don't think I'm aware of reports of users running the GrapheneOS web installer, or following the GrapheneOS command-line instructions, or running the GrapheneOS automatic system updater, experiencing device bricking due to bootloader rollback protection". But this is a pretty energetic forum, so if somebody is aware of such an event I expect a post will appear.

hemingway

de0u Pixel 4 ... 0% relevant today.

afaict the issue primarily affects pixel 6 and 8 devices. One of the hard brick scenarios iirc was reported by a user with a pixel 8a running stock.

de0u GrapheneOS mathematically can't run into a problem with bootloader anti-rollback

There's one instance linked above.

Yes the user "didn't do things the right way". But from my pov, if a hard brick is possible due to a manufacturer failure (google), I'm better off understanding the scope of the issue if I am to avoid it.

dc32f0cfe84def651e0e

I'm wondering why does this ~~bug~~ feature brick the device instead of just refusing to boot? That's very hostile.

hemingway

dc32f0cfe84def651e0e I'm wondering why does this bug feature brick the device instead of just refusing to boot? That's very hostile.

So from what I've gathered, how the anti rollback feature is supposed to work - it flashes the bootloader to the secondary slot, and if the phone bootloops later, it deletes the snapshot/configuration changes and reverts to the old config on the primary slot. If there's no bootloop, it merges the changes to the primary slot.

But for some reason, when implemented on Pixels 6/8, the potential for a hard brick rises radically and the phone enters some kind of emergency recovery mode where it's detected if connected to the OS, but you can't power on, fastboot, use recovery or anything. I'm not finding any concrete reason for why this occurs, but it is clearly related to which slot is flashed, when and how.

Apparently google have decided that they can make bank whether or not they address the issue and can afford to give the finger to affected users instead of make public their recovery mode tools for restoring these 'hard' bricked phones to working condition.

monogram

hemingway Yes the user "didn't do things the right way". But from my pov, if a hard brick is possible due to a manufacturer failure (google), I'm better off understanding the scope of the issue if I am to avoid it.

That's understandable to me, I also took extra precautions prior to flashing GOS to a new Pixel 8 (which I then returned) on stock Android 14: I sideloaded stock Android 16 twice in a row.

hemingway

monogram

Just to clarify, sideloading twice to ensure it installs to both slots?

monogram

hemingway Just to clarify, sideloading twice to ensure it installs to both slots?

Yes, exactly.
First sideload, reboot system, reboot recovery again, second sideload.