Some time ago I was thinking if it’s possible to rebase my ostree system from one to another and how difficult this is. After some thinking I decided to try it by rebasing Fedora 35 Silverblue on my gaming machine to Fedora 35 Kinoite. In this post I will write what I did and what difficulties I had along the road.

DISCLAIMER: This is not something that is supported by the Fedora KDE SIG so do it at your own risk.

Choosing the correct rebase target

First thing I needed to do is find the correct rebase target on Fedora 35 Silverblue.

$ostree remote refs fedora

I checked for the potential candidate and found the correct Kinoite entry.

fedora:fedora/35/x86_64/updates/kinoite

There are other options for Kinoite for different architectures or older versions of Fedora. You can even try to rebase to Fedora Core OS if you want. 🙂

Rebasing the Silverblue to Kinoite

Rebase itself is similar to update to a new version of Fedora Silverblue. You just need to run the following:

$ rpm-ostree rebase fedora:fedora/35/x86_64/kinoite

And then reboot the machine.

I ended up in broken GNOME

So after reboot I was welcomed by kdm (KDE Display Manager) and logged in, but instead KDE I found out I’m in broken GNOME, which doesn’t work as it should. At the first sight I thought something went wrong during the rebase. But this was not the case. I checked the state of the rpm-ostree

$ rpm-ostree status

And I noticed that one of the layered packages I had for Silverblue is gnome-shell-extension-appindicator for tray icons in GNOME.

So I decided to remove it.

$ rpm-ostree uninstall gnome-shell-extension-appindicator

And rebooted.

After reboot I found out that the KDE is working fine. It looks like when layered package was applied above the ostree image it also added all the required GNOME dependencies, which broke the KDE.

But this wasn’t the end of it.

The flatpaks couldn’t be found in KDE

When looking for installed flatpaks using the search option from menu in panel I wasn’t able to find them. I was wondering why, so I started searching for this. After some search I came across this issue in flatpak: XDG_DATA_DIRS is not set on fish shell (at the time of writing this blog post this is already solved).

As you can probably guess by now I have fish layered above the base ostree image. For those who don’t know what fish is. It’s a really nice alternative to standard bash shell, so I like to have it. If you find to know out more about fish, I can point you to official page.

So why is this happening?

From what I was able to found out is that gdm (GNOME Display Manager) is doing the initialization of the desktop in bash and then switching to user defined shell. So everything applied in the initialization phase, like /etc/profile.d/ profiles, which is where the flatpaks directories are registered in the desktop, is run in bash. In kdm /etc/profile.d/ profiles are applied using the logged in user default shell and this didn’t work in fish, because the syntax is slightly different and the fish needs to have it’s own profile file.

What I did?

To fix this issue, I changed my default shell to bash from fish using lchsh command, but to not lose the fish as a main shell, I set it as a default shell for tmux session. After this change the flatpak integration started working correctly!

Conclusion

The change itself was really easy and the issues I encountered were all caused by the packages I had layered above the base ostree image.

I’m still getting used to KDE, but it’s a nice experience. Just some struggle with multi-monitor setup, but multi-monitor setup is always struggle on any desktop environment.