Can I make boot process shorter?

English Install/Boot/Login
#1

Notebook Lenovo T 450s, Leap 15, no other OS. /home on SSH is encrypted with LUKS. Boot time about a minute. I’m puzzled. See here:


linux-kjrm:/home/AW # systemd-analyze
Startup finished in 2.752s (kernel) + 2.786s (initrd) + 22.769s (userspace) = 28.308s
linux-kjrm:/home/AW # systemd-analyze blame | head -20
         16.368s display-manager.service
         15.853s plymouth-quit-wait.service
          4.859s systemd-cryptsetup@cr\x2dauto\x2d1.service
          2.272s postfix.service
          1.004s btrfsmaintenance-refresh.service
           809ms ca-certificates.service
           537ms vboxdrv.service
           332ms lvm2-monitor.service
           287ms rsyslog.service
           281ms opt.mount
           281ms kbdsettings.service
           280ms var.mount
           275ms boot-grub2-i386\x2dpc.mount
           252ms usr-local.mount
           251ms apparmor.service
           222ms initrd-switch-root.service
           210ms \x2esnapshots.mount
           208ms plymouth-start.service
           189ms tmp.mount
           168ms boot-grub2-x86_64\x2defi.mount
linux-kjrm:/home/AW # systemd-analyze critical-chain
The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.

graphical.target @22.764s
└─display-manager.service @6.395s +16.368s
  └─systemd-user-sessions.service @6.390s +4ms
    └─remote-fs.target @6.389s
      └─iscsi.service @6.365s +24ms
        └─network-online.target @6.363s
          └─network.target @6.360s
            └─wpa_supplicant.service @6.882s +20ms
              └─dbus.service @5.311s
                └─basic.target @5.307s
                  └─paths.target @5.307s
                    └─btrfsmaintenance-refresh.path @5.307s                                          
                      └─sysinit.target @5.304s                                                       
                        └─systemd-update-utmp.service @5.300s +3ms                                   
                          └─auditd.service @5.282s +17ms                                             
                            └─systemd-tmpfiles-setup.service @5.274s +7ms                            
                              └─local-fs.target @5.273s                                              
                                └─home.mount @5.262s +10ms                                           
                                  └─systemd-fsck@dev-disk-by\x2duuid-b85c5630\x2d9b74\x2d4714\x2dae0e\x2d91b8bc2287a2.service @5.243s +18ms
                                    └─dev-disk-by\x2duuid-b85c5630\x2d9b74\x2d4714\x2dae0e\x2d91b8bc2287a2.device @5.242s

Display-manager 16 seconds? wpa_supplicant? Any ideas? Thank you!

By the way, Leap 15 is running stable and I enjoy it.

#2

I am using Leap 42.3, but when booting I hit the escape key to see what takes so long. In my case it is wpa_supplicant performing multiple connects and disconnects.

I noticed it in /var/log/boot.log as:


         Starting WPA Supplicant daemon...
  OK  ] Started WPA Supplicant daemon.
  OK  ] Started Wait for Network to be Configured.
*     ] A start job is running for wicked managed network interface
**    ] A start job is running for wicked managed network in
***   ] A start job is running for wicked managed netw
 ***  ] A start job is running for wicked managed netw
  *** ] A start job is running for wicked managed netw
   ***] A start job is running for wicked managed netw
    **] A start job is running for wicked managed network inter
     *] A start job is running for wicked managed network interfaces (
    **] A start job is running for wicked managed network inter
   ***] A start job is running for wicked managed netw
  *** ] A start job is running for wicked managed netw
 ***  ] A start job is running for wicked managed netw
***   ] A start job is running for wicked managed netw
**    ] A start job is running for wicked managed network in
*     ] A start job is running for wicked managed network interface
**    ] A start job is running for wicked managed network in
***   ] A start job is running for wicked managed netw
 ***  ] A start job is running for wicked managed netw
  *** ] A start job is running for wicked managed netw
   ***] A start job is running for wicked managed netw
    **] A start job is running for wicked managed network inter
     *] A start job is running for wicked managed network interfaces (
    **] A start job is running for wicked managed network inter
   ***] A start job is running for wicked managed netw
  *** ] A start job is running for wicked managed netw
 ***  ] A start job is running for wicked managed netw
***   ] A start job is running for wicked managed netw
**    ] A start job is running for wicked managed network in
*     ] A start job is running for wicked managed network interface
**    ] A start job is running for wicked managed network in
***   ] A start job is running for wicked managed netw
 ***  ] A start job is running for wicked managed netw
  *** ] A start job is running for wicked managed netw
   ***] A start job is running for wicked managed netw
    **] A start job is running for wicked managed network inter
     *] A start job is running for wicked managed network interfaces (
    **] A start job is running for wicked managed network inter
   ***] A start job is running for wicked managed netw
  *** ] A start job is running for wicked managed netw
 ***  ] A start job is running for wicked managed netw

So, I dumped the boot logs with the command below to see what wpa_suipplicant was actually doing.


journalctl -b --no-pager >boot.txt

I dumped it to a text file for easier searches.

#3

If I disable Plymouth (plymouth.enable=0), PC boots fast:

https://bugzilla.opensuse.org/show_bug.cgi?id=1094961

#4

This is just for comparison:


# systemd-analyze critical-chain
The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.

graphical.target @38.303s
└─multi-user.target @38.302s
  └─getty.target @38.302s
    └─getty@tty1.service @38.302s
      └─systemd-user-sessions.service @22.808s +121ms
        └─remote-fs.target @22.807s
          └─iscsi.service @22.635s +172ms
            └─network.target @22.557s
              └─wpa_supplicant.service @35.935s +674ms
                └─dbus.service @9.293s
                  └─basic.target @9.238s
                    └─paths.target @9.238s
                      └─sendmail-client.path @9.238s
                        └─sysinit.target @9.206s
                          └─apparmor.service @2.437s +6.768s
                            └─system.slice
                              └─-.slice

I’m using GDM as display manager. I use an ethernet connection for networking. My desktop is Plasma 5 (X, not Wayland). I have removed the string “splash=silent” from the kernel command, so I don’t see plymouth graphics. I do use an encrypted LVM.

#5

This is normal “wicked” behaviour: it waits until it’s absolutely certain that, all interfaces are read, up, and running. In “/etc/sysconfig/network/config” there’s a parameter named “WAIT_FOR_INTERFACES” which controls how long wicked will wait.

To work out how long to wait, you need something like this, for the user “root”:journalctl --this-boot | grep -Ei ‘r8169|eth0|wicked|network|DHCP|ntp’

Where: “r8169” is the physical interface indicated by “kernel: ??? 0000:02:00.0 eth0: link up” – your system will have something different to “r8169” …

Walk through the output and check the timestamps for:

  • “systemd[1]: Reached target Host and Network Name Lookups.”
  • “systemd[1]: Starting wicked network management service daemon…”
  • “kernel: r8169 0000:02:00.0 eth0: link up”
  • “wicked???]: Interface wait time reached”

The wicked interface wait time should expire a few seconds after wicked has committed at least the DHCPv4 lease …
On this system, wicked commits the DHCPv6 lease about 3 seconds after “systemd[1]: Started wicked managed network interfaces.” and “systemd[1]: Reached target Network.” …

#6

To work out how much time the “wpa_supplicant.service” is taking, use "systemd-analyze blame | grep ‘wpa_supplicant’ ".
And, “systemctl status wpa_supplicant.service”.

#7

Actually, this means that, the WPA Supplicant service started successfully, before


  OK  ] Started wicked network nanny service.
         Starting wicked managed network interfaces...

had completed (" OK ] Reached target Network.") …