KDE Plasma start up very slow

English Install/Boot/Login
1

After recently removing an HDD from my system (openSUSE Leap 15.5, KDE) I find KDE Plasma (and Wayland) are now slow to start (30 - 40 seconds after login, was 5 seconds). This is a non critical issue but I would like to solve it if assisance is available.

The system is a small desktop PC used as a home computer. The most recent system change, apart from regular software updates, was the removal of a failing hard disk. The OS is installed on an nvme card, with btrFS. The swap partition is far too small - my partitioning error.

I found a related issue posted on 1st April discussed on this forum here

This report is based on issues raised there:-

systemd-analyze shows:
Startup finished in 1.017s (kernel) + 2.596s (initrd) + 6.524s (userspace) = 10.139s
graphical.target reached after 6.501s in userspace

systemd-analyze blame shows:
3.850s NetworkManager-wait-online.service
followed by about 25 lines in this pattern:-
2.146s sys-devices-platform-serial8250-tty-ttyS*.device
2.146s dev-ttyS*.device
(all ttySxx) where * is a number from 3 to 31. The reported delay in all cases is similar.

systemd-analyze critical-chain shows:

graphical.target @6.713s
└─display-manager.service @5.977s +735ms
  └─systemd-user-sessions.service @5.970s +5ms
    └─remote-fs.target @5.968s
      └─iscsi.service @5.944s +20ms
        └─network-online.target @5.940s
          └─NetworkManager-wait-online.service @2.088s +3.850s
            └─NetworkManager.service @2.053s +33ms
              └─network-pre.target @2.052s
                └─firewalld.service @1.626s +426ms
                  └─polkit.service @5.384s +12ms
                    └─basic.target @1.607s
                      └─sockets.target @1.607s
                        └─snapd.socket @1.596s +11ms
                          └─sysinit.target @1.593s
                            └─systemd-update-utmp.service @1.585s +8ms
                              └─auditd.service @1.431s +152ms
                                └─systemd-tmpfiles-setup.service @1.379s +50ms
                                  └─systemd-journal-flush.service @701ms +677ms
                                    └─var.mount @622ms +8ms
                                      └─dev-nvme0n1p2.device @584542y 2w 2d 20h 1min 48.076s +2.088s

cat /proc/cmdline shows:
BOOT_IMAGE=/boot/vmlinuz-5.14.21-150500.55.83-default root=UUID=eda410d2-7556-403c-b2d8-89d9b684a534 splash=silent resume=/dev/disk/by-id/nvme-ADATA_SX8200PNP_2J3020071038-part3 nvme_core.default_ps_max_latency_us=0 quiet mitigations=auto

Let me know what other information may assist an assessment.

Thanks

2

Are there any fstab entries remaining that point anywhere on the removed disk?

Are there any symlinks remaining anywhere in your homedir pointing anywhere on the removed disk?

If neither, try logging out of Plasma and into anything else available. IceWM ought to be. Does it take anywhere near as long? If not, or nothing else is available, while not logged into Plasma, purge the content of ~/.cache/ before logging back into Plasma, and after, report back here.

1 Like
3

Thanks for responding.
Nothing in fstab - I cleaned that. I had not thought of symlinks, thanks for the suggestion. There are a few symlinks - I will move them somewhere safe, test and report back.
I had already created a clean ‘new user’ - login is very fast. And yes - clear the ~/.cache.

You have been very helpful.

Thanks

4

I found and removed a few symlinks, I logged in with lxqt (no delay) and cleared ~/.cache …
Sadly, no improvement - login is still taking 35 seconds or so.

The tty subsystem is a mystery to me. I understand terminals 1-6 but what are all the ttySxx devices?

5

UART Serial ports. Why so many I have no comprehension.

1 Like
6

This two statements suggests, that the delay is not from the start process itself which can be monitored/captured by systemd-analyze. That means the delay is after the login and should be investigated via journalctl.

2 Likes
7

Thanks. I can see nothing obvious in log for relevant time during last boot (journalctl -b). There are other known errors and oddities but nothing related to ttySxx devices. Any clues?

8

Once again I spoke too soon. With your kind advice I may have found the culperit. mrmazda warned about “broken symlinks”, hui pointed to “journalctl”. The log told me that a wallpaper file was not found - and instructed me to fix it - I did. The file was on the damaged disk that I had removed. After fixing login is normal.

Thank you both so much. I keep learning from this forum. Your kindness is noted. :boomerang:

9

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.