[EffrafaxOfWug]

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.

[codethief]

I've been using GrapheneOS since the Pixel 3a and this is the first time I'm hearing of such an issue. To me, the ability to relock the bootloader and rely on verified boot is a big security advantage compared to other custom ROMs. I would not want to give that up lightly.

[gradeless]

Ive been using GrapheneOS for years and was in the chat rooms a fair bit, this isnt something common. Sounds like it may be hardware failing.

Having bootloader locked you get verified boot, big security benefits and automatic healing of operating system files damaged by the drive degrading.

[strcat]

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.

[EffrafaxOfWug]

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.

[sureglymop]

I'd be interested in more specifics here. I've been in a few bootloops with GrapheneOS early on but I've always been able to get out of them by keeping cool and not prematurely trying to reflash and wipe. Eventually the phone always booted (I think that it's due to the A/B partition system where eventually the phone will try to boot the other "working" partition again. But sometimes this would take a while).

It hasn't happened in a year though and I've been happily upgrading lately. I'm not saying you couldn't have run into a unique bug but I'd find it surprising if your phone was really left completely bricked except for reflashing/wiping it.

[EffrafaxOfWug]

It was some time ago, so I unfortunately can't remember all the details. It occured during a normal system update that ran without problems at first, but when I rebooted the phone to finish the update it couldn't boot anymore (I can't remember the error messages). I don't know what exactly went wrong or was corrupted during the update. I definetly rebooted the phone multiple times and tried to fix the issue, but after some time I realized it was futile.

Maybe there still was a way to salvage it, but I really can't tell in hindsight.