Slow Plasma desktop startup

snack · 2025-07-11 07:14:23

Since the upgrade to Plasma 6.4 my desktop takes a very long time to load after typing the login credentials in SDDM. The splash gear keeps rotating for about 15 seconds, then a black desktop with frozen widgets and no panels/bars appears. Windows for automatically started applications show up correctly and they work fine, but the desktop is still black. After about 1 minute the desktop recovers and everything work fine except for the system tray where icons of some automatically started applications (Thunderbird with systray-x-kde and Whatsie) are not present, so I have to manually kill and restart them to make the icons appear.

I don't know if this is really due to Plasma 6.4 or to some other package that was updated at the same time (I didn't update for a week while I was in holiday, and when I did it it was pretty massive). I don't know precisely how to debug this, so I'd need some help, thanks.

Last edited by snack (2025-07-22 07:58:15)

seth · 2025-07-11 08:26:36

Did you inadvertently to move wayland?
https://archlinux.org/news/plasma-640-w … re-on-x11/
Same problems on X11?

Please post your complete system journal for the boot:

sudo journalctl -b | curl -F 'file=@-' 0x0.st

snack · 2025-07-11 08:37:54

Here it is: https://0x0.st/8DMn.txt

About Wayland, I've been on it since a long time before the problem appeared. I'll check X11 as soon as I can reboot (I'm currently working with the system and cannot interrupt).

seth · 2025-07-11 08:44:40

lug 11 08:09:11 stryke kernel: simple-framebuffer simple-framebuffer.0: [drm] Registered 1 planes with drm panic
lug 11 08:09:11 stryke kernel: [drm] Initialized simpledrm 1.0.0 for simple-framebuffer.0 on minor 0
lug 11 08:09:11 stryke kernel: simple-framebuffer simple-framebuffer.0: [drm] fb0: simpledrmdrmfb frame buffer device
lug 11 08:09:11 stryke kernel: i915 0000:00:02.0: [drm] Found coffeelake (device ID 3e9b) integrated display version 9.00 stepping N/A
lug 11 08:09:11 stryke kernel: i915 0000:00:02.0: [drm] Finished loading DMC firmware i915/kbl_dmc_ver1_04.bin (v1.4)
lug 11 08:09:11 stryke kernel: i915 0000:00:02.0: [drm] *ERROR* Failed to probe lspcon
lug 11 08:09:11 stryke kernel: [drm] Initialized i915 1.6.0 for 0000:00:02.0 on minor 1
lug 11 08:09:11 stryke kernel: fbcon: i915drmfb (fb0) is primary device
lug 11 08:09:11 stryke kernel: i915 0000:00:02.0: [drm] fb0: i915drmfb frame buffer device
lug 11 08:09:11 stryke systemd[1]: Starting Load Kernel Module drm...
lug 11 08:09:11 stryke systemd[1]: modprobe@drm.service: Deactivated successfully.
lug 11 08:09:11 stryke systemd[1]: Finished Load Kernel Module drm.
lug 11 08:09:22 stryke kwin_wayland[1210]: No backend specified, automatically choosing drm
lug 11 08:32:52 stryke kwin_wayland[1210]: kwin_wayland_drm: failed to open drm device at "/dev/dri/renderD128"
lug 11 08:32:52 stryke kwin_wayland[1210]: kwin_wayland_drm: failed to open drm device at ""
lug 11 08:32:52 stryke kwin_wayland[1210]: kwin_wayland_drm: failed to open drm device at ""
lug 11 08:32:52 stryke kwin_wayland[1210]: kwin_wayland_drm: failed to open drm device at ""
lug 11 08:32:52 stryke kwin_wayland[1210]: kwin_wayland_drm: failed to open drm device at ""

Lose "pcie_port_pm=on", add "nvidia_drm.modeset=1" (this will block the simpledrm device, let's see where that gets us - nb. that you might not be able to run a GUI session at all w/ this)
Also remove the kms hook, resp the i915 module from your mkinitcpio.conf (and regenerate the initramfs)

Sidebar, replace pulseaudio w/ pipewire-pulse

snack · 2025-07-14 07:05:44

@seth I tried the modifications to the kernel parameters you suggested but that didn't help. Also, the X11 session has the same problem. I didn't remove kms hook from mkinitcpio (I actually need it for some packages, I think, do you really think it's worth trying this?) Iand I didn;t understand what you mean about i915 (add it to mkinitcpio.conf?).
Sidebar, pulseaudio replaced, thanks.

seth · 2025-07-14 09:13:21

You might have "kms" in the HOOKS array or "i915" in the MODULES array of your mkinitcpio.conf (or both) - either would trigger early KMS.
Whether that's gonna help here idk ahead.

w/o a dri device you're gonna have problems everywhere - do you have an udpated journal and an xorg log?
Also

ls -l /dev/dri
echo $KWIN_DRM_DEVICES

snack · 2025-07-16 05:05:59

The problem seems to be fixed now, I didn't specifically do anything so it could be due to a package update. Thanks Seth for your help.

snack · 2025-07-22 07:51:43

I've been too optimistic with my previous post, but at least I think I understood the problem. In my fstab I have some lines referring to disk servers (Ceph and NFS) at work, e.g.:

172.16.5.22:/storage/home /wizard/bombur/home nfs noauto,x-systemd.automount,x-systemd.requires=network-online.target,x-systemd.idle-timeout=5min,x-systemd.device-timeout=10,_netdev 0 0

When I'm home I use an OpenVPN tunnel to mount them, which does not start automatically at boot. I see that systemd tries to mount these network shares at boot, which fail after some minutes; except when I'm at work, where in the local network there's no need for the VPN and shares are mounted immediately. This could explain why sometimes (i.e. when I'm at home) the Plasma startup is really slow, while some others it isn't (i.e. when I'm at work with the same laptop). This behavior is quite recent so I cannot say if it is due to newer versions of systemd that tries to mount the automount shares at boot or due to newer Plasma that waits for all the boot mounts to be finished.

I tested this hypothesis by removing the systemd automount entries from fstab and indeed this fixed the problem, but I'd like anyway to automount the shares on demand. Is it possible to tell systemd to not automount on boot? I searched for this setting but I didn't find anything, the only mention is about noauto (which is already present on my fstab line) and anyway it says that when x-systemd.automount is present it is ignored.

seth · 2025-07-22 13:58:45

Something™ is gonna try to access that path - you can catch it w/ https://wiki.archlinux.org/title/Audit_ … ies_access
The alternative would be to replace "x-systemd.requires=network-online.target" w/ a custom target that's only reached when 172.16.5.22 is actually reachable.
https://wiki.archlinux.org/title/System … tom_target
See eg. /usr/lib/systemd/system/graphical.target - you'll need a service that has maybe "ExecStartPre=/usr/bin/ping -1 -W 0 172.16.5.22" or so, so it will only start after the server responded. Then just "Exec=/usr/bin/true".

snack · 2025-07-22 14:11:35

Thanks for the tips, I'll try first to understand what's trying to access the share (guess something related to Plasma, hence the slow startup).

Arch Linux

#1 2025-07-11 07:14:23

Slow Plasma desktop startup

#2 2025-07-11 08:26:36

Re: Slow Plasma desktop startup

#3 2025-07-11 08:37:54

Re: Slow Plasma desktop startup

#4 2025-07-11 08:44:40

Re: Slow Plasma desktop startup

#5 2025-07-14 07:05:44

Re: Slow Plasma desktop startup

#6 2025-07-14 09:13:21

Re: Slow Plasma desktop startup

#7 2025-07-16 05:05:59

Re: Slow Plasma desktop startup

#8 2025-07-22 07:51:43

Re: Slow Plasma desktop startup

#9 2025-07-22 13:58:45

Re: Slow Plasma desktop startup

#10 2025-07-22 14:11:35

Re: Slow Plasma desktop startup

Board footer