Kde gui doesn't start anymore after update, dumped core

Today I updated a Manjaro PC of mine that I’ve sadly neglected for at least 6 months (and only used it remote as an ssh socks gateway…)

Now the KDE GUI doesn’t start anymore… Looking at the journalctl output show’s lot’s of problems, I don’t know how to find what the root cause might be:

kwin_x11[1374]: kwin_xkbcommon: XKB: couldn't find a Compose file for locale "en_AT.UTF-8" (mapped to "en_AT.UTF-8")
pulseaudio[1827]: GetManagedObjects() failed: org.freedesktop.DBus.Error.TimedOut: Failed to activate service 'org.bluez': timed out (service_start_timeout=25000ms)
systemd-coredump[2082]: Process 531 (systemd-journal) of user 0 dumped core.
plasmashell[1391]: file:///usr/lib/qt/qml/org/kde/plasma/extras/PlaceholderMessage.qml:238:5: QML Heading: Binding loop detected for property "verticalAlignment"
libddcutil[3115]: i2c_check_businfo_connector() failed for bus *
systemd[1]: Failed to start Disk Manager.
systemd[1399]: plasma-powerdevil.service: start operation timed out. Terminating.
systemd[1399]: Failed to start Powerdevil.
libddcutil[3141]: busno=3, sleep-multiplier =  2.00. Testing for supported feature 0x10 returned Error_Info[DDCRC_RETRIES in ddc_write_read_with_retry, causes: DDCRC_DDC_DATA(10)]
udisksd[4643]: failed to load module nvme: libnvme.so.1: cannot open shared object file: No such file or directory
udisksd[4643]: Failed to load the 'nvme' libblockdev plugin
kernel: traps: udisksd[4643] trap int3 ip:7fd4373ac5a3 sp:7ffc4e523330 error:0 in libglib-2.0.so.0.7800.3[7fd437363000+9e000]
systemd[1]: Started Process Core Dump (PID 4648/UID 0).
systemd-coredump[4649]: [🡕] Process 4643 (udisksd) of user 0 dumped core.

UPDATE: so it seems it just got extremely slow, it actually did produce my desktop after around 10 minutes which before that update took around 2 seconds…

So the system still works sort of but is in an unusable state because the GUI reacts extremely slow to any keyboard/mouse input.

Hi @thomas85,

Well, thanks, I was busy typing for you when the update loaded…

Well…open a terminal and provide the output of the following, please:

mhwd-kernel --list


mhwd-kernel --listinstalled


journalctl --priority=warning..err --boot=0 --no-pager 


  • The --priority=warning..err argument limits the output to warnings and errors only;
  • --no-pager formats the output nicely for use here, on the forum;
  • the --boot=0 argument limits the messages to be from the current boot.
# mhwd-kernel --list
available kernels:
   * linux419
   * linux510
   * linux515
   * linux54
   * linux61
   * linux65
   * linux66
   * linux67
   * linux61-rt
   * linux65-rt
   * linux66-rt

# mhwd-kernel --listinstalled
Currently running: 6.1.68-1-MANJARO (linux61)
The following kernels are installed in your system:
   * linux61

journalctl --priority=warning..err --boot=0 --no-pager produces extremely much output I can’t post here…

Something I found that I believe might be the cause of the extrem slowdown is that Timeshift decided to delete btrfs snapshots using rm -rf instead of btrfs subvolume delete

Then try this:

journalctl --priority=warning..err --boot=0 --no-pager | curl -F 'sprunge=<-' http://sprunge.us


See what happens if you run the following:

killall org_kde_powerdevil

it kills the process :wink:

The slowdown comes and goes. It sometimes reacts normal for a few minutes and sometimes freezes for around 30 seconds. (And it just happened again, so killing that didn’t fix the problem)

But it seems to only freeze windows whose processes try to read from disk or some other bottle-neck resource. Firefox freezes & the terminal windows containing htop too, but the terminal window running dstat continues to work fine.

OK, to be totally honest with you:

I think best would be a reinstall. I have never seen that many errors in the logs (And I thought mine was bad, PFFFT.)

I honestly don’t knosw what else to tell you, except BACKUP and reinstall…

okey :wink: well it still works well enough for it’s main purpose (ssh socks proxy)

And it seems now that timeshift finished deleting all my old btrfs snapshots with rm -rf instead of btrfs subvolume delete it does work reasonably well again.
(crappy tool, I should have used btrbk like I do on my servers instead, but let it entice me years ago when it came pre-installed and with this nice looking gui)

Make sure your .pacnew files are handled! That will help.


Personally, if something was going to be used like you just describe this PC’s purpose, I’d use a point release, preferably LTS distribution. Like Ubuntu Server LTS. And possibly something very low power-consuming, like my Raspberry Pi, which I use as my network’s sever…

possibly something very low power-consuming,

yes, me too normally, but this is in an office where I don’t have to pay the power and I don’t have the freedom to bring my own hardware, it’s just an office PC that I managed to get them to let me install an OS of my choice on - And since I’m not there too often any longer the main purpose that it has left is as socks proxy. If I had known when I installed it I wouldn’t have chosen Manjaro, but back then I was in the office twice a week and used that PC as my main development machine, and for that I just prefer a distro that gives access to the AUR.

That could be the reason why btrfs wants to clean up quite a bit :wink:

Take a look at the status of the “unused space” of btrfs (but definitely via sudo), and then again 30 minutes later.

If btrfs cleans up in the background, this can take quite a long time on a mechanical hard drive.

You can force this by sending gradually filtered balances. You can find a pattern on the btrfs page in the manjaro wiki. (So first 50%, then 70%, then 80%… 95%)