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.
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.
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.
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.
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.
This has happened to me when the battery ran out during the reboot/upgrade. One time I had to let it charge and reboot for a good 30 minutes and eventually it booted again.
I totally understand giving up there though as it sucks to not be able to use the phone for a while and is very inconvenient. Let alone if this happens at an inconvenient time/during a work day, etc.
I have used FreeTube on wayland now for a long time without any issues. Electron still uses x11 as the default on wayland so you need to enable the wayland mode manually. You can easily do that by setting the ELECTRON_OZONE_PLATFORM_HINT=auto
environment variable.
Thanks, that fixed the resolution issue! I also had to give it access to the dbus system socket and wayland for it to work. Wasn't sure how to do that but the flatseal app made it easy.