SUMMARY By default, the Breeze Splash screen is enabled. I noticed the system took a long time to log in after entering my password after upgrading to Neon / Plasma 6. I went to disable to splash screen in order to look at the text of what was being loaded and this time logging in to the desktop was almost instantaneous. STEPS TO REPRODUCE - Problem 1. Go to Settings > Colors & Themes > Splash Screen 2. Select Breeze 3. Reboot OBSERVED RESULT After entering password, the Breeze splash shows for about 33 seconds before the desktop appears. EXPECTED RESULT Logging in should be a LOT quicker than 33 seconds. ---- ADDITIONAL STEPS TO REPRODUCE - Problem 1. Go to Settings > Colors & Themes > Splash Screen 2. Select None 3. Reboot OBSERVED RESULT After entering password, the desktop loads almost instantaneously. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Neon / Plasma 6 KDE Plasma Version: 6.0.0 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.2 ADDITIONAL INFORMATION There are no "new" splash screens available yet for Plasma 6, so I was unable to test other splash screens.
Run journalctl and see if you have bluetooth related failures, see Bug 481870
(In reply to Kevin R from comment #0) > ... I went to disable to splash screen in order to look at the text of > what was being loaded and this time logging in to the desktop was almost > instantaneous ... That's disabling the Splash Screen in the System Settings > Colors and Themes > Splash Screen? As far as I can tell, that didn't make a difference for me.
Confirming: affecting users on discuss aswell: https://discuss.kde.org/t/slow-desktop-loading-plasma-6/10749/21?u=duha
Disabling splash screen brings the wayland login time from ~30s down to ~2.5s for me too. Still feels like extra 1.5s more than the X11 login time, but now I would need stopwatch to be sure it's not placebo. The X11 session is still ~1s login time even after Plasma 6 upgrade, just like it was before, but I used Wayland first time ever by accident (it was default after upgrade) and it took those ~30s, also after logout/restart (well, once I fixed those as they were not working after upgrade too). Going to test X11 without splash screen if it didn't get slower (to match ~2.5s of Wayland), but if there's no edit/comment from me, then X11 behaves normally with ~1s login.
There must be more than one issue in play here... I've tried setting the splash screen to "none" (something that crashed systemsettings) in a test VM. Rebooting and logging on with Wayland and X11, I still get the org.bluez timeout and no difference to the logon delay.
(In reply to tagwerk19 from comment #1) > Run journalctl and see if you have bluetooth related failures, see Bug 481870 I initially checked to see if this was Bluetooth related, as I when I did some google searching that is all I found was people having delayed login due to Bluetooth. However I found out my problem doesn't seem to be related. I just checked journalctl again after enabling splash and rebooting and it doesn't show any unusual errors related to Bluetooth. The only error I see (which I have always seen with previous versions of Plasma) is "Bluetooth: hci0: Malformed MSFT vendor event: 0x02". So this is "normal" for me. This just seems to be the splash screen that is delaying login for some reason. I did look through the journalctl logs and was not able to find anything that could point to the delayed login. However, I don't even know what I am looking for, so someone else might be a better candidate for looking at the logs.
Just to collect some extra data, can we the output of `systemd-analyze --user blame` for those that can reproduce this bug? While there is something going on with ksplash it'd be useful to exclude other things going wrong.
(In reply to Arjen Hiemstra from comment #7) > Just to collect some extra data, can we the output of `systemd-analyze > --user blame` for those that can reproduce this bug? While there is > something going on with ksplash it'd be useful to exclude other things going > wrong. I'm not able to replicate a link to the splash screen, I've copied the "blame" here: https://bugs.kde.org/show_bug.cgi?id=481870#c6
(In reply to Arjen Hiemstra from comment #7) > Just to collect some extra data, can we the output of `systemd-analyze > --user blame` for those that can reproduce this bug? While there is > something going on with ksplash it'd be useful to exclude other things going > wrong. 1min 49ms drkonqi-coredump-pickup.service 2.044s xdg-desktop-portal.service 1.656s plasma-kcminit.service 1.582s xdg-desktop-portal-gtk.service 169ms plasma-powerdevil.service 143ms plasma-ksmserver.service 111ms plasma-plasmashell.service 108ms pulseaudio.service 89ms plasma-polkit-agent.service 86ms plasma-xdg-desktop-portal-kde.service 70ms plasma-kded6.service 35ms plasma-kactivitymanagerd.service 20ms plasma-ksplash-ready.service 17ms obex.service 16ms plasma-kglobalaccel.service 13ms kde-baloo.service 11ms plasma-kwin_wayland.service 8ms plasma-kcminit-phase1.service 6ms dbus.socket 6ms app-kaccess@autostart.service 6ms xdg-document-portal.service 5ms plasma-restoresession.service 5ms app-lts_eol@autostart.service 5ms app-org.kde.discover.notifier@autostart.service 4ms session-migration.service 4ms app-org.kde.kdeconnect.daemon@autostart.service 3ms xdg-desktop-portal-rewrite-launchers.service 3ms at-spi-dbus-bus.service 3ms app-org.kde.xwaylandvideobridge@autostart.service 2ms app-snap\x2duserd\x2dautostart@autostart.service 2ms dconf.service 2ms xdg-permission-store.service
(In reply to Arjen Hiemstra from comment #7) > Just to collect some extra data, can we the output of `systemd-analyze > --user blame` for those that can reproduce this bug? While there is > something going on with ksplash it'd be useful to exclude other things going > wrong. My previous comment was with the splash screen chosen. Below is with the splash screen as "none" and then I rebooted: 1.969s xdg-desktop-portal.service 1.667s plasma-kcminit.service 1.592s xdg-desktop-portal-gtk.service 139ms plasma-ksmserver.service 134ms plasma-powerdevil.service 92ms plasma-plasmashell.service 89ms pulseaudio.service 64ms plasma-polkit-agent.service 63ms plasma-xdg-desktop-portal-kde.service 62ms plasma-kded6.service 34ms plasma-kactivitymanagerd.service 22ms plasma-kglobalaccel.service 20ms kde-baloo.service 13ms plasma-kwin_wayland.service 8ms plasma-restoresession.service 7ms app-kaccess@autostart.service 7ms plasma-kcminit-phase1.service 6ms plasma-ksplash-ready.service 6ms dbus.socket 6ms app-lts_eol@autostart.service 6ms app-org.kde.discover.notifier@autostart.service 6ms xdg-document-portal.service 5ms app-org.kde.kdeconnect.daemon@autostart.service 4ms app-snap\x2duserd\x2dautostart@autostart.service 4ms app-org.kde.xwaylandvideobridge@autostart.service 4ms session-migration.service 4ms at-spi-dbus-bus.service 3ms obex.service 2ms xdg-desktop-portal-rewrite-launchers.service 2ms dconf.service 2ms xdg-permission-store.service
Just did a system update today and this issue appears to be resolved. I was curious as I saw a file with the name "Breeze" in it and decided to re-enable to splash screen after the update was completed. I rebooted, and lo and behold, the splash screen appeared after I entered my password for about a 1/2 second and then the desktop loaded.
*** This bug has been marked as a duplicate of bug 482267 ***