Skip to content

Up and Running on Fedora Silverblue

I’ve been thinking about making the move to Fedora Silverblue since at least 2020, and this summer I finally went ahead with the change.

To grossly oversimplify, the Silverblue approach is to make the entire operating system immutable – there is nothing the user, an application, or malware can do to edit most of the system files. As the project’s site describes,

This means that every installation is identical to every other installation of the same version. The operating system that is on disk is exactly the same from one machine to the next, and it never changes as it is used.
About Silverblue

That isn’t to say it is permanent and can’t be updated, of course. Just, instead of dnf as a package manager, updates come in waves of changes from the rpm-ostree. When updating, the old version remains available – so if something has broken in the update (it hasn’t happened for me so far, of course) you can immediately roll back to the previous installation. Applications can be installed in flatpaks, run in the toolbox (a container environment that allows dnf packaging), or – ideally as sparingly as possible – added to the rpm-ostree as additional layers on top of the core.

I didn’t intend for this to be a complete summary of Silverblue, there are much more thorough treatments:

But I did want to share a few resources that were very helpful in fleshing out my initial installation:

And some of my thoughts as a new Silverblue user so far:

  • A lot of people online warn that “you’ll need to reboot a lot”, but I don’t find myself rebooting that much more than I used to on Fedora workstation. Sure, maybe I update my rpm-dependent packages a little less often, but I still try to keep a fairly up to date system. In practice, this has meant rebooting a few times a week vs maybe once a week on traditional Fedora.
  • Flatpaks still cause issues. Generally they’re fine, but some libraries that are typically available (for instance, foreign language character support, theming, etc) do not work without significant tweaking. Flatseal, recommended by one of the guide, is helpful in modifying flatpak permissions in a GUI way, but still trying to implement certain things require significant trial and error.
  • It’s easy to see whether you’re in a Toolbox or not when working on the CLI, but it’s difficult sometimes to figure out which toolbox you are in. I tried to segment certain toolboxes. I currently have 3 toolboxes – my default one, one focused on ruby dependencies and programming, and a third to host a certain seldom-used application which requires tons of ugly dependencies I didn’t want to bundle into my default toolbox. I have occasionally run into issues where I thought I was in the ruby box, but I wasn’t. It would be nice if it said which toolbox you were in, ie having the command prompt show user@ruby (where ruby is the name of the toolbox – which is tracked by podman) instead of just user@toolbox for each, which is the current behavior.

Overall, the switch to Silverblue hasn’t caused a great amount of difficulty or change of workflow, is fast and stable (no SELinux alerts so far – which I got occasionally on workstation), and makes me feel more confident that if something causes an issue, I can easily and painlessly roll back to a previous stable system. I don’t know that I would recommend Silverblue yet to a non-curious generic computer user, but I think your average Linux desktop user is curious enough and inclined enough to tinker with their system to find Silverblue usable, interesting, and stable.

Published inTechnology

Be First to Comment

Leave a Reply