Fixing slow boot on Leap 42.2

English Install/Boot/Login
#1

Hi all,

My recent install of Leap 42.2 onto an older computer using a usb cdrom drive came with a prolonged boot time. Using systemd-analyze blame I noticed that the system was looking for the usb cdrom (/dev/sdc), and, that was 17 seconds of the problem.

~> systemd-analyze blame
17.232s dev-sdc1.device
15.210s wicked.service
15.011s systemd-journal-flush.service
14.087s systemd-udevd.service
8.153s ntpd.service
4.024s SuSEfirewall2_init.service

Using Yast-Bootloader-Edit Disk Boot Loader, I added /dev/sda as the primary in the disk boot order. Before that, it had only listed /dev/sdc3. I tried deleting /dev/sdc3 and leaving /dev/sda, but, an error occurred, possibly due to the fact that /dev/sdc is in the boot resume line, or that it shows up in mtab etc.

The most recent systemd-analyze blame starts:
~> systemd-analyze blame
18.874s systemd-journal-flush.service
15.290s wicked.service
5.942s dev-sdc1.device
2.517s display-manager.service
2.370s SuSEfirewall2_init.service

So, I was wondering, could I use dracut to personalize the boot, like I did with Fedora a couple of years back, so it rids the init of the fact that I used the usb cdrom for the install? Or, could I use a better way to fix the problem?

Thanks in Advance
Tom

#2

Will disconnecting the cable of the on board cdrom work in your case since it sounds like a faulty internal optical drive?

#3

I recently had a similar problem.

Turned out, my DVD burner was broken. It was looking for an installation disc that wasn’t there. Disabling it in BIOS worked.

Wicked remains somewhat of a problem. Although a fresh install via an USB stick did reduce the time significantly.

#4

Ever since its introduction, wicked initialized my single DHCP eth0 connection within quite unreliable time limits (up to 4 seconds), leading to similarly prolonged boot times here.
I am now booting within 2.1 seconds into KDE5. I thought I’d list shortly what I’ve tweaked in the meantime, from 2016 to now.

  • 6,235s — Leap 42.2 with wicked, IPv6 disabled
  • 3.737s — replace wicked with NetworkManager
  • 3.528s — replace Postfix with Exim
  • 2.992s — ntpd off, smartd off, irqbalance off, plymouth off
  • 2.691s — replace sddm with kdm
    , no frills - 2.567s — cupsd off; not doing any printing
  • 2.326s — reduce grub2 and kernel output to errors only
  • 2.127s — switch from noop scheduling to deadline

»systemd-analyze blame« now gives me


           243ms dev-sda1.device
           191ms NetworkManager.service
           184ms display-manager.service
           111ms systemd-udevd.service
            93ms systemd-journal-flush.service
            79ms systemd-vconsole-setup.service
            54ms upower.service
            30ms systemd-logind.service
            27ms systemd-update-utmp.service
            26ms polkit.service
            20ms systemd-udev-trigger.service
            …

Still room for improvement with a 4-year-old, bog-standard Core-i5 system with Samsung SSD and Asus board. Happy tuning! :slight_smile:

#5

Is the system partition using the Btrfs file system?

My Leap 42.3 Laptop with a Btrfs system partition was suffering a similar malady for the past few weeks but, for the past few days (System update and/or patch? Or, Btrfs healed itself?) the boot time is about the same as pre-Leap days (without Btrfs).

#6

That’s a good question. I’ve been a single-partition, ext[2—4] user since my first S.u.S.E. v4.2 install in 1996. The ext4 filesystem has proved itself beyond any doubt to be reliable and robust, with extremely predictable timing. (Just think about all those Android phones and tablets running ext4 — as a mere user, you wouldn’t ever know there was some Unix filesystem underneath, and that’s just the way it’s supposed to be.)

Since about ten years ago, when system RAM went up from 256 MB to 8 GB and more, I even ditched the swap partition on most systems. Now, all my SSDs are one ext4-formatted volume with its partition boundaries adjusted for access speed (multiple of 4k blocks, I think). If I ever wanted or needed swap, I could dynamically generate and mount a few gigs of swap file, but that need never has never arisen.

I like many of the concepts and features BTRFS implements, its flexibility and so on, but I don’t need any of it, and I don’t consider btrfs nearly as trustworthy as ext4. At work, we have hundreds of server systems set up with all kinds of configurations, distros, partition layouts and optimizations. Most of them (roughly 90%) them use ext4, some use XFS, but none use btrfs. We just don’t use customer data as guinea pigs for the newest, latest and greatest (?) filesystem, ever.

#7

Quick addendum: over a year later, and with openSUSE Leap 15 growing on me, and with most of the KDE/Plasma5 quirks ironed out, my best boot time was 1.378s.
Considering it was a reboot with the hardware already initialized and caches pre-filled, I should mention my fastest documented cold boot as well: 1.391s.

I achieved this with what I listed here upthread (6-Dec-2017, 10:40), but having one single, large, old-school primary ext4 partition exclusive on one fast SSD was part of it.

Another big part that helped me to go from average 2.5s boot times to around 1.5s was the little extra effort, after each kernel or driver update, generating a custom and uncompressed (!) initial RAM disk with:

dracut --verbose --hostonly --force --no-compress --omit "img-lib cifs fcoe fcoe-uefi rdma multipath iscsi qemu lvm mdraid dm dmraid cdrom pollcdrom plymouth btrfs wacom convertfs wicked ipv6 mtp-probe"

Caution: DO NOT blindly copy this into your root shell, because you may need btrfs or ipv6 or one of the other modules omitted here.

My uncompressed initrd is just over 50 MB, which seems a waste of space compared to a compressed one of around 17 MB. However, my SSD can apparently load 50 MB much faster than my Core i5 CPU could decompress those 17 MB into RAM.

Of course, systemd-analyze only measures what it can. Before it, there’s about 1s of BIOS initialisation and bootstrap, maybe a 10th of a second for GRUB2 to load kernel and initrd, and after systemd started the display manager (superfast and bare-bones KDM in my case), another second for KDE5/Plasma to start everything. So, measuring with a stopwatch from the power button to my xterm results in about about 3.5 seconds. Still, pretty quick. :wink:

Finally, if your network is secured against attacks and malware, you could experiment with disabling SuSEFirewall, AppArmor and most in-kernel Spectre/Meltdown patches (kernel params: pti=off spectre_v2=off l1tf=off nospec_store_bypass_disable no_stf_barrier) in order to make things even more responsive, but that may be pushing it. Cheers!

#8

The last few posts on this thread have nothing to do with Fixing Slow Boot on Leap 42.2 … and 42.2 is out of support.

So, this thread is closed.

To discuss boot issues about 15.0 or other current, join a suitable thread or start your own.

This thread is closed.