Boot Times are too High

Hey everyone,

I had installed OpenSUSE TW on a Lenovo Laptop with Intel i5 and 12 GB of RAM.
No additional software has been installed.
All possible updates have been installed.

The boot time is just too high. I had clocked it from the power on to desktop. It had taken nearly 3 minutes to reach the desktop.
Surprisingly the VM Image I had taken tried on before installing on actual hardware had taken hardly 1 minute to boot.
Not sure what is causing the slowness. Can you please help in identifying and resolving this issue ?

Thanks in Advance,
RD (y)

Please show ouput of


systemd-analyze blame

between CODE tags ( the # in the editor )

My apologies, I saw the post a bit late.
I had reinstalled OS TW again, but had removed a bunch of pattern during the installation screen itself. The boot times are a little better…Around a minute mark.
Anyways posting the output here in case, it can be further optimized.

:~> systemd-analyze blame
          5.675s firewalld.service
          5.237s dev-sda8.device
          4.370s ModemManager.service
          4.362s btrfsmaintenance-refresh.service
          4.314s initrd-switch-root.service
          4.229s display-manager.service
          3.839s nscd.service
          3.465s postfix.service
          3.426s chronyd.service
          3.043s avahi-daemon.service
          3.021s kbdsettings.service
          3.021s bluetooth.service
          2.822s plymouth-quit-wait.service
          2.724s apparmor.service
          2.141s boot-efi.mount
          1.743s plymouth-start.service
          1.581s home.mount
          1.081s systemd-logind.service
           925ms polkit.service
           821ms dev-disk-by\x2duuid-0da24141\x2d1725\x2d4ba9\x2d99a6\x2de5285dc0d5f9.swap
           814ms systemd-udevd.service
           593ms upower.service
           581ms NetworkManager.service
           541ms var.mount
           536ms systemd-rfkill.service
           534ms root.mount
           525ms srv.mount
           519ms udisks2.service
           508ms tmp.mount
           489ms boot-grub2-i386\x2dpc.mount
           484ms boot-grub2-x86_64\x2defi.mount
           436ms systemd-remount-fs.service
           427ms dev-mqueue.mount
           423ms dev-hugepages.mount
           409ms sys-kernel-debug.mount
           396ms rtkit-daemon.service
389ms opt.mount
           383ms systemd-udev-trigger.service
           356ms systemd-journal-flush.service
           329ms usr-local.mount
           286ms systemd-tmpfiles-setup-dev.service
           235ms auditd.service
           217ms sysroot.mount
           200ms systemd-modules-load.service
           194ms systemd-random-seed.service
           176ms user@1000.service
           169ms systemd-journald.service
           158ms iscsi.service
           153ms systemd-backlight@backlight:intel_backlight.service
           144ms wpa_supplicant.service
           143ms initrd-parse-etc.service
           137ms plymouth-read-write.service
           134ms mcelog.service
           114ms kmod-static-nodes.service
            98ms systemd-vconsole-setup.service
            94ms systemd-fsck-root.service
            88ms systemd-user-sessions.service
            73ms systemd-sysctl.service
            62ms systemd-tmpfiles-setup.service
            49ms dracut-cmdline.service
            40ms systemd-update-utmp.service
            26ms initrd-cleanup.service
            19ms plymouth-switch-root.service
            17ms dracut-pre-trigger.service
            16ms dracut-shutdown.service
            13ms \x2esnapshots.mount
            11ms user-runtime-dir@1000.service
            10ms systemd-update-utmp-runlevel.service
             7ms initrd-udevadm-cleanup-db.service
             6ms sys-fs-fuse-connections.mount

Thanks for all the help.

Can you now provide the output from:

grep swap /etc/fstab

There have been some cases where the installer has messed up the swap configuration, so that’s one possible place to look.

i5 cpus are not created equal:

notebook:~ # systemd-analyze 
Startup finished in 6.352s (firmware) + 4.393s (loader) + 4.231s (kernel) + 2.317s (initrd) + 3.741s (userspace) = 21.037s
graphical.target reached after 3.571s in userspace
notebook:~ # 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 @3.571s
└─multi-user.target @3.571s
  └─cron.service @3.570s
    └─postfix.service @1.880s +1.685s
      └─network.target @1.875s
        └─wpa_supplicant.service @2.567s +45ms
          └─dbus.service @923ms
            └─basic.target @919ms
              └─sockets.target @918ms
                └─dbus.socket @918ms
                  └─sysinit.target @915ms
                    └─apparmor.service @302ms +612ms
                      └─systemd-journald.socket
                        └─system.slice
                          └─-.slice
notebook:~ # 

My notebook is:

notebook:~ # inxi -zF
System:    Host: notebook.fritz.box Kernel: 4.19.4-1.g2f38375-default x86_64 bits: 64 Console: tty 0 
           Distro: openSUSE Tumbleweed 20181122 
Machine:   Type: Laptop System: HP product: HP Laptop 15-da0xxx v: Type1ProductConfigId serial: <filter> 
           Mobo: HP model: 84A6 v: 80.24 serial: <filter> UEFI: Insyde v: F.02 date: 05/24/2018 
Battery:   ID-1: BAT1 charge: 29.6 Wh condition: 40.0/41.9 Wh (95%) 
CPU:       Topology: Quad Core model: Intel Core i5-8250U bits: 64 type: MT MCP L2 cache: 6144 KiB 
           Speed: 600 MHz min/max: 400/3400 MHz Core speeds (MHz): 1: 600 2: 600 3: 600 4: 601 5: 600 6: 600 7: 600 8: 600 
Graphics:  Device-1: Intel UHD Graphics 620 driver: i915 v: kernel 
           Display: server: X.org 1.20.3 driver: modesetting unloaded: fbdev,vesa resolution: <xdpyinfo missing> 
           OpenGL: renderer: Mesa DRI Intel UHD Graphics 620 (Kabylake GT2) v: 4.5 Mesa 18.1.7 
Audio:     Device-1: Intel Sunrise Point-LP HD Audio driver: snd_hda_intel 
           Sound Server: ALSA v: k4.19.4-1.g2f38375-default 
Network:   Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet driver: r8169 
           IF: eno1 state: down mac: <filter> 
           Device-2: Realtek RTL8821CE 802.11ac PCIe Wireless Network Adapter driver: rtl8821ce 
           IF: wlo1 state: up mac: <filter> 
Drives:    Local Storage: total: 238.47 GiB used: 166.02 GiB (69.6%) 
           ID-1: /dev/nvme0n1 vendor: Toshiba model: KBG30ZMV256G size: 238.47 GiB 
RAID:      Hardware-1: Intel 82801 Mobile SATA Controller [RAID mode] driver: ahci 
Partition: ID-1: / size: 29.40 GiB used: 6.46 GiB (22.0%) fs: ext4 dev: /dev/nvme0n1p2 
           ID-2: /home size: 200.17 GiB used: 159.55 GiB (79.7%) fs: ext4 dev: /dev/nvme0n1p3 
           ID-3: swap-1 size: 4.00 GiB used: 0 KiB (0.0%) fs: swap dev: /dev/nvme0n1p4 
Sensors:   System Temperatures: cpu: 33.0 C mobo: N/A 
           Fan Speeds (RPM): N/A 
Info:      Processes: 221 Uptime: N/A Memory: 7.70 GiB used: 1.02 GiB (13.2%) Shell: bash inxi: 3.0.27 
notebook:~ # 

I think you can disable several of those services. I presume you are adsl or fibre and not on a modem so you can disable ModemManager.service. If you are like me on ext4 and not on btrfs, you can disable btrfsmaintenance-refresh.service. On my computer I have disabled avahi-daemon.service (that is configuring an auto connection when you have no networking service), if you don’t run a mail server you can disable postfix.service. The command is

systemctl disable <insert service here>

I shouldn’t have thought of that,maybe some apps is hidden on the computer.

very interesting thing, I’m supposing to disable these services, is this ok about your opinion??
pla@pla-3-TW:~> systemd-analyze blame
14.306s apparmor.service, I don’t know anything about it, is it ok to disable?
9.776s ModemManager.service, I don’t use modem, it is ok to disable?
8.531s btrfsmaintenance-refresh.service, I on ext4, it is ok to disable?
are there other services that I can disable about your opinion?
manythanks, ciao, Pier

pla@pla-3-TW:~> systemd-analyze blame
         17.120s plymouth-quit-wait.service
         16.941s display-manager.service
         14.306s apparmor.service
         13.392s lvm2-monitor.service
         10.482s ca-certificates.service
          9.776s ModemManager.service
          8.531s btrfsmaintenance-refresh.service
          5.989s initrd-switch-root.service
          5.553s systemd-journal-flush.service
          4.810s mcelog.service
          4.773s nscd.service
          4.614s kbdsettings.service
          4.108s vboxdrv.service
          3.942s postfix.service
          3.780s systemd-udevd.service
          3.736s polkit.service
          3.096s NetworkManager.service
          2.261s backup-rpmdb.service
          2.231s ntpd.service
          2.151s sshd.service
          1.708s systemd-tmpfiles-setup-dev.service
          1.686s plymouth-start.service
          1.390s systemd-fsck@dev-disk-by\x2dlabel-dati.service
          1.301s systemd-tmpfiles-clean.service
          1.049s avahi-daemon.service
           859ms systemd-fsck@dev-disk-by\x2dlabel-home2.service
           800ms systemd-remount-fs.service
           792ms dev-disk-by\x2duuid-7d02d083\x2dd2a0\x2d4527\x2d9a0a\x2d95d7ce380c89.swap
           728ms systemd-udev-trigger.service
           710ms colord.service
           677ms systemd-sysctl.service
           630ms dev-mqueue.mount
           619ms iscsi.service
           578ms auditd.service
           531ms sys-kernel-debug.mount
           489ms dev-hugepages.mount
           484ms bluetooth.service
           459ms upower.service
           434ms systemd-fsck-root.service
           351ms logrotate.service
           343ms wpa_supplicant.service
           339ms systemd-user-sessions.service
           333ms systemd-modules-load.service
           323ms systemd-tmpfiles-setup.service
           295ms systemd-random-seed.service
           287ms systemd-logind.service
           285ms systemd-backlight@backlight:nv_backlight.service
           284ms systemd-backlight@leds:dell::kbd_backlight.service
           256ms fstrim.service
           191ms sysroot.mount
           186ms home.mount

Hi
You probably want to check things first…

For example, use journalctl to check the boot log for failed services, eg, on a recent setup here;


journalctl -b --no-pager |grep Failed

Nov 26 08:09:28 big-bird systemd-backlight[844]: Failed to get backlight or LED device 'backlight:acpi_video0': No such device

It’s because the amdgpu one is used…


journalctl -b --no-pager |grep backlight:amdgpu

Nov 26 08:09:28 big-bird systemd[1]: Starting Load/Save Screen Backlight Brightness of backlight:amdgpu_bl0...

So I want to not only disable, but ensure it doesn’t pop back so I mask it…


systemctl status systemd-backlight@backlight\:acpi_video0.service
systemctl disable systemd-backlight@backlight\:acpi_video0.service
systemctl mask systemd-backlight@backlight\:acpi_video0.service

Created symlink /etc/systemd/system/systemd-backlight@backlight:acpi_video0.service ? /dev/null.

Likewise for things like ModemManager.

That being said, the critical chain output is of more interest and delays here. The blame output can be missleading as tasks can be in parallel, esp things like fsck, purge kernels, rpmdb maintenance. If your only using ipv4 I always configure this in postfix main.cf inet_protocol since I disable ipv6. I also get rid of plymouth packages and add locks then rebuild initrd.

trying this I have only:

pla@pla-3-TW:~> journalctl -b --no-pager |grep Failed
Hint: You are currently not seeing messages from other users and the system.
      Users in the 'systemd-journal' group can see all messages. Pass -q to
      turn off this notice.
Nov 18 16:11:47 pla-3-TW.suse kdeinit5[2304]: org.kde.kcm_keyboard: Failed to parse the layout memory file "/home/pla/.local/share/kded5/keyboard/session/layout_memory.xml"
Nov 18 16:11:56 pla-3-TW.suse pulseaudio[2414]: [pulseaudio] backend-ofono.c: Failed to register as a handsfree audio agent with ofono: org.freedesktop.DBus.Error.ServiceUnknown: The name org.ofono was not provided by any .service files
pla@pla-3-TW:~> su
Password: 
pla-3-TW:/home/pla # journalctl -b --no-pager |grep Failed
Nov 18 16:11:47 pla-3-TW.suse kdeinit5[2304]: org.kde.kcm_keyboard: Failed to parse the layout memory file "/home/pla/.local/share/kded5/keyboard/session/layout_memory.xml"
Nov 18 16:11:56 pla-3-TW.suse pulseaudio[2414]: [pulseaudio] backend-ofono.c: Failed to register as a handsfree audio agent with ofono: org.freedesktop.DBus.Error.ServiceUnknown: The name org.ofono was not provided by any .service files
pla-3-TW:/home/pla # 

and for now I removed these:

pla-3-TW:/home/pla # systemctl disable btrfsmaintenance-refresh.service
Removed /etc/systemd/system/multi-user.target.wants/btrfsmaintenance-refresh.path.
Removed /etc/systemd/system/multi-user.target.wants/btrfsmaintenance-refresh.service.
pla-3-TW:/home/pla # systemctl disable ModemManager.service
Removed /etc/systemd/system/dbus-org.freedesktop.ModemManager1.service.
Removed /etc/systemd/system/multi-user.target.wants/ModemManager.service.
pla-3-TW:/home/pla # systemctl disable apparmor.service
Removed /etc/systemd/system/multi-user.target.wants/apparmor.service.
pla-3-TW:/home/pla # 



Hi
Check on the next boot, if they come back, then mask as well… :wink:

Apparmor is a kernel security module - I wouldn’t disable that.

manythanks, I did this:

pla@pla-3-TW:~> su
Password: 
pla-3-TW:/home/pla # systemctl enable apparmor.service
Created symlink /etc/systemd/system/multi-user.target.wants/apparmor.service → /usr/lib/systemd/system/apparmor.service.
pla-3-TW:/home/pla # 

Today my Leap-15.0-based main rig managed to boot in 1.488 seconds, a new personal record. It was a warm boot into KDE, which is one contributing factor amongst many others. My rig is a self-built Core-i5/ASUS/Samsung-SSD box, nothing special.

▶ systemd-analyze blame

           468ms dev-sda1.device
           164ms initrd-switch-root.service
           111ms upower.service
           108ms display-manager.service
            94ms systemd-journal-flush.service
            80ms NetworkManager.service
            73ms systemd-udevd.service
            67ms polkit.service
            55ms systemd-logind.service
            42ms klog.service
            40ms initrd-parse-etc.service
            34ms systemd-tmpfiles-clean.service
            34ms systemd-udev-trigger.service
            29ms dracut-cmdline.service
            21ms user@1000.service
            19ms initrd-cleanup.service
            19ms systemd-update-utmp.service
            15ms udisks2.service
            15ms systemd-tmpfiles-setup.service
            14ms systemd-tmpfiles-setup-dev.service
            13ms dev-mqueue.mount
            12ms systemd-remount-fs.service
            12ms dev-hugepages.mount
            11ms sys-kernel-debug.mount
            10ms systemd-fsck-root.service
            10ms systemd-sysctl.service
             7ms dracut-pre-trigger.service
             6ms sysroot.mount
             6ms rtkit-daemon.service
             5ms systemd-journald.service
             5ms dev-...f.swap
             4ms systemd-random-seed.service
             4ms dracut-shutdown.service
             3ms systemd-update-utmp-runlevel.service
             2ms systemd-modules-load.service
             2ms systemd-user-sessions.service
             2ms kmod-static-nodes.service
             1ms initrd-udevadm-cleanup-db.service

▶ systemd-analyze

Startup finished in 237ms (kernel) + 724ms (initrd) + 526ms (userspace) = 1.488s

My boot params: loglevel=4 systemd.show_status=auto cgroup_disable=memory ipv6.disable=1 fips=0 resume=/dev/disk/…-part2 elevator=deadline

I use exim instead of postfix, and KDM instead of SDDM, and NetworkManager instead of wicked, all of those start quicker than their SuSE-standard counterparts.
I also generate a custom, uncompressed initial ramdisk using dracut by tinkering with the following lines in my /etc/dracut.conf.d/01-rig-m.conf:

hostonly="yes"
omit_dracutmodules+="img-lib cifs fcoe fcoe-uefi rdma multipath iscsi qemu lvm mdraid dm dmraid pollcdrom plymouth btrfs wacom convertfs"
omit_drivers+="hid-wiimote wacom hv_vmbus rmi_core dm-mod iscsi_if iscsi_tcp dm_multipath parport pcmcia jsm"

Alternatively, I use variants of the following command (your mileage may vary):
** dracut --hostonly --force --no-compress --omit “img-lib cifs fcoe fcoe-uefi rdma multipath iscsi qemu lvm mdraid dm dmraid pollcdrom plymouth btrfs wacom convertfs”
**
I’ve been avoiding EFI boots for 5 years, and I use one large ext4 partition for ‘/’ (i.e., everything but swap). Cheers!

How do you perform warm boot?

My rig is a self-built Core-i5/ASUS/Samsung-SSD box, nothing special.
Would you mind posting output of: inxi -zF

I use exim instead of postfix, and KDM instead of SDDM, and NetworkManager instead of wicked, all of those start quicker than their SuSE-standard counterparts.
I am quite happy with postfix, sddm, wicked and others.

I’ve been avoiding EFI boots for 5 years
Any comment on: https://wiki.debian.org/BootProcessSpeedup Use Linux Kernel as bootloader: On a system which has UEFI , you can bypass all traditional bootloaders(like Grub,Lilo,syslinux etc) and make the UEFI boot the kernel.

Reboot or linger a few seconds in the BIOS or the GRUB CLI — that way, CPU caches, instuction pipelines etc seem to have had enough time to fill or get up to speed, and boot times tend to be a few milliseconds faster. Just some thing I noticed.

Would you mind posting output of: inxi -zF

Here you go (copy-pasted from xterm):

System:    Host: rig Kernel: 4.12.14-lp150.12.25-default x86_64 bits: 64 Desktop: KDE Plasma 5.12.6
           Distro: openSUSE Leap 15.0
Machine:   Device: desktop System: ASUS product: All Series serial: N/A
           Mobo: ASUSTeK model: H87I-PLUS v: Rev X.0x serial: N/A
           BIOS: American Megatrends v: 2003 date: 11/05/2014
Battery    hidpp__0: charge: N/A condition: NA/NA Wh
CPU:       Quad core Intel Core i5-4670 (-MCP-) cache: 6144 KB
           clock speeds: max: 3800 MHz 1: 3400 MHz 2: 3400 MHz 3: 3400 MHz 4: 3400 MHz
Graphics:  Card: NVIDIA GP107 [GeForce GTX 1050]
           Display Server: X.Org 1.19.6 driver: nvidia Resolution: 1920x1200@59.95hz
           OpenGL: renderer: GeForce GTX 1050/PCIe/SSE2 version: 4.5.0 NVIDIA 390.87
Audio:     Card-1 Intel 8 Series/C220 Series High Definition Audio Controller driver: snd_hda_intel
           Card-2 NVIDIA GP107GL High Definition Audio Controller driver: snd_hda_intel
           Sound: Advanced Linux Sound Architecture v: k4.12.14-lp150.12.25-default
Network:   Card: Intel Ethernet Connection I217-V driver: e1000e
           IF: eth0 state: up speed: 100 Mbps duplex: full mac: <filter>
Drives:    HDD Total Size: 376.1GB (40.3% used)
           ID-1: /dev/sda model: Samsung_SSD_850 size: 250.1GB
           ID-2: /dev/sdb model: SanDisk_SDSSDP12 size: 126.0GB
Partition: ID-1: / size: 230G used: 134G (59%) fs: ext4 dev: /dev/sda1
           ID-2: swap-1 size: 8.61GB used: 0.00GB (0%) fs: swap dev: /dev/sdb2
Sensors:   System Temperatures: cpu: 55.0C mobo: N/A gpu: 32C
           Fan Speeds (in rpm): cpu: 0
Info:      Processes: 144 Uptime: 7:27 Memory: 1628.9/7908.9MB Client: Shell (bash) inxi: 2.3.40

I am quite happy with postfix, sddm, wicked and others.

How about Plymouth? It’s the first thing I’ve disabled since SuSE has been using it by default.

I find it reassuring to see that console login for a fraction of a second, and Plymouth tries to cover it up. There is some ongoing development (read it on LKML recently), though, to set the native LCD resolution during early boot and never resetting resolution for text mode nor for display manager nor for the desktop GUI. This should reduce flicker during boot and may also save some time (because Xorg doesn’t have to wait for the graphics hardware to re-initialize), and therefore it might look even prettier and smoother than Plymouth. No idea how this would work with multi-display or multi-head support, though.

Any comment on: https://wiki.debian.org/BootProcessSpeedup Use Linux Kernel as bootloader: On a system which has UEFI , you can bypass all traditional bootloaders(like Grub,Lilo,syslinux etc) and make the UEFI boot the kernel.

Bypassing anything during boot sounds great to me. There are several things I’d like to try out as soon as I have some additional x86 hardware to install SuSE on. Hopefully, I’ll obtain a mainboard that’s supported by one of the open-source EFI projects so I can have a completely open boot chain. Although… it’s just a hobby (system optimization) within a hobby (computer stuff), so to speak. So, things could change quicker than I may be able to give them a spin.

It’s tempting to contemplate my ASUS/AMI BIOS directly bootstrapping kernel+initrd, but I don’t trust closed-source EFI stuff, and I don’t like what knowledgeable hackers had to report about several EFI bugs at conferences. So I still use old-style MBR booting using GRUB2, with single-partition /dev/sda1 on SSD, ext4-formatted — none of that newfangled btrfs rubbish! :wink:

The biggest benefit listed in the Debian page you mentioned is, in my view, good ol’ controversial systemd. I see how UNIX purists dislike aspects of systemd, but I prefer it to the stuff I’ve had to deal with professionally all to often: buggy init scripts inexplicably aborting themselves, disrupting other scripts or halting the whole boot process; then, cron/at variants, all with their own peculiar conf-file syntax, and all too many logging demons (syslog/rsyslog etc). And finally, monitoring and profiling the boot process, which system also does out of the box. I like it. Cheers!

This morning, after installing some dracut/systemd updates, an old vconsole-setup error reared its head again (»systemd-vconsole-setup: loadkeys failed with error code 1«, »cannot open include file compose.latin1«, etc). Having experienced this annoyance several times since openSUSE 42.1 (without an official fix on the horizon yet), a few minutes ago I simply overwrote the original /usr/lib/systemd/systemd-vconsole-setup with /usr/bin/true (i.e., do nothing, return success).

Not only did this solve my recurring vconsole errors, it also sped up boot times again (well, this and the updates, I reckon) — from 1.490s to 1.455s:

▶ systemd-analyze
Startup finished in 229ms (kernel) + 675ms (initrd) + 550ms (userspace) = 1.455s

▶ 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 @546ms
└─display-manager.service @442ms +100ms
  └─systemd-user-sessions.service @438ms +3ms
    └─network.target @438ms
      └─NetworkManager.service @350ms +87ms
        └─dbus.service @312ms
          └─basic.target @311ms
            └─sockets.target @311ms
              └─dbus.socket @311ms
                └─sysinit.target @310ms
                  └─swap.target @310ms
                    └─dev-disk-by\x2duuid…08ff.swap @305ms +5ms
                      └─dev-disk-by\x2duuid…08ff.device @303ms
 ▶ _

The funny thing: my text console seems to work the same as before.
Cheers!

erlangen:~ # inxi -zSM
System:    Host: erlangen Kernel: 4.19.5-1-default x86_64 bits: 64 Console: tty 0 Distro: openSUSE Tumbleweed 20181206 
Machine:   Type: Desktop Mobo: ASRock model: Z170 Pro4S serial: <filter> UEFI: American Megatrends v: P3.50 date: 06/23/2016 
erlangen:~ # 

With Kernel 4.19 there is no flicker. System switches between Plymouth and the ASRock logo.

The biggest benefit listed in the Debian page you mentioned is, in my view, good ol’ controversial systemd. I see how UNIX purists dislike aspects of systemd, but I prefer it to the stuff I’ve had to deal with professionally all to often: buggy init scripts inexplicably aborting themselves, disrupting other scripts or halting the whole boot process; then, cron/at variants, all with their own peculiar conf-file syntax, and all too many logging demons (syslog/rsyslog etc). And finally, monitoring and profiling the boot process, which system also does out of the box. I like it. Cheers!
Init scripts were annoying. Systemd is great. I never looked closer into startup until it arrived at openSUSE.

This morning, after installing some dracut/systemd updates, an old vconsole-setup error reared its head again (»systemd-vconsole-setup: loadkeys failed with error code 1«, »cannot open include file compose.latin1«, etc). Having experienced this annoyance several times since openSUSE 42.1 (without an official fix on the horizon yet), a few minutes ago I simply overwrote the original /usr/lib/systemd/systemd-vconsole-setup with /usr/bin/true (i.e., do nothing, return success).
Had that too. Removed /etc/vconsole.conf and ran “zypper in --force kbd kbd-legacy dracut systemd”: https://forums.opensuse.org/showthread.php/533663-Failed-to-start-Setup-Virtual-Console?p=2886062#post2886062

erlangen:~ # rpm -qf /etc/vconsole.conf
systemd-239-2.1.x86_64
erlangen:~ # cat /etc/vconsole.conf 
KEYMAP=de-nodeadkeys
FONT=eurlatgr.psfu
erlangen:~ #

Just have had two cold boots into openSUSE Leap 15 (multiuser+network+KDM+Plasma), each boot measured by systemd-analyze just so happened to be exactly 1.456 seconds.

  • Startup finished in 225ms (kernel) + 713ms (initrd) + 518ms (userspace) = 1.456s
  • Startup finished in 219ms (kernel) + 729ms (initrd) + 507ms (userspace) = 1.456s

Here’s an animated GIF I’ve made with the two boot charts using GIMP.
Quite the coincidence, methinks!
Anyways, all the best for 2019 and »einen guten Rutsch«, as some German speakers put it these days. Cheers!