Kinoite, a KDE (and now XFCE) version of Fedora Silverblue

I don’t know why, but moving the KDE plasma settings in depth makes the kinoite 33 and 34 buggy

With other interfaces this does not happen

Hi @omlet1241. If you have a specific Plasma bug that you can reproduce then you can report that at with as much details as possible to help get it fixed.

I don’t know what the problem is

I downloaded fedora 33, created a new account, rebase to the coreos, and installed sddm and plasma-desktop

In short, I don’t think the system settings

If you rebased to Fedora CoreOS then you’re not using Kinoite. You probably need to add a lot of other packages to have properly working Plasma session on top of CoreOS.

rebase to Core os as an experiment

But then I did a rebase for the kinoite and it’s still the same, right now I’m using the fedora kinoite lxqt 33,

The server hosting the unofficial builds is currently down due to a fire in OVH datacenter:

any prediction to host on another server?Temporarily

I’ll probably setup a new server in the coming days but I don’t have a full local copy of the ostree repo so I will have to start from the latest backup I have which is a little bit old. Hopefully that should not be an issue.

The repository is back online with the backup I had which is approximately two months old. Will push a new build in the coming days.

1 Like

Thanks for all the work you’re doing on Kinoite! :+1:

1 Like

@Siosm it was just to mention that some important applications for lxqt are missing

Like for example the qps

Once I find out which packages are missing from lxqt, I’ll be back here

I’ve just pushed a new update for F33, F34 and Rawhide to the repo. The repo is temporarily hosted on the previous slower server while I get another faster one back online.

Make sure to pin your current deployment or the ones you want to keep as backup as I won’t be able to bring back the history even if/when I get access to the server back. I’ve tested the update for Kinoite so at least those should work.

@Siosm can you remove Firefox from the kinoite base rebase?

This has been discussed several times:

I’m personally against it as I think it makes it really hard for people to figure out what happened if we remove the default browser from the image in an update or if they uninstall it by mistake. Overall, having a browser always be included in the image makes for a better user experience.

If you don’t want to have the browser listed as installed, you can use:

$ rpm-ostree override remove firefox

Applications are not provided in the base image by default as they should either be provided via Flatpaks or overlayed as needed.

What applications are missing?

I’ve just pushed the latest build for F33, F34 & Rawhide. F34 should be Beta content at this point. Enjoy!

I have Silverblue installed as the only OS, with default disk layout and disk encryption. Then I have a rebase to Kinoite which I use as a daily driver for a couple months.

I did a rebase to F34 to test it, but it fails to boot. The console output goes too fast to be able to see exactly where the problem occurs and there are no logs. I made a video where I could barely see that Journal service is started, FUSE control file system is mounted and static nodes in dev are created, and then many trace outputs like RIP: 0010:kobject_put+0x19/0x1d0. After many screens of such output errors, it gets to a wait trying to zram and in the end it freezes, so I can only do a forced shutdown via power off. Repeated CTRL+ALT+DEL presses in the meanwhile again lead to a freeze.

Luckily, as I have pinned both Silverblue and Kinoite in several versions, I can still boot and continue working :slight_smile:

I do have extensive experience on various Linux distribution, but I have not touched Fedora until now and anything Redhat I used was before 2000. Silverblue and Kinoite are setup a bit different, so I have trouble finding the right documentation on capturing logs from the boot process. There is nothing at all in /var/log or journal from this specific boot that has failed. I can only see the logs from boot processes before that, and after that. Can you direct me to the relevant docs on how to capture the trace outputs to be able to find the problem and report it where relevant.

Can you create a new thread in the Silverblue section? You will get more visibility as this thread here is only for updates about Kinoite and other variants status.

I will move that discussion to the Silverblue section. I just found that this is a recently reported issue where DELL laptops are affected and there is a fix in rawhide kernel. For now, if anyone else is affected, the temporary fix to be able to boot for me was to add the modprobe.blacklist=dell_wmi_sysman option at boot time.

I only have one issue with F34 Kinoite now, and this is probably due to differences in the official infrastructure and the Kinoite builds. I use a toolbox to manually build v4l2loopback, and for this to work, the same version of the kernel and modules at the host and the toolbox are needed. It will sort out when things get synchronized, and in the meanwhile I keep pinned several versions of F33. It is just something one has to have in mind.