Moving to Fedora Silverblue/Kinoite (and the things I had to fix)

July 15-19th, 2023

I’ve been using a Linux Desktop for gaming and machine learning since 2021, but in Winter of 2022, I switched my entire life to Linux after a freak rainstorm turned my Macbook Air into a Macbook Water, and I couldn’t dry it out myself because Apple fights disassembly every step of the way. So, I moved to a Framework laptop alongside my desktop, and frankly, I’ve been pretty happy.

Why Silverblue/Kinoite?

Having played with Gentoo, Ubuntu, Arch, Yellow Dog, and Solaris, I’ve done my share of Distrohopping. But when I needed a daily driver, I ended up choosing Fedora. Fedora’s been amazing. Very stable, and with the exception of one bad kernel update which borked the graphics drivers for intel iGPUs (causing serious flickering and forcing me to roll back to an old kernel and withhold kernel updates for a few weeks), and some first-months issues with new AMD GPU models as drivers made their way into the kernel, it’s been relatively stable.

I’ve also put a lot of effort into making my system declarative, using Ansible to configure packages, symlinks, flatpaks, and more. In short, I make a policy of, rather than changing a setting or installing a package or adding a symlink, I take the time to make the Ansible/Shell code which will automatically do that same thing on a future system (or, on my other one when I get home!). This adds a bit of friction once, but it means that in the event of breakage, I can reinstall and be productive in about 2 hours, much of which is waiting on file transfers and downloads. As control-freaky as it sounds, configuring my computer scratches the same itch as Factorio, and this kind of automation brings me joy.

But I remain haunted, both by this weird kernel display issue which I was lucky to run into at home, rather than between classes, and by my past daily-driving Gentoo where a random kernel update would mean I no longer had a mouse. Considering I make my living and do my work on a computer, I’ve wanted a system which is stable, where I could roll back if there was a problem. I also wanted a system where updates were regular and automatic, because no system is truly secure, but I want to do my best. I also don’t mind Flatpaks and enjoy distrobox, and I’m privileged enough to run on nice hardware, so the overhead from a bit of virtualization isn’t a particular problem.

Sidebar: Why not NixOS?

Given that I like very much the idea of a reproducible and declarative computer system, where I have a configuration (ideally as a file) of settings, programs, and file links, NixOS was immediately appealing to me. The idea of having one central config file, which I could modify, then use on another machine to immediately be back to where I need to be, was lovely. Although I currently use Ansible to declare many elements of my system, it’s always a bit ‘robot pulling the levers’ hacky, with poor support for many system configuration actions, so the idea of that declarative configuration being ‘baked in’ and containing literally every setting was super appealing, as is the idea of easy container creation to isolate (e.g.) one python environment from another. So, I installed NixOS on another drive and gave it a try.

Ultimately, I was a bit disappointed. The configuration language isn’t particularly pleasant to work with, the packages were a bit out of date, there were some holes in the repos in terms of packages I use, but most of all, I didn’t find that it quite delivered on the promise of declarativity. It’s amazing for repo-installed packages, but somehow, it seemed to have no built-in mechanism for Flatpak management, and much of what I do in my userspace ended up relegated to home-manager. Ultimately, it felt that for my particular use case, I wasn’t actually so far off from what NixOS was doing by just using Ansible heavily in Fedora, and I’d rather work on a better-supported distro if I’m getting a similar experience. So, I wound up feeling like NixOS is really cool, and it (or something like it) may be the future of Linux, but it’s not the present of linux.

Choosing Kinoite

So, in an effort to get both the stability I crave, the rollbacks and automatic updates I’d like, and to keep using a system which has worked quite well for me, I decided to move to the Immutable Fedora Silverblue distribution (or in my case, as a KDE user, ‘Kinoite’). I also chose to use Distrobox rather than the baked in Toolbox, because it’s a cross-distribution thing, and because I like the idea of grabbing a package from the Ubuntu or Arch (btw) repos if I needed it.

I won’t say it’s been super easy to switch my life to Kinoite (probably around 20 hours of work across my desktop and laptop getting everything dialed in and coming up with the relevant ansible scripts to make it happen, with getting some CLI workflows taking some time and troubleshooting), but I’ve managed, and as a public service, I wanted to explain in full view of Google how I addressed some of the problems which have come up (which I spent a bunch of time googling).

I make no guarantees that these are the right solutions, just that they worked for me on July 14-16th, 2023. If you have a better solution, please let me know by shooting me an an email and I’ll happily update the page.

Things that were just fine

rocm and AMD’s Machine Learning toolchain

I use an AMD GPU for machine learning. This is patently incorrect given the ubiquity of CUDA, but Nvidia is awful on linux, to linux, and for linux, and I can’t give them money at this point in my life. By and large, everything’s harder, but most things are possible, and their toolchain is sucking less, regularly. But I was terrified this workflow would snap in half in Silverblue/Kinoite.

Weirdly, though, everything just worked fine. I have a Fedora data science distrobox container which has rocm-opencl and rocm-runtime installed, and it ‘just works.’ I was able to install StableDiffusion, KoboldAI, and work on jupyter notebooks which presume working rocm, and it just works. Weird.

Framework Laptops

Every single thing works fine on Fedora Kinoite on a 13th Gen Framework 13 laptop, including wifi, suspend, the Ethernet expansion card, and more.

Damn, I love Framework.

OpenConnect

I use OpenConnect to connect to my work VPN, because Cisco VPN software doesn’t deserve root access. Turns out, OpenConnect is included with Kinoite, and just works.

restic

restic is an amazing backup program. Installed in a distrobox, it works great, and backs up everything you’d need. The only downside I’ve found is that it uses the distrobox’s hostname (e.g. fedorabox.mycomputer) rather than the system hostname, which is weird if you’re using hostnames to distinguish the sources of backups. But the end result is the same.

pandoc

Pandoc is perfectly happy in a distrobox, and works fine exported to the host system using something like:

distrobox-export --bin /usr/bin/pandoc --export-path $HOME/Documents/bin/distrobin --export-path $HOME/.local/bin

LaTeX

LaTeX is also quite content in a distrobox. Just install texlive-scheme-full and texlive and everything works fine, just export xelatex and bibtex and anything else you need as above.

Things that needed Tweaks

ansible

My computer and Distroboxes are largely configured through ansible, which works fine when layered in Kinoite. You just need to switch the dnf entries to rpm-ostree entries for layering system packages. Installing rpm-fusion repos in Silverblue/Kinoite does seem busted for now, though, so, I’ve had to manually:

sudo rpm-ostree install https://mirrors.rpmfusion.org/free/fedora/rpmfusion-free-release-$(rpm -E %fedora).noarch.rpm https://mirrors.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-$(rpm -E %fedora).noarch.rpm

Additionally, to install all the flatpaks I wanted, I needed to add method and remote to my flatpak task, and make sure that the flatpack section is not under become: true (e.g. installing flatpaks as root is unreliable in Silverblue/Kinoite).

- name: Add flathub repo
  flatpak_remote:
    name: flathub
    state: present
    flatpakrepo_url: https://dl.flathub.org/repo/flathub.flatpakrepo
    method: user
- name: Install Flatpaks via community.general
  community.general.flatpak:
    name:
      - org.audacityteam.Audacity
[...]
      - com.github.xournalpp.xournalpp
    state: present
    method: user
    remote: flathub

Finally, changing my shell (e.g. to zsh) no longer works in ansible, and I had to edit /etc/passwd instead. In short, Ansible works fine, but it doesn’t work quite as cleanly, and feels a bit less polished in the rpm-ostree space.

Chrome Persistent Web apps

There’s one persistent web app I was using via Google Chrome. I’ve actually since removed that from my life, but I wanted to see if I could get it working anyways. Chrome was previously installed as an RPM, and when I moved Chrome to a Flatpak, I needed to:

flatpak override --user --filesystem=~/.local/share/applications --filesystem=~/.local/share/icons com.google.Chrome

In order for it to be able to create a Desktop shortcut for PWAs, otherwise I’d have to launch it from within Chrome.

Steam

Steam as a Flatpak doesn’t see external drive contents by default, and I keep my steam games library on a second SSD (named, aptly, ‘steam’). So I needed to:

flatpak override --user --filesystem=/run/media/USERNAME/steam com.valvesoftware.Steam

The other Flatpak Steam issue that I haven’t been able to resolve is creating Desktop files for the installed games. Steam isn’t ‘officially’ a Flatpak yet, so the method for creating them isn’t particularly robust, and even with the right permissions (like with Chrome, above), it generates files which expect a non-Flatpak steam.

keyd

I use keyd to remap ‘Capslock’ to Shift+Ctrl+Alt+Meta, or, when tapped, to ‘escape’. This enables a large series of cursed keyboard shortcuts which I use to navigate my computer (e.g. CapLock+T opens a terminal, CapsLock+H moves the current tiled window left…). To set up keyd on Kinoite, I…

• Downloaded the repo for the keyd copr (as it’s not available in Fedora’s repos yet) into /etc/yum-repos-d
• Installed the rpm (sudo rpm-ostree install)
• Set up /etc/keyd

… and it worked!

isync/mbsync/neomutt

I use mbsync and neomutt to quickly read email and get notifications about incoming messages.

Although you’d think these would work fine in Distrobox, turns out both have major issues when run as distrobox, so I had to layer both isync and neomutt. For mbsync, everything worked almost fine, except oauth2 authentication, where a working configuration in normal Fedora failed in Kinoite with:

IMAP error: selected SASL mechanism(s) not available;
   selected: XOAUTH2
   available: EXTERNAL LOGIN

Despite a bit of troubleshooting, I could never make it work in a Distrobox, but once layered, it works great. Frustrating, but not the end of the world.

neomutt is fine for reading messages installed in a Distrobox, but would kick odd errors when trying to reply, so I layered it, and everything was fine.

Espanso

Espanso is great, but the fact that it’s packaged as an AppImage makes things a bit janky when it wants to install itself in non-Silverblue places. So, to install it on Kinoite, I had to not follow the instructions on the site, and instead register it as a user service:

chmod u+x ~/Documents/bin/bin/Espanso.AppImage
./Espanso.AppImage service register
systemctl --user enable espanso

Works perfectly fine now, albeit only in X11. Espanso is one of my last holdouts keeping me from moving to Wayland, so I hope the coming revisions to Wayland make Espanso (or similar) easier to implement there.

Fixing Distrobox Shell Choice Errors

One frustration is that, since chsh isn’t a thing in Silverblue/Kinoite, Distrobox would always start with the wrong shell (bash rather than zsh). After wrestling with it for too long, I realized that I was massively overthinking, and changed my shell in Distrobox just as one changes it in Silverblue/Kinoite: By opening a terminal and…

sudo vim /etc/passwd

… and then changing the shell for my user to /bin/zsh. That took me too long to figure out, and is proof that a Ph.D is not particularly diagnostic of smarts.

Mullvad VPN

Mullvad is a great, privacy-conscious VPN Provider, which is really useful for when you’re on the road or don’t trust the coffee shop wifi. I was very concerned at first that getting a VPN running in Kinoite would be tough, but it turned out to be easy. First, Download the RPM. Then sudo rpm-ostree install /path/to/mullvad.rpm. Then reboot, because you’ve layered a package, and then…

sudo systemctl enable --now mullvad-daemon

Then it ‘just works’, including the GUI.

1password

Although Flatpak browsers don’t allow the browser to unlock using the System 1Password instance, and there’s no official 1Password flatpak (yet), the browser extensions work fine in Brave, Chrome, and Chromium. Really, I don’t need the main app, but do prefer that interface to using the Browser extension for editing multiple entries, etc.

Well, it turns out 1password runs fine in a Distrobox. So, just open up a Distrobox set for Fedora, then follow the ‘CentOS, Fedora or RHEL’ instructions here and install 1password. Then you can distrobox-export --app 1password and it’s working on your main system

Update: As of November, 2023, 1Password now ships a 1st party Flatpak, albeit through their own repo, which works great. Thanks, 1Password! Note, though, that using the Flatpak version currently prevents 1password from unlocking all browsers’ extensions.

kitty

I kept getting odd errors about 'xterm-kitty': unknown terminal type. in Distroboxen and elsewhere. Turns out layering and installing kitty-terminfo cured what ailed me.

cmus

I use cmus to listen to local music files, because it’s fast and great. But, it turns out, if you run it in a Distrobox, it doesn’t work with cmus-remote commands, and oddly, keeps playing when you close the terminal window without a way to reconnect to it. So, I ended up layering it and running it in the system terminal.

Changing the KDE Wallpaper and Lockscreen from the CLI

I have some scripts which generate line-art from text, and then set it automatically as a wallpaper. Previously, I was using a (very) messy dbus-send command to change the wallpaper. But Kinoite broke some important parts of dbus-send. Luckly, it turns out there’s an easier approach:

### Change the desktop wallpaper
plasma-apply-wallpaperimage `realpath /path/to/wallpaper.png`

### Change the lockscreen wallpaper
kwriteconfig5 --file kscreenlockerrc --group Greeter --group Wallpaper --group org.kde.image --group General --key Image "file:///path/to/lockscreenwallpaper.png"

These both work fine on Kinoite, and are nicer commands to boot!

Getting ‘Release Notes’ and changed packages for Silverblue/Kinoite upgrades

When you have automatic updates enabled, you’ll find that periodically, your computer has staged the latest upgrade for you automatically, such that next time you reboot, you’ll boot into the upgraded system. You can tell this by running:

rpm-ostree status

But particularly if you’re waiting for a particular (e.g.) kernel, you might be curious about what the staged update changes. Turns out that the answer is deceptively simple, you just need a ‘verbose’ flag:

rpm-ostree status -v

Then you’ll get a full list of what’s changed.

Things that didn’t work

resilio-sync

One initial blocker for me moving to Silverblue/kinoite was the lack of resilio-sync available in the repositories to layer, and the pain of adding their repo. Plus, setting everything up was unpleasant, and it just fought me every step.

Well, it turns out that syncthing is now almost up to feature parity (just missing ‘selective sync’), and is massively easier to set up on Linux. I switched my life to syncthing, and it’s just better. So, the solution to using resilio-sync on Silverblue/Kinoite is ‘don’t’. I’m sure there’s a way to get it running, but I’m glad I didn’t.

All content © Copyright 2011-2024 Will Styler unless otherwise licensed. Please contact for relicensing.