zlacker

>>moelf+(OP)
When installing graphene os I would consider very carefully if you want to relock the bootloader. In the past I have installed graphene os on my pixel 7a and a normal system update broke my system and made it unbootable. Because of the locked bootloader you can't reflash the os without wiping your data. It may be a very uncommon bug that may never happen to you, but honestly it shouldn't have happened to me either.

>>Effraf+JM
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.

>>strcat+Lk1
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.