Newly installed leap 15 is very slow to boot on a ssd.
Show as root
systemd-analyze blame
Think this is root.
22.029s display-manager.service
21.510s plymouth-quit-wait.service
16.566s wicked.service
10.340s backup-rpmdb.service
1.275s firewalld.service
1.249s btrfsmaintenance-refresh.service
1.215s ca-certificates.service
1.040s postfix.service
1.035s lvm2-monitor.service
772ms apparmor.service
627ms rsyslog.service
514ms logrotate.service
507ms initrd-switch-root.service
322ms chronyd.service
256ms udisks2.service
229ms nscd.service
213ms check-battery.service
200ms smb.service
155ms nmb.service
152ms upower.service
103ms mcelog.service
100ms kbdsettings.service
89ms systemd-udevd.service
88ms initrd-parse-etc.service
71ms systemd-udev-trigger.service
64ms home.mount
60ms systemd-tmpfiles-setup-dev.service
58ms dev-mqueue.mount
53ms backup-sysconfig.service
50ms sys-kernel-debug.mount
50ms dev-hugepages.mount
49ms systemd-remount-fs.service
48ms dracut-cmdline.service
44ms user@1000.service
36ms auditd.service
36ms iscsi.service
32ms wickedd.service
31ms klog.service
29ms systemd-vconsole-setup.service
27ms systemd-logind.service
26ms systemd-modules-load.service
25ms systemd-journal-flush.service
23ms systemd-journald.service
21ms boot-efi.mount
21ms systemd-fsck-root.service
20ms systemd-sysctl.service
18ms plymouth-start.service
18ms plymouth-switch-root.service
14ms dev-disk-by\x2duuid-2bd5cfff\x2dbc8c\x2d44ae\x2da803\x2d6c1120b66d71.s>
14ms initrd-cleanup.service
13ms systemd-tmpfiles-setup.service
13ms rtkit-daemon.service
12ms sysroot.mount
12ms plymouth-read-write.service
12ms dracut-pre-trigger.service
12ms systemd-random-seed.service
7ms systemd-update-utmp.service
7ms kmod-static-nodes.service
6ms systemd-update-utmp-runlevel.service
6ms dracut-shutdown.service
4ms systemd-user-sessions.service
4ms sys-fs-fuse-connections.mount
4ms initrd-udevadm-cleanup-db.service
Something to try.
On your next boot, hit ‘e’ when you see the boot menu.
Scroll down until you find a line that begins “linux” or “linuxefi”
On that line, replace “splash=silent” with “plymouth.enable=0”
Then hit CTRL-X to continue booting.
This is a one-time action for just the one boot. See if it boots faster. Maybe repeat the “systemd-analyze blame” after that boot.
Your boot times don’t look all that bad to me, but then I don’t have an SSD. But disabling plymouth does speed up booting here.
No still slow. I dual-boot with window 10 on separate ssds and windows boots in under 30 seconds. It’s not a major problem but I’m just wondering if there is something amiss.
17.884s display-manager.service
17.326s plymouth-quit-wait.service
17.198s wicked.service
1.206s btrfsmaintenance-refresh.service
1.038s postfix.service
989ms lvm2-monitor.service
932ms ca-certificates.service
733ms apparmor.service
517ms initrd-switch-root.service
421ms rsyslog.service
197ms smb.service
182ms udisks2.service
168ms upower.service
151ms nmb.service
127ms kbdsettings.service
100ms wickedd-auto4.service
99ms wickedd-dhcp4.service
98ms wickedd-dhcp6.service
96ms nscd.service
89ms systemd-udevd.service
89ms initrd-parse-etc.service
72ms chronyd.service
70ms systemd-udev-trigger.service
64ms home.mount
62ms avahi-daemon.service
62ms dev-hugepages.mount
61ms dev-mqueue.mount
59ms sys-kernel-debug.mount
55ms systemd-remount-fs.service
Usage of “systemd-analyze critical-chain” and “systemd-analyze plot > «Some file name».svg” will possibly show that, the display-manager service was waiting for the plymouth-quit-wait.service to complete …
- If you’re running systemd-analyze from the user “root” then, you’ll have to move the .svg Plot file off to somewhere where a “normal” user can gain access to it with either Firefox or Konqueror.
The 64 dollar question is " What’s currently “normal”? " – for me today: “36.248s plymouth-quit-wait.service” and “35.641s display-manager.service” – often it’s much less – only a second or two – I currently haven’t the faintest (read foggiest) notion as to what the root cause of this behaviour is …
If it was a new install then, it’s fairly normal for the RPM database backup service to take a few seconds to run on the initial reboot – normally it needs only a few hundred milliseconds – today for me: “868ms backup-rpmdb.service” …
Ditto the Firewall daemon: “900ms firewalld.service”.
Unfortunately the CA certificates service will usually need a second or two: “1.276s ca-certificates.service”.
Wicked, is wicked: for me today: “8.494s wicked.service” … Please be aware that, Wicked is very dependent on how the related DHCP server is responding to the requests triggered by the Wicked service – some tuning with respect to the DHCP leases and the interaction with the DHCP server is often required …
Having spent some time digging into the intricacies of the following systemd services, I have stumbled across an instability on this Leap 15.0 Desktop machine – a Leap 15.0 Laptop I have doesn’t display the instability I’m about to describe …
The systemd services I investigated were: ‘display-manager.service’; ‘plymouth-quit-wait.service’; ‘plymouth-quit.service’; ‘systemd-user-sessions.service’ and ‘multi-user.target’.
The game seems to be as follows:
- ‘display-manager.service’ service wants ‘systemd-user-sessions.service’ and, it’ll run after the ‘systemd-user-sessions.service’ and the ‘plymouth-quit.service’ have finished starting up …
- ‘plymouth-quit-wait.service’ calls “plymouth --wait” which holds the boot process until the Plymouth daemon has exited …
- ‘plymouth-quit.service’ and ‘plymouth-quit-wait.service’ are started by symbolic links in the “multi-user.target.wants/” directory …
In the “display-manager.service” file there’s a Conflict definition for the “plymouth-quit.service” …
- Removing the “plymouth-quit.service” Conflict definition initially caused some improvement but, not always …
Given that, the Display Manager service does not have a Conflict definition for the Plymouth “quit” service – the Plymouth “quit” service always executes and is never killed off by the Display Manager service – but, occasionally, the Plymouth “quit” service errors and fails to stop the Plymouth daemon …
- But, only on this Desktop – the Laptop never displays this behaviour …
If the Plymouth “quit” service doesn’t error, the Display Manager service sets up in about 850 milliseconds …
If the Plymouth “quit” service errors then, the Display Manager service needs about 11 seconds to set up, with the Plymouth “quit” service booking about 20 seconds to the system boot time …
More next week …
I’ve raised the openSUSE Bug Report #1110199.
[HR][/HR]The solution seems to be, to add a conflict (“Conflicts=”) to the ‘/usr/lib/systemd/system/display-manager.service’ systemd Service file: “plymouth-quit-wait.service” …
[HR][/HR]The reasoning is:
- The systemd Display Manager service makes an “ExecStart=/usr/lib/X11/display-manager start” call.
- The SUSE/openSUSE Bash script ‘/usr/lib/X11/display-manager’ has a Shell Function named “plymouth_quit” which calls “plymouth quit” (which is what the systemd "plymouth-quit.service
" does) and a call “plymouth --wait” (which is what the systemd “plymouth-quit-wait.service” does). - Therefore the systemd Display Manager conflict with both “Plymouth Quit” and “Plymouth Quit wait” …
[HR][/HR]On this non-UEFI machine, the systemd Display Manager service now needs “only” 2.3 seconds instead of 20 to 40 seconds …
Thanks for taking the time to investigate, share you findings, and the bug report. It does seem to have impacted a significant number of users.
Actually, I’ll be submitting a follow-on (alternative) Bug Report once I’ve tested a different approach on a UEFI Laptop.
- A possible root cause is, various boot time scripts are not respecting the systemd unit files and in particular the ones for “Plymouth Quit” – there seems to a bit of “Do-It-Yourself” going on in several places which calls “plymouth quit” and “plymouth --wait” directly rather than relying on the systemd “Before=” and “After=” mechanism …
- Because these “DIY” calls are possibly due to having to support non-systemd systems, the trick is to determine if the machine is being booted with systemd or not: "ps -q 1 -o comm=
" produces a string indicating if the initialisation process is “systemd” or, something else …
What boat loader options do you have? > yast control center> boat loader> kernel parameters
Without problems Plymout can be uninstalled
Wicked.service I’m sorry to say it but it’s a wrong choice of openSuse, with two clicks you can use network manager
Plain, vanilla, GRUB2 …
- This is a non-UEFI AMD platform …
Yes, I know, but, AFAICS there’s more than a few dependencies in the systemd services …
- If I was ever tempted to throw out systemd then, I could commiserate with your thought but, I’m staying with systemd and, therefore, no commiserations … >:)
I disagree, absolutely and totally!!!
- This is a Desktop system – Ethernet cable – no WLAN – therefore wicked
… >:) - My Laptop is portable, movable, usually WLAN, possibly a (mobile telephone network) Wireless (UMTS or LTE) card with a SIM – therefore Network Manager
… rotfl!
Beware the boot settings affect how, if you want to see the boot messages you will have a longer boot, if you want a black monitor with cursor only, you’ll be much faster if you want Plymouth you’ll be slow
I boot Tumbleweed Plasma in 7.5 - 8.5 seconds depends on systemd, and my computer is three years old, I do not think Leap15 is very different in the Boot.
Wicked is really bad and slows down any Boat loader
enziosavio@linux-area51:~> systemd-analyze
Startup finished in 3.568s (kernel) + 784ms (initrd) + 4.177s (userspace) = 8.530s
graphical.target reached after 4.167s in userspace
enziosavio@linux-area51:~> systemd-analyze blame
1.386s postfix.service
1.052s ca-certificates.service
1.005s dev-sda2.device
694ms display-manager.service
691ms firewalld.service
548ms systemd-logind.service
461ms systemd-fsck@dev-disk-by\x2duuid-badbc6e3\x2dcd3d\x2d4ea7\x2db946\x2d7037dca2c4b1.service
369ms initrd-switch-root.service
356ms systemd-fsck@dev-disk-by\x2duuid-c7c3a57f\x2dc5e8\x2d4327\x2d8fdb\x2d9ab3e6720784.service
336ms ModemManager.service
332ms tmp.mount
311ms chronyd.service
307ms udisks2.service
297ms nscd.service
287ms kbdsettings.service
251ms polkit.service
199ms upower.service
194ms var.mount
189ms systemd-tmpfiles-setup.service
188ms systemd-fsck@dev-disk-by\x2duuid-4a79e528\x2d7bbb\x2d4357\x2dac42\x2dc6b1b4796448.service
162ms archivio.mount
158ms accounts-daemon.service
98ms systemd-fsck@dev-disk-by\x2duuid-a9d3ce66\x2da5db\x2d4801\x2da86f\x2d000b90e1bca9.service
95ms NetworkManager.service
88ms initrd-parse-etc.service
84ms systemd-journal-flush.service
67ms mcelog.service
67ms systemd-fsck@dev-disk-by\x2duuid-64bfcff2\x2da36c\x2d4f21\x2d98c7\x2d8fbeaf14b11b.service
64ms auditd.service
60ms systemd-random-seed.service
59ms systemd-udev-trigger.service
52ms systemd-udevd.service
46ms user@1000.service
43ms lm_sensors.service
41ms dracut-cmdline.service
35ms iscsi.service
31ms issue-generator.service
31ms boot.mount
27ms systemd-fsck-root.service
23ms home.mount
23ms initrd-cleanup.service
20ms systemd-remount-fs.service
20ms systemd-update-utmp.service
20ms dev-hugepages.mount
17ms systemd-tmpfiles-setup-dev.service
15ms dev-mqueue.mount
14ms systemd-journald.service
enziosavio@linux-area51:~>
Plymouth addictions are very few, and concern only Plymouth
I’ve opened Bug 1110364 as an alternative solution.
The proposed changes (with the realisation that, the system is using systemd for initialisation) are as follows:
# /usr/lib/X11/displaymanagers/sddm
# Modify:
sddm_start_proc () {
+ pid1name=$(ps -q 1 -o comm=)
+ if 'systemd' != $pid1name ]; then
if -x /usr/bin/plymouth ]; then
/usr/bin/plymouth quit
fi
+ fi
return 0
}
#
# /usr/lib/X11/display-manager
# Modify:
plymouth_quit()
{
+ pid1name=$(ps -q 1 -o comm=)
+ if 'systemd' != $pid1name ]; then
if -x /usr/bin/plymouth ]; then
plymouth quit
plymouth --wait
fi
+ fi
}
#
# /usr/lib/systemd/system/display-manager.service
# Remove the Plymouth quit service conflict:
- Conflicts=getty@tty7.service plymouth-quit.service
- Conflicts=getty@tty7.service plymouth-quit.service plymouth-quit-wait.service
+ Conflicts=getty@tty7.service
#
# /usr/lib/systemd/system/sddm.service
# Remove the Plymouth quit call:
- ExecStartPre=-/usr/bin/plymouth quit --retain-splash
#
Please note that, for the case that a system is not using systemd for initialisation, the calls to quit Plymouth have to be retained …
Another thing that I have verified, using lightdm instead of sddm from the login to the Desktop is much faster, I had also done a post, but nobody has deigned to at least say it was or was not a problem just mine
Confirmed with nrickert’s solution below:
replace “splash=silent” with “plymouth.enable=0”
18 and a ½ seconds userspace with Wicked …
- If I were to replace Wicked by Network Manager I could, possibly, experience about 6 seconds userspace at boot time …
[LIST] - Sounds good for my Laptop …
[/LIST]
My bot options
splash=silent quiet showopts
After trying different this for me is the fastest, logically I uninstalled Plymout
For future reference, though, just letting you know that Yast is changing and installations to Desktop and Tower systems will eventually also default to Network Manager, as well as laptops.
Do you think this problem only occurs on non UEFI systems? I set up a new AMD Ryzen based desktop machine recently which uses UEFI and I think I have the same problem. Sometimes the boot time is really long. And it seems that the long boot time comes from the display-manager.service. Sometimes the display-manager.service needs 25 seconds more or even longer compared to the normal boot.