I’ve been researching ways to improve startup times on my systems (Atati ST, classic MacOS, OS X, Linux) during decades, mostly out of curiosity.
With my most recent openSUSE-Leap-based main desktop (a 5 years old Core i5, Mini-ITX), I’ve tried concentrating on minimalism and simplicity right from the start, and I began systematically reducing boot times while experimenting:
[ul]
[li]6,235s — Leap 42.2 with wicked, IPv6 and Plymouth disabled
[/li][li]3.737s — replace wicked with NetworkManager (and later: use only systemd-networkd with fixed IPv4 address)
[/li][li]3.528s — replace Postfix with Exim
[/li][li]2.992s — ntpd off, smartd off, irqbalance off
[/li][li]2.691s — replace sddm with no-frills minimally configured kdm
[/li][li]2.567s — cupsd off (not doing any printing)
[/li][li]2.326s — reduce grub2 output and kernel/console output to errors only (see below)
[/li][li]2.127s — switch from noop scheduling to deadline
[/li][li]etc, etc… see below.
[/li][/ul]
This lead me to collate a little list of some things to try for you, if you’re so inclined:
[ul]
[li]use one fast SSD — I still think this and the dracut stuff below may been the greatest improvement to any system
[/li][li]use one MBR-style, primary, properly block-aligned ext4 »/« partition (I have no use for btrfs, makes things really simple)
[/li][li]mount options: noatime,acl,user_xattr (no automatic discard/trim, I kick off fstrim manually after each full backup once a month)
[/li][li]no swap, because I don’t use hibernation/sleep/standby
[/li][li]disable Plymouth (unnecessary eye candy)
[/li][li]disable AppArmor (arguably no evidence of additional security)
[/li][li]use unthemed kdm as a display manager (much faster initialization times compared to gdm and sddm)
[/li][li]optimize your graphical session accordingly: no startup animations, no unnecessary agents/frills/helpers/gadgets/widgets/animations/eye candy
[/li][li]use exim (postfix takes a while to initialize) or disable local mail processing altogether
[/li][li]try using [b]systemd-networkd[/b] only (I don’t need wicked’s complexity and slow boot-time initialisations, and I don’t usually use a WLAN at home, so no NetworkManager too)
[/li][li]IF you have a separate firewall: disable SuSEfirewall and other iptables-based filters
[/li][li]in YaST’s »Services Manager«, disable as many services as you are comfortable with, for example bluez, smartd, ModemManager, iscsi, nmb+Samba and — again — Plymouth.
[/li][li]make the kernel just write warnings or errors during boot onto the screen, nothing else; relevant kernel parameters:[/li]```
loglevel=4 systemd.show_status=auto
[li]customize your initial RAM-disk ([i]initrd[/i]) with [b]dracut[/b], e.g. issuing as root user something like: [/li]```
dracut --hostonly --force --omit "img-lib cifs fcoe fcoe-uefi multipath iscsi qemu lvm mdraid dm dmraid pollcdrom plymouth btrfs samba"
Caution! Your needs may differ from mine! — If everything works after a rebooting and testing, make it permanent in a custom dracut config file like /etc/dracut.conf.d/01-my-own-dracut.conf:
hostonly="yes"
compress="cat"
omit_dracutmodules+=" network kernel-network-modules ifcfg img-lib cifs fcoe fcoe-uefi rdma multipath iscsi qemu lvm mdraid dm dmraid cdrom pollcdrom plymouth btrfs wacom convertfs wicked ipv6 mtp-probe warpclock i18n "
omit_drivers+=" usb-storage uas ums-* snd soundcore snd-* hid-wiimote wacom hv_vmbus rmi_core dm-mod iscsi_if iscsi_tcp dm_multipath parport pcmcia jsm cdrom serial "
[li]If you’re not a kernel developer, reduce sizes of kernel objects; as root, do a [/li]```
find /lib/modules -name *.ko -exec strip --strip-unneeded {} +
… this helps dracut to build slightly smaller initrd’s.
[/ul]
Every change helped a bit; the SSD and dracut even in a dramatical fashion, as already mentioned.
So this is my boot from this morning, it’s a pretty typical one:
rig:~ 
systemd-analyze; systemd-analyze blame
Startup finished in 231ms (kernel) + 687ms (initrd) + 387ms (userspace) = 1.306s
110ms systemd-journal-flush.service
89ms udisks2.service
81ms upower.service
77ms display-manager.service
73ms systemd-udevd.service
71ms polkit.service
47ms klog.service
31ms systemd-udev-trigger.service
30ms systemd-tmpfiles-setup.service
21ms user@1000.service
20ms systemd-tmpfiles-setup-dev.service
19ms systemd-update-utmp.service
16ms systemd-modules-load.service
14ms dev-hugepages.mount
14ms systemd-logind.service
13ms systemd-tmpfiles-clean.service
13ms systemd-fsck-root.service
12ms systemd-remount-fs.service
11ms sys-kernel-debug.mount
10ms systemd-sysctl.service
10ms systemd-networkd.service
9ms dev-mqueue.mount
8ms systemd-journald.service
6ms systemd-random-seed.service
5ms dracut-shutdown.service
4ms systemd-update-utmp-runlevel.service
3ms systemd-user-sessions.service
3ms rtkit-daemon.service
2ms kmod-static-nodes.service
1ms systemd-vconsole-setup.service
rig:~ _
The »critical chain«:
rig:~ systemd-analyze critical-chain
graphical.target @382ms
└─display-manager.service @305ms +77ms
└─systemd-logind.service @290ms +14ms
└─basic.target @249ms
└─sockets.target @248ms
└─dbus.socket @248ms
└─sysinit.target @248ms
└─systemd-update-utmp.service @228ms +19ms
└─systemd-tmpfiles-setup.service @197ms +30ms
└─systemd-journal-flush.service @86ms +110ms
└─systemd-remount-fs.service @71ms +12ms
└─systemd-fsck-root.service @584542y 2w 2d 20h 1min 49.362s +13ms
└─systemd-journald.socket
└─-.mount
└─system.slice
└─-.slice
rig:~ _
Finally, using…
systemd-analyze plot > boot.svg
… and using Gimp to convert the SVG to PNG, here’s the accompanying boot plot:
[IMG]https://susepaste.org/images/87486322.png[/IMG]
My best time was a reboot several months ago: 1.211 seconds — a fluke, I guess, when systemd just had its boot jobs arranged perfectly, and with optimal concurrence.
(The fact that a reboot usually re-uses a certain momentum in an already running system with initialized components and full caches etc may have helped too.)
My worst (re)boot time is usually directly after kernel updates, when an additional [i]purge-kernel[/i] job uses several seconds for housekeeping.
I realize that several of my actions may be an absolute [i]no-no[/i] for you guys. For example, you may have external, network-accessible storage, and you may need Samba, ntpd, IPv6, iSCSI etc for that. (I use only SSH for transfers, and I start sshd only on-demand). But I think it’s fun to have at least one system for testing those things out, for optimizing, of course also for learning about all those intricacies and adding knowledge to the personal toolbox.
Cheers!
