This post is basically for KDE Plasma users on Linux systems which are not based on rolling releases, but which get upgraded in the course of defined upgrade cycles of the distribution. It is a kind of reminder about a rather trivial point when you upgrade your Linux system or when someone else has done this for you:

• It may sometimes be worth the effort to rebuild and reconfigure your KDE Plasma desktop after your Linux OS has been upgraded.

A full upgrade of a modern Linux system comprises the upgrade of very different components. In most cases a change to a newer version of your preferred desktop environment is part of the packet upgrades. Regarding the evolution of KDE/Plasma during the last 20 years, I have several times experienced that the desktop may exhibit problems after such an upgrade. In a few cases the desktop itself and its configuration would struggle with problems, sometimes a certain application or plasmoid had deficits. Such deficits have most often affected the performance or presentation of only the application on the desktop, but sometimes the overall desktop performance was hampered.

Startup times for standard Linux systems are pretty fast these days – including the start of a graphical desktop session. Even on a 12 years old laptop a KDE Plasma desktop based on X11 builds up within 3 secs after passing login credentials – even with reconstructing the status of multiple applications you left open at the end of your last KDE session. Part of the time may go into (Wifi) network access – and the establishment of complex firewall rules during network startup by networkmanager – dependent on your configuration. But under normal circumstances, establishing network connections by networkmanager should not be an obstacle for a fast general start of the graphical desktop.

Therefore, it should make you nervous when you find that starting a KDE Plasma session on a laptop takes around 10 to 20 secs. This was an experience I yesterday had on a system which had been upgraded to Opensuse Leap 15.6 some months ago. The user was frustrated about a long delay during KDE startup – which he could prove by excerpts of logged system messages. Unfortunately, neither the system logs nor the X11 logs indicated clearly what the reason was. In my opinion, this was an indication of some problematic configuration. Even if the KDE desktop appeared to work without problems after its long startup phase. Some app or plasmoid could have waited during the start of the desktop session for a rather long period for a timeout.

I could help my acquaintance. The question who has caused the glitch, the user or the OS provider, most often is relatively unproductive and fruitless. As long as there is no indication of a hacker’s manipulation … Leaving the possibility of a hacker’s interference aside, we first of all want to reconstruct a working graphical environment. If we find the culprit for the problems on our way – the better it is. Nevertheless, for important system exposed for whatever reason to unfriendly attackers, I would recommend to make forensic copies of the system first. Never ever think, Linux is a kind of barrier for experienced hackers …

This post, therefore, is about a possible solution under best circumstances – namely about a systematic reconstruction of your KDE desktop, its layout, plasmoids and applications to avoid configuration “errors” you may have carried around with you since the last or even since some older upgrade.