Minimal CentOS-9 KDE Plasma install with latest LTS Kernel

I like Fedora, so I had this idea in my head to try out KDE Plasma on something more stable.

Some forethoughts

First bummer, RHEL / Almalinux / Rockylinux or even CentOS-Stream are not “a bit more stable” than Fedora, by far.

There is a point with very stable packages (apart from not needing to reinstall from a CD every 6 months :wink: , it just doesnt seem to work well with 3rd party maintained KDE Plasma.

I didnt actually have any problems with Fedora packages. I may would like to use the official LTS Kernel, but the rest just works. More on the LTS Kernel later.

I also want a modern KDE Plasma experience, as I use it for years and especially Plasma 6 is a huge upgrade in stability and alignment of everything.

I dont mind using a setup like on Fedora Kinoite, where only the real core apps are system packages and the rest is all Flatpaks. This already helps a ton with stability, while using modern applications.

I will also experiment with CentOS-Stream-atomic as soon as something usable comes out (rebasing to CentOS-9-bootc just gave me a blackscreen).

Getting a minimal ISO

This was complicated. Not requesting alternative images, just to have the netinstall visible.

The official download page has various install types, but all are ~8GB and contain the complete GNOME desktop with a ton of apps (aka. not at all what I plan).

But the minimal install “boot” can be found here. It includes the Anaconda installer and is basically a Netinstall. I dont get why this is hidden.

Make sure to verify the checksum before using it. I used KDE Dolphins integrated menu.

Note that the “netinstall” ISOs dont seem to be compatible with the “verify boot media” step on boot.

Setting up

For testing I create a virt-manager VM, 40GB storage, 6GB RAM, 4 logical CPU cores.

There are a few interesting differences.

  • I disabled KDUMP as I dont need it
  • The standard user is not in the “wheel” group by default, which is strange

Security profiles

  • At least the “advanced” ones dont work with the automated partitioning.
  • About the RHEL ones it just tells you what Software will be added. dovecot, really? You should use external sources about what these rules will actually do.

Disk partitioning:

  • I chose “default” which afaik is XFS.
  • I chose LUKS encryption
  • Blivet GUI is missing, and exiting from the “custom setup” menu is near impossible.


  • just the minimal install
  • security utilities are also nice
  • poorly, same as with Fedora, there is no “Hardware support” group, so no Wifi functionality on real hardware, likely

First boot

Interestingly, the LUKS prompt is full CLI and pretty messed up

I can enter the password normally, but the errors below it are a bit strange.

I would like to know how to change this to the GUI (related post).

After entry and login, lets set it up!

I used this post as a guide.

Setting up the repos

EPEL and EPEL-next repos

These repos are needed for a lot of packages like the entire KDE Plasma desktop. They are not officially supported by RedHat, so be careful.

sudo dnf install -y epel-release epel-next-release
# or if not found
# sudo dnf install -y 

# enabling 
sudo dnf config-manager --set-enabled crb

optional: kernel-longterm-6.6 COPR

I saw the Kernel used is 5.14, which is a bit crazy old for me (even with the CentOS Kernel having tons of backports also for features).

Luckily there is this cool COPR project, building the current LTS Kernel for many RPM distros.

sudo dnf copr enable kwizart/kernel-longterm-6.6

If you end up using that Kernel in production, consider leaving the kwizart a donation on his Paypal account.

Note that this is optional. I trust the upstream maintained LTS kernel more, but it is not at all tested against CentOS (just built for it).

Advantages are possible more security backports, better hardware support, new features. Drawbacks are shorter support time and no testing (afaik).

optional: rpmfusion

This has dependencies on EPEL

sudo dnf install --nogpgcheck$(rpm -E %rhel).noarch.rpm$(rpm -E %rhel).noarch.rpm

RPMFusion is needed for legally restricted codecs and drivers. Also some packages like ffmpeg are there in their complete form.

Advantages are more support via native packages, including critial NVIDIA driver support. Drawbacks are synchronisation issues (way less of a problem than on Fedora), less reliabilty and liability and external trust.

Installing the packages

Now let’s install everything needed for a good KDE GUI experience

# base
sudo dnf install -y kernel-longterm man-pages dnf-automatic fwupd firewalld firewall-config

sudo dnf install -y plasma-workspace-wayland sddm sddm-breeze konsole dolphin ark kwrite kio-fuse plasma-systemmonitor flatpak-kcm kscreen kinfocenter plasma-nm

# Wifi etc.
sudo dnf group install -y "Hardware Support"

Optional packages

# base
nano parallel wireguardtools fish ...

plasma-discover-flatpak plasma-discover sddm-kcm kaccounts-providers khelpcenter plasma-nm-openconnect plasma-nm-openvpn spectacle kate kcharselect 

# Bluetooth
NetworkManager-bluetooth bluez bluedevil kf5-bluez-qt

# Printing
system-config-printer cups-filesystem system-config-printer-udev bluez-cups

# virtualization
virt-manager qemu qemu-kvm

For whatever reason this also installed the x11 stuff, so removing it again

sudo dnf remove -y kwin-x11

# removing possibly unneeded packages, be careful!
sudo dnf autoremove

# refreshing the dnf cache
sudo dnf --refresh upgrade

(I am sure there is some fancy dnf flag to avoid this.)

Installing Flatpak apps

To keep the system minimal, I mainly install Qt and KDE Flatpaks. This is completely optional though and there are many good or GNOME Flatpaks too. Have a look at my recommendations.

To keep it secure, I only add the flathub-verified remote. (More infos).

flatpak remote-add flathub-verified --subset=verified 

# install a minimal set of apps
flatpak install -y gwenview okular librewolf keepassxc skanpage haruna cryptomator

There are other apps that I would recommend:

# GNOME runtime
celluloid simplescan g4music bottles carburetor switcheroo decoder denaro pdfarranger localsend videotrimmer warp

# big flatpaks
thunderbird libreoffice gimp inkscape 

# other kde/qt apps
kcalc filelight strawberry digikam krita qbittorrent kfind kcalc kleopatra

# other apps
syncthingy nextcloud 

bottles pupgui

Note: the Fedora Flatpak runtime has Flatpaks that are built from Fedora RPMs. This has the advantages of another distro looking at them, a secure and common build system and possibly SELinux support. The Flathub runtime has various sources, builds, dependencies etc, advantages are official upstream support, way more apps, less bugs and theoretically one less person to trust.

Things like the xz vulnerability maybe wouldnt have been discovered without 3rd party distributors.

Other programs

There also is StirlingPDF, which allows a ton of PDF editing features from all the FOSS tools, centralized in a single podman container and with a good Web UI.

sudo dnf install -y podman

podman run -d -p 8080:8080 --name stirling-pdf

# desktop entry coming soon

Rust packages

If you want to install Rust binaries, this works completely independently from the host system and thus ensures always being on the latest version.

Building some crates requires gcc. Alternatively you could use cargo-binstall to use the official binaries.

# install rustup and cargo
curl --proto '=https' --tlsv1.2 -sSf | sh

# when needed
sudo dnf install -y gcc

Python packages

sudo dnf install python3-pip

For use with virtual environments consider pipx.

Enabling automatic updates

This system is stable, so you may want automatic updates. dnf is not suited for that, that’s why dnf-automatic is installed.

But this does not do anything on its own, it needs to be invoked.

I think this systemd service should work.

sudo cat > /etc/systemd/system/auto-updates.service <<EOF
Description=Update in the background

# wait 2min to reduce system load
ExecStartPre=/usr/bin/sleep 120
# execute after another to reduce system load
ExecStartPost=/usr/bin/flatpak update -y

# this is somehow required to make it installable. It will be executed when

This service is not yet tested.

For some reason, I had no permission using sudo cat but sudo vi worked?

So you might need to edit that file manually.

sudo systemctl enable --now auto-updates

Finishing the setup

This will enable graphical mode and enable the sddm login manager.

sudo systemctl set-default
sudo systemctl enable sddm && reboot


Stuff that is missing

sddm-wayland is available on Fedora and missing here. A backport would be highly appreciated, or it may be possible via a config change.

I am also not sure if SDDM uses a dedicated sddm user in the sddm group, or runs as root.

Plasma 6

Do you know if Plasma 6 will end up in EPEL, like EPEL-next-10?

There is a crazy project by @loise for KDE Plasma 6 on EPEL 9. The COPR adds a ton of more repos, and possibly more repos are needed. I assume this is work in progress and 90% there, but currently it does not install the base packages because of many dependency issues on core libraries.


You might be interested in the images the CentOS Alternative Images SIG is producing, which include KDE: Images - CentOS Alternative Images SIG

I saw the Kernel used is 5.14, which is a bit crazy old for me. Luckily there is this cool COPR project, building the current LTS Kernel for many RPM distros.

The version number of the kernel in CentOS Stream is a bit misleading. It is true the kernel is based on 5.14, but it has a large number of backports from more recent releases, including whole subsystems at times. While by no means a cutting-edge kernel, it’s less old than it appears to be.

1 Like

Interesting, thanks! The images are really useful, even though likely very “bloated” with RPM packages, similar to Fedora KDE.

I trust the officially maintained LTS kernel way more, and dont expect any breakages using that.

It will also have better hardware support.

Using the CentOS kernel really only makes sense if you need support for over 2 years, and I dont think admins should be that lazy ;D highly depends, embedded devices somewhere remotely maybe, but even them will have ssh.