How did your Plasma session break, and how did you fix it?

Brainstorm
1

Hi! I’m investigating what it would take to recover from a broken Plasma session. Maybe you have experiences of breakage and finding a (manual) fix for it? I’d be interested in your story.

General topics that come to mind:

  • Plasma broke after you updated to a new version (of any package).
  • Plasma broke after you installed some 3rd-party add-ons.
  • Plasma broke after you changed some settings, and it wasn’t straightforward how to restore the previous state.
  • You tried to copy your Plasma setup to a different machine, and it didn’t work.

If anything like this happened to you, I’m all ears! And especially if you figured out how to make it work again. Perhaps something along the lines of:

  • You couldn’t figure out what’s wrong, but creating a new user account made things work again.
  • You had to change (or delete) some config files manually and that did the trick. (Which ones specifically?)
  • There was some version mismatch and updating some packages fixed it.
  • You never found a solution, and Plasma is now on your top hated buggy piece of crap list.
  • You know what broke, but it can only be fixed by Plasma developers, so you submitted a bug report.

All of the above are just to get your juices flowing. Feel free to include as many or as few details as you want to!

Please note that I’m looking into recovering from a broken state, not into implementing specific missing features. If something works for most people, but isn’t working for you, that’s exactly what I’m hoping to learn about. If something doesn’t work for any Plasma user, chances are you’ll get more mileage out of submitting a bug or feature request to bugs.kde.org.

Curious about your stories, thanks for writing them up :slight_smile:

2 Likes
2

Recently I was trying to set up a package manager called UnigetUI to run in a distrobox container and simultaneously manage rpm packages inside the container and also Homebrew packages on the host Bazzite system. I was using Google’s AI search to help me figure this out, and somehow this led to a black screen that persisted even after rebooting. I don’t remember exactly what I did, but I should be able to bring up and share that chat. I eventually was able to fix it by deleting the distrobox container, rolling back to an earlier Bazzite image, and deleting some files in ~/.local/config. I’m not sure if all of those steps were necessary, but eventually something fixed it!

1 Like
3

Wow, yeah, that sounds like quite the chaotic change history. I’m not sure if it’s be feasible to figure out what happened on your system without spending too much time on a longer chat history, but theoretically distrobox (as a container technology) should not interfere with the basic desktop, and similarly Bazzite (as an atomic distro) is a relatively trustworthy base.

So my intuition is that the deletion of files in .local/config (which ones, if I may ask?) would have been the most likely fix for Plasma to not turn black. But distrobox shouldn’t be dismissed either, it often gets home folder access in some ways and can be autostarted via systemd service (or KDE autostart settings).

Good stuff, thanks for sharing!

1 Like
4

I found the relevant bit from the AI chat history:

“I had to install flatpak-spawn using dnf in the container, but when I tried to add the package source, my PC froze and rebooted, and booting took much longer than usual. after logging in, it froze again on a black screen”

I did that because the AI suggested using flatpak-spawn as a way to bypass the container and execute commands directly in the host OS, which I wanted to do to manage Homebrew packages. When I explained what happened, it said that was actually a bad idea:

"Your PC froze because installing flatpak-spawn via DNF inside a standard Distrobox container created a catastrophic dependency and mounting conflict.

Because Distrobox shares critical low-level namespaces with the host (like /sys, /dev, and parts of /run), installing flatpak-spawn pulled in heavy systemd/DBus plumbing dependencies into the container. This clashed with your host’s active Nvidia drivers and display server, inducing a kernel lockup and hard reset. The long boot time and black screen freeze mean your broken container’s initialization service is crashing your display manager (KWin/Plasma) on login."

I guess I learned the hard way not to trust AI advice, even if it seems reasonable! At least this time I was able to recover! :joy:

1 Like
5

Getting a bit off topic, but Distrobox provides the distrobox-host-exec command as the way to do that.

6

Wow, that’s a crazy way to have your system break. But also an interesting mindbender, and as you say educational.

I’ve heard more than one story about AI suggestions being involved in breakage and/or fixing, maybe I should ask one of the popular models about what cases of breakage it’s seen before in its training data.

2 Likes
7

When I was on Manjaro KDE years ago, nearly every update would break something. I managed to fix it once or twice with using a live USB session but can’t remember exactly how I fixed it. But it look a long time to fix (maybe a day or two of looking up and trying various things). Manjaro was always breaking on me, so I switched distros.

These days, I don’t generally have those issues as Fedora KDE and Ultramarine KDE are pretty stable. With that being said, towards the end of 42 both distros were having regression issues with it’s various parts. One of the last updates broke SDDM and only a blank screen after booting (I was also using themes for the SDDM which may have also caused the black screen issue). I managed to login going to a command prompt after booting. I had to create a new session (F3, F4??), tried reinstalling the updates manually. I also tried a few things in a Live USB. After days of trying various things it was just quicker and easier to do a fresh install. I was up and running in 30min again.

Now I just use the default SDDM theme, BTRFS assist for system snapshots - not that I’ve had to use them since.

1 Like
8

If people find this there’s going to be a lot of very user-specific scenarios, aren’t there?

I started* with Xfce and Ubuntu then Plasma then same with Debian, so I did most of the learning with the first pairing – there were definitely Ubuntu releases that borked things but it was mostly things other than the DE (like a networking component being changed, or fundamental ecosystem stuff). And it’s mostly been with distros using apt. Since I’ve only reinstalled the main daily use system once in a decade, when moving to Debian due to the Canonical Snap direction, I got fairly comfortable with manually sorting out any upgrades that broke partway through enough to not get back to a functioning DE. Which hasn’t been many on this box.

IIRC Plasma 5 to 6 needed a bit of fixing afterwards (having restored the previous /home/ files) and the plasmoids etc I was using or had customised didn’t carry over into a usable desktop, but considering I’m still carrying some config files and things like icon choices forward from 2016, have switched compositors, found workarounds, etc, it’s all been robust enough even with the degree of frankensteining I’ve done. No intention of ever starting with a completely clean slate unless it’s VMs to troubleshoot something specific, or maybe if the hardware gets replaced (but I haven’t found any need, PCs got to “good enough” way back or about 2012 in my case).

The trouble is that to the average user it really isn’t obvious what’s distro, what’s DE, what’s software stacked on top of that, so they may not ever get to the bottom of things and identify root causes. From what I was reading around the time of the 5 to 6 switch, though, I think that wasn’t a very smooth transition for some people. Similarly, there’ve been issues over the years that I connect with the hardware and kernel issues, re: power management and graphics acceleration. Those might have looked like the fault of a DE to some people.

Occasionally (with no obvious pattern) when restoring from hibernation the Wayland session seems to not recover, certainly not in a reasonable amount of time, and the quickest resolution is to switch tty and restart. I don’t think this is fully not recovering, it’s more that it feels like it’s taking an inordinately long time to switch back in things required for an interactive desktop session – possibly the order in which things are prioritised. It isn’t consistent and since this generation of Intel hardware has always been a bit flaky on Windows as well as Linux with hibernation, it’s something I just accept. I don’t tend to restart after updates unless the DE specifically prompts, either, so like pretty much everything it’s likely mostly my fault. Have also made decisions over the years about things like a main non-system partition using Ext4 without case sensitivity.

As long as upgrade processes are relatively seamless for the majority of users, that’s a win. There’s nothing I notice as being broken in whatever version of Plasma is currently in Debian 13. A few minor issues with the interaction of Wayland and specific non-KDE applications, but I expect that’s going to be the situation for years. Everything’s still infinitely more robust than Linux was circa the turn of the century.

That reminds me – the handling of existing global shortcuts when switching to Wayland is an example that springs to mind where things could perhaps have been done with more hand-holding for normal users.

*Started the time I stayed for personal use, anyway. Have dipped in and out for about as long as Linux has been around and some fond memories of KDE 3 for instance.

edit: My notes from the Plasma 5 to 6 switch as part of the Debian upgrade –

https://virtualdebris.co.uk/blog/039DA73E/project-zebra-upgrade-to-debian-13-and-switching-to-wayland

1 Like
9

A recent example from reddit:

1 Like