What you're describing is highly unusual and likely due to making changes to the OS. Hardly anyone has reported this kind of issue over the many years GrapheneOS has existed. A/B updates have automatic rollback if the OS doesn't boot to the home screen. If it doesn't boot all the way, then it's automatically completely undone by the firmware and all changes to OS data are undone because the data is initially mounted in a mode which only appends to the filesystem log and doesn't persist any of the changes. The update system is very robust and can handle an update not booting automatically. It's also very unlikely for updates not to boot properly considering that they're tested on each device model before reaching Alpha and then go through both public Alpha and Beta testing before the Stable channel.
Leaving the device unlocked makes it far more likely something will go wrong and data will be lost. Disabling or revoking permissions from core system components which are not user-facing apps or making low-level changes with ADB to unsupported settings, etc. are other examples of how people can screw things up entirely on their own. If people disable something like the OS permission manager component and the OS can't boot anymore without a factory reset, that's not a bug. This is likely the kind of issue which happened to you.
We recommend against using developer options on a production device, particularly making changes with ADB. We also recommend against disabling core system components or their permissions in the Settings app via the Show system menus. Android allows users to break the OS via developer options or disabling core system components. It may not happen until after a reboot or update. We don't think the Android Settings app should allow disabling as much as it does but we didn't design that and taking away options from people in the GUI would make a lot of people angry even if it can still be done via ADB.
Not locking the device is an extremely poor security and robustness decision. It's not considered a completed GrapheneOS installation without locking.
> but honestly it shouldn't have happened to me either
It depends on what you changed. Android doesn't block power users from breaking the OS and needing a factory reset. That's not GrapheneOS specific. We did eliminate a few common ways people locked themselves out of their device like disabling the built-in keyboard if they use a different one which can then break or might not support running Before First Unlock via Direct Boot support.
You are right, it may have been a unusual bug that hardly occurs, but it definitely happened to me. I also agree that having a unlocked bootloader is a security risk (how big of security risk depends on one's thread level I would say).
I can't remember disabling any core system components, executing low level adb commands or any other unusual things which may have let to update breaking.
I think the error message that I got was the "No valid operating system found" one. Maybe the issue would have resolved itself, if I had rebooted my phone a few times more, through the A/B slot mechanic. I honestly didn't know all this in that situation and only found some vague forum posts about it.
I think it would have helped if there was a bit of official documentation about boot loops and what to do when one occurs on the graphene os website.
The experience was for me a bit off putting because I lost some personal data (shame on me for not having proper backups), but after reading these comments I might try Graphene os again.
> You are right, it may have been a unusual bug that hardly occurs, but it definitely happened to me.
This doesn't mean that it was a GrapheneOS issue.
> I also agree that having a unlocked bootloader is a security risk
It's a major reduction in security. It completely ruins the defenses against data extraction and significantly reduces security against a remote attacker persisting access. It also reduces robustness.
> I can't remember disabling any core system components, executing low level adb commands or any other unusual things which may have let to update breaking.
Based on the error message you give below, it wasn't any of those things because the error message isn't from the OS and is from before the OS boots.
> I think the error message that I got was the "No valid operating system found" one.
This is an error message from the firmware indicating that there's no OS installed on the current slot. If that happened after an update, it would have automatically rolled back. What you're describing was either caused by a firmware bug or a hardware failure. It indicates data loss on the SSD. If you had the device unlocked and modified the OS, it indicates that went wrong. It's highly unlikely that this had anything to do with an OS bug or misconfiguration.
> The experience was for me a bit off putting because I lost some personal data (shame on me for not having proper backups), but after reading these comments I might try Graphene os again.
You're describing a Pixel firmware bug or hardware failure such as SSD data loss. It could have occurred with the stock OS too. It's not really feasible that it was an OS bug. The error is from the firmware, not the OS, and if the firmware was working properly with no hardware failure involved it would roll back automatically if it had happened after an update. If it wasn't after an update, then it indicates data loss for the existing OS images.
Leaving the device unlocked makes it far more likely something will go wrong and data will be lost. Disabling or revoking permissions from core system components which are not user-facing apps or making low-level changes with ADB to unsupported settings, etc. are other examples of how people can screw things up entirely on their own. If people disable something like the OS permission manager component and the OS can't boot anymore without a factory reset, that's not a bug. This is likely the kind of issue which happened to you.
We recommend against using developer options on a production device, particularly making changes with ADB. We also recommend against disabling core system components or their permissions in the Settings app via the Show system menus. Android allows users to break the OS via developer options or disabling core system components. It may not happen until after a reboot or update. We don't think the Android Settings app should allow disabling as much as it does but we didn't design that and taking away options from people in the GUI would make a lot of people angry even if it can still be done via ADB.
Not locking the device is an extremely poor security and robustness decision. It's not considered a completed GrapheneOS installation without locking.
> but honestly it shouldn't have happened to me either
It depends on what you changed. Android doesn't block power users from breaking the OS and needing a factory reset. That's not GrapheneOS specific. We did eliminate a few common ways people locked themselves out of their device like disabling the built-in keyboard if they use a different one which can then break or might not support running Before First Unlock via Direct Boot support.