[Stable Update] 2024-05-18 - Linux-Firmware, PHP, Gitlab, Qt6

The monitor is not listed at all, so cannot be enabled"… I wish it were that simple.

I’m recalling the DP monitor display was glitchy/corrupted when I first booted it up (was off for vacation), but after I switched it to HDMI (my Steamdeck, which found and used it as expected without glitchy video) and then back to DP the display was no longer corrupted for the laptop… installed the updates, rebooted, and the display was absent… it may be possible the DP port on the monitor is borked and this was bad/coincidental timing.

I’ve discovered a new issue with SDDM. If I Super-L to lock the screen I’m left at a black/blank screen, SDDM is not presented to log back in.

The first time I encountered this, I did a REISUB… the second time I switched to TTY3 to see if I could find anything interesting in the journal (pretty quiet), and when I switched back to TTY2 SDDM was presenting.

Super-L again and SDDM was again not presented (blank screen). Switched to TTY1 then back to TTY2 and SDDM was showing.

So it seems to be that when I lock the screen, I have to switch away from TTY2, and SDDM will show when I return to TTY2.

EDIT: seems I’m not alone with the blank SDDM on lock… Plasma 6: Lock screen renders black (troubleshooting help) - Help - KDE Discuss

It works, but you need to clean the cache. It was looking ugly for me, but when I cleaned it, it stared looking like before again. Somehow, main settings were kept, so I probably didn’t mess with config, but I did clean Plasma 5 configs too.

Well, it appears the old Samsung C32HG70 DP port/“brains” died; completely unrelated to the 5-18 update. The monitor’s HDMI continues to work fine on my Steamdeck and is now working well on the Laptop.

I’ll replace the monitor when the HDMI or monitor itself dies… this monitor’s twin blew it’s PSU a couple years ago, so I’m guessing this ones days are numbered now that issues are creeping in.

Ok I figured it out… The Kjots is not jet updated to latest 6.0.0 that is compatible with KDE6 therefore it cannot work.

update to plasma 6.0.5 went well for me

Edit: posted right before Philm made testing announcement…

Testing branch? [Testing Update] 2024-05-23 - ICU 75.1, InputPlumber, Plasma 6.0.5, LibreOffice, NextCloud


In my computer, is the first system release upgrade on my Manjaro fresh installed in November 2023.

The only problem what I don’t encountered a solution is: After the update, in every shutdown attempt, my system is always delaying the shutdown, appearing the message for 40 to 60 seconds: “A stop job is running for User Manager” in the shutdown logs. There are some solutions for this problem?


1 Like

When I try to change KDE shotcuts, I’m getting Error while communicating with the global shortcuts service and the system settings for shortcuts is grayed out.

journalctl shows
May 23 22:48:09 quantum systemsettings[154441]: org.kde.kcm_keys: "org.freedesktop.DBus.Error.UnknownObject" "No such object path '/component/o> May 23 22:48:09 quantum systemsettings[154441]: org.kde.kcm_keys: "Error while calling allShortCutInfos of/component/org_kde_spectacle_desktop"

Upd: uninstalling spectacle fixed the issue

I have also seen this at times. I haven’t been able to work out a pattern/cause yet.

This is generally not a problem. Occasionally this can happen when, for example, a background process needs to complete before shutting down. If you forget to terminate a process (a running app) then shutdown can be delayed (usually no more than 1-2 minutes in practice) with a Stop Job message until the process finishes.

Normally, you should likely wait for shutdown to continue of it’s own accord. Terminating the Stop Job prematurely often results in it appearing again at the next reboot/shutdown, in my experience.

You can always check your logs to see just what hadn’t finished closing.


1 Like

It’s a pain in the backside when you have to wait a long time for a stop job if you need an urgent reboot. Annoyingly, the oft-found “fix” of changing DefaultTimeoutStopSec in /etc/systemd/system.conf doesn’t make any difference.

1 Like

I can’t dispute that. It depends on what still has to close, and how long that may take. Changing the timeout has done diddly-squat for me, also. :person_shrugging:

it’s not a fix but cutting off a limb when you have an itchy finger.
Linux asks all tasks to stop, and sometimes a task refuses in order to finish its job.
the bug is, if linux no ask and close all (looks like your fix) :wink:

All you have to do is find this job! Imagine it’s a backup, is it a good idea to cut it off before it’s finished ?
Generally this task is a backup service, cloud service or network service…

We’re not on the right topic, open your own.

1 Like

This is weird… as I am no longer experiencing the blank/black screen on lock.

Now that I’ve accepted the monitor’s DP demise and swapped connecting the monitor via its still working HDMI port, I cannot duplicate the blank/black SDDM on lock problem.

However, curiosity demanded I see what happens when I disconnect the monitor (unplug HDMI) and my next lock after doing so presented the blank/black screen.

Reconnected the HDMI connection, desktop spanned two monitors, locked the PC, and SDDM showed correctly; no more blank/black screen.

This got me even more curious, wondering if kscreen was holding on to the fact that there were 2 monitors, so I tried another test… disconnected HDMI, rm -rd ~/.local/share/kscreen, locked the PC, and SDDM was blank again.

Well, I’m confused, but it appears that a workaround to this issue under X11 is to have more than one monitor.

Just want to make a statement and offer a curious thought.

I applied this update in the worst way possible (logged in and actively using the system) and managed to only encounter a single “major issue” for which multiple solutions have already been brought and essentially is solved.

The curious thought about this.
Did my intentional switch to wayland about a year ago (roughly) allow me to apply this huge update with almost zero issues? Im thinking this may be the case due to seeing that lots of graphical issues were afflicting others post-update. I have suffered exactly 0 graphical issues.

Probably not. It was likely that you kept your environment in better shape than most; avoiding foreign gadgets and AUR packages, for example. I’ve seen a few reports of people having done nothing much in the way of preparation, but still without any issues to speak of.

All I did, basically, is remove a few incompatible widgets, delete the .cache directory, reboot and update. I only had minor issues (a widget I forgot about) which I took care of before the next reboot.


Understood. Must be that. I run a rather lean system with as little added graphical fluff as I can. That habit comes from running a $300 hp office machine, bought in 2009, up until 2019. Even with an added low-grade graphics card and maxed RAM, and running xcfe manjaro (or a distro very similar), I had to download yt videos and play them in vlc; they would not play in browser, even 480p.
Streaming audio with no video with hiccup sometimes too! I was about to migrate to an even less graphically heavy flavor, or no GUI at all, but choose to finally build a new machine, something I was looking to do for almost 3 years but kept putting it off as an unnecessary purchase.

Ill def be more actively involved in updating my system and watching announcements, after this last update. Id like to keep this install going for as long as possible :crossed_fingers: … eventho a fresh install has its perks!



Thanks for your response. Do you have any tips to detect in the logs what processes is delaying the User Manager closing?

Thanks for your attention.

This will produce logs from the last boot:

journalctl --boot=-1 --priority=3 --catalog --no-pager
  • Typing journalctl --help will give more options.

The solution of the following thread will allow you to see shutdown logs:



I would like to inform that I got error with Plasma Network Management (plasmanetworkmanagement_l2tpui.so). I cannot add or edit L2TP network configuration. Here is the screenshot from dmesg:

Turns out that this error also occured on fresh ISO.
Please help.