Possible to install Kinoite over Silberblue while keeping HOME?

Hi there,

I am thinking about trying Kinoite instead of Silverblue, mainly because I really dislike GNOME’s decision to use Mutter and its boneheaded inconfigurability (e.g. there’s no working utility akin to xrandr and xinput for Mutter).

I’ve seen that some users report issues when rebasing from Silverblue to Kinoite, so I thought about reinstalling Kinoite somehow right over Silverblue’s system while keeping HOME intact. Is this possible? How would I go about doing it? Maybe selecting something during install…?

Full format and install is more-or-less out of the question because of the way things are set up right now, especially regarding luks.

I have rebased Kinoite over Silverblue. But was testing to see if homed worked in Kinoite. To me everything worked, but then again I don’t really use Plasma to notice what works like it supposed too.

Upond first login, I did notice it installs many files into the home directory which will not be reversible with a rollback . It also alters the gsettings to make it compatible to Plasma. If you do not want your home directory altered, you should create a new user before rebasing to login to for your testing…

If you decide to rebase back to GNOME, and didn’t create a spare user, you will have to manually remove all the files and folders installed by KDE and reset the gesttings to reach it’s near default.

Both desktops have their default settings. Mixing both is properly why people are having problems.

I guess this mixing shows that the promises of ostree based variants have not fully materialized yet. (To be clear: I think it’s a great direction to go into.)
The linked article mentions one problem: if “part of your desktop environment” (the bigger part) is in your rpm-ostree and another part is in a flatpak system or user install then there is no complete rollback.
As you mentioned here, Gnome and KDE apparantly influence each other’s user settings. That is unfortunate and won’t be solved either way.
If you use apps from toolboxes or distroboxes they will write to a user’s settings, too. Different versions from different boxes may write conflicting settings.
In short, the separation simply isn’t there yet.

Maybe we should restrict the ostree install to the actual OS, and have DEs and apps in carefully curated containers? (toolbox/distrobox are podman with basically all isolation removed)

This should be just fixed by the desktop environments, there’s no reason for them to stomp on each other’s settings anyway.

I think if desktop environment contributors understood how much easier it is for everyone to try their desktop this way then those issues would get attention. It’s such a cool way to do it, perhaps we can find someone with expertise in both GNOME and KDE and see if there’s any low hanging fruit there …

Sorry for the delay.

So basically, I should create a new user before I rebase. This new user would be dedicated to Kinoite. Then, when I rebase I should login into the new user, and avoid touching the GNOME-dedicated user at all while under KDE – and avoid touching KDE-dedicated one under GNOME, if I rebase back to GNOME.

By doing this I should be fine with no issues? Would there be any conflicts with layered packages through ostree?

Also, is there a way to access (some) files from GNOME-dedicated user’s HOME directory in Kinoite? Would symlinks work in such a case (to avoid making copies of the required files and dirs)?

Final question, is there a way to access distrobox/toolbox images from Kinoite? Would a simple copy/symlink suffice?


  • A

My home folder still has Plasma files on it. I just reset the settings like so

gsettings reset-recursively org.gnome.desktop.interface

gsettings reset-recursively org.gnome.desktop.wm.preferences

I just mentioned the clutter in case you like a tidy home. You can copy any directory/files over to the next user. Toolboxes? I wouldn’t try copying it over unless you understand how containers work.

Question for the inconfigurability piece of this, did you happen to look into Wayland’s version of tools? I haven’t had to use any of these so I don’t know if they work for your use case, but am genuinely curious if they might or you already checked them out and they didn’t. From what I can find it seems like wlr-randr might be what you were looking for in GNOME.

Rich, thanks, appreciate the reply.

Just one final question: what about Flatpaks? If I rebase and work under the same user, would Flatpaks be automatically recognised by the system? Were they in your case?


  • A

Hi Matthew,

I know about wlr-randr and some other tools, as I did a semi-extensive research while trying to make it work. Originally, the issue was that I had an external touchscreen, whose touch input GNOME/mutter got mapped erroneously onto the main laptop screen. Nothing helped except going back to X11 and using xrandr/xinput.

Unfortunately, none of these tools are compatible with mutter, which is where my frustration with GNOME stems from.

Additionally, I got acquainted with KDE Plasma’s detailed customisability, including the ability to make it look and function very close to GNOME, so I am in the process of moving to KDE. Originally I disliked KDE Plasma because it looked like a stale Windows Vista UI, from which I am strongly repelled.

If the Flatpaks were installed in the system, they would still be available to all users, regardless of upgrade, rollback or rebase.

If the Flatpaks were installed by the user, they would be saved in the home directory only for that user.

Alright, status report:

I successfully rebased to Kinoite. Using the same user. Mostly everything works just right out of the box.

In general, I cannot express how happy I am to be able to just switch my DE so easily. Kudos to Fedora SVB/KNT teams for making this possible!

I have issues with some Flatpaks i.e. they either crash some time after launch, or upon certain actions. Unfortunately, they don’t print anything in the terminal, so don’t know how to debug them. Tried reinstalling them, but the same issue happens again. Maybe it is a dependency issue, can’t say.

EDIT: the reason why Flatpaks were crashing was that they didn’t have permission to work in the background (even for apps that really don’t need it). See: Flatpak apps crashing after rebasing from Silverblue to Kinoite - #2 by andandand