Originally published at: Rebasing Fedora Silverblue to Kinoite – Fedora Community Blog
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.
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
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
/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
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!
The change itself was really easy and the issues I encountered were all caused by the packages I had layered above the base
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.