Improving boot speed | Fedora 40 |

The Water Cooler
21

I’m curious to try my setup since it’s very fast. I believe it’s in part because of systemd-boot

systemd-analyze blame --no-pager

3.166s plymouth-quit-wait.service
 2.937s abrtd.service
 1.284s initrd-switch-root.service
  849ms NetworkManager.service
  699ms dkms.service
  326ms firewalld.service
  287ms ModemManager.service
  266ms upower.service
  253ms systemd-udev-trigger.service
  195ms udisks2.service
  185ms user@1000.service
  171ms power-profiles-daemon.service
  166ms accounts-daemon.service
  157ms polkit.service
  151ms systemd-tmpfiles-setup.service
  133ms systemd-vconsole-setup.service
  116ms systemd-logind.service
  115ms dracut-cmdline.service
  104ms chronyd.service
  100ms systemd-tmpfiles-setup-dev-early.service
   97ms systemd-journal-flush.service
   86ms systemd-udevd.service
   83ms systemd-resolved.service
   78ms systemd-tmpfiles-clean.service
   76ms lvm2-monitor.service
   76ms avahi-daemon.service
   75ms systemd-fsck@dev-disk-by\x2duuid-C710\x2d1353.service
   75ms systemd-oomd.service
   71ms bluetooth.service
   71ms systemd-zram-setup@zram0.service
   71ms switcheroo-control.service
   69ms passim.service
   67ms var-lib-nfs-rpc_pipefs.mount
   66ms geoclue.service
   64ms lm_sensors.service
   62ms systemd-journald.service
   53ms dbus-broker.service
   51ms rtkit-daemon.service
   42ms virtqemud.service
   40ms dev-zram0.swap
   39ms dracut-pre-pivot.service
   39ms dracut-shutdown.service
   39ms livesys.service
   39ms home.mount
   37ms systemd-boot-update.service
   36ms colord.service
   36ms systemd-boot-random-seed.service
   34ms systemd-backlight@backlight:amdgpu_bl1.service
   34ms systemd-tmpfiles-setup-dev.service
   33ms systemd-binfmt.service
   33ms thermald.service
   31ms gssproxy.service
   31ms systemd-machined.service
   31ms auditd.service
   30ms audit-rules.service
   29ms systemd-userdbd.service
   29ms import-state.service
   28ms cups.service
   28ms unbound-anchor.service
   25ms plymouth-start.service
   23ms plymouth-switch-root.service
   22ms systemd-machine-id-commit.service
   22ms livesys-late.service
   21ms dev-hugepages.mount
   21ms uresourced.service
   19ms plymouth-read-write.service
   19ms systemd-remount-fs.service
   19ms systemd-sysctl.service
   19ms dracut-pre-udev.service
   19ms dev-mqueue.mount
   19ms sssd-kcm.service
   18ms sys-kernel-debug.mount
   17ms sys-kernel-tracing.mount
   17ms boot-efi.mount
   17ms gdm.service
   16ms tmp.mount
   16ms systemd-fsck-root.service
   16ms kmod-static-nodes.service
   14ms initrd-parse-etc.service
   14ms rpc-statd-notify.service
   14ms systemd-user-sessions.service
   14ms flatpak-system-helper.service
   13ms initrd-cleanup.service
   13ms modprobe@fuse.service
   12ms wpa_supplicant.service
   12ms raid-check.service
   12ms systemd-random-seed.service
   12ms systemd-modules-load.service
   11ms systemd-network-generator.service
   11ms systemd-sysusers.service
   11ms user-runtime-dir@1000.service
   10ms proc-sys-fs-binfmt_misc.mount
    9ms systemd-rfkill.service
    9ms initrd-udevadm-cleanup-db.service
    9ms modprobe@loop.service
    8ms systemd-update-utmp-runlevel.service
    7ms systemd-update-utmp.service
    7ms modprobe@configfs.service
    6ms sys-fs-fuse-connections.mount
    6ms modprobe@dm_mod.service
    4ms modprobe@drm.service

systemd-analyze critical-chain

graphical.target @12.904s
└─multi-user.target @12.904s
  └─plymouth-quit-wait.service @9.735s +3.166s
    └─systemd-user-sessions.service @9.717s +14ms
      └─remote-fs.target @9.702s
        └─remote-fs-pre.target @4.365s
          └─nfs-client.target @4.365s
            └─gssproxy.service @4.332s +31ms
              └─network.target @4.318s
                └─wpa_supplicant.service @4.305s +12ms
                  └─basic.target @2.521s
                    └─dbus-broker.service @2.465s +53ms
                      └─dbus.socket @2.443s
                        └─sysinit.target @2.437s
                          └─systemd-resolved.service @2.354s +83ms
                            └─systemd-tmpfiles-setup.service @2.172s +151ms
                              └─import-state.service @2.141s +29ms
                                └─local-fs.target @2.116s
                                  └─opt-piavpn-etc-cgroup-net_cls.mount @6.520s
                                    └─local-fs-pre.target @1.227s
                                      └─systemd-tmpfiles-setup-dev.service @1.192s +34ms
                                        └─systemd-tmpfiles-setup-dev-early.service @1.070s +100ms
                                          └─kmod-static-nodes.service @1.049s +16ms
                                            └─systemd-journald.socket
                                              └─system.slice
                                                └─-.slice
1 Like
22

From Ask Fedora to The Water Cooler

23

Added tech-talk and removed f40, gnome

24

That is interesting, are you able to share your systemd-analyze output?

1 Like
25

systemd-analyze

Startup finished in 4.824s (firmware) + 256ms (loader) + 1.105s (kernel) + 32.640s (initrd) + 12.926s (userspace) = 51.752s 
graphical.target reached after 12.904s in userspace.

Which reminds me I need to clean up my /boot which i normally do after a upgrade.

A question of whether password complexity is involved in the count to reach graphical target :thinking:

1 Like
26

Cheers, do you have multiple OS boot options? Or just fedora?

Clutching at straws, how about secure boot turned on or off?

Trying to think what’s unique :thinking:

27

systemd-boot and Only Fedora 40

SecureBoot Off

:thinking:

1 Like
28

This is interesting - do you have any guidance on how I can migrate over to systemd-boot from the default GRUB loader please? I use F40 as my daily driver, there is one other F36 as recovery and an older Windows entry which I will happily purge in the process if needed…

I’ve tried this and rebooted a few times, its gone up and down a few times for loader but nothing consistent…

Startup finished in 8.506s (firmware) + 9.379s (loader) + 2.313s (kernel) + 3.425s (initrd) + 17.614s (userspace) = 41.239s
graphical.target reached after 17.584s in userspace. ```
1 Like
29

In many years of using fedora I have never seen anything in /boot that required a manual cleanup. What is causing that need for you?

1 Like
30

What’s going on there? Most I’ve seen was 6 seconds

31

I had no notable boot speed differences with systemd-boot and GRUB on openSUSE TW yesterday; I think GRUB was actually a tiny bit faster due to something with custom dracut configs not being applied with oS’s systemd-boot implementation (I do cat/uncompressed initrd from dracut), and I had to manually do bootctl cleanup after generating a few initrds; way too much intervention for a boot loader I see for 5 seconds :stuck_out_tongue:

I’ve wanted to try systemd-boot for a while, and inst.sdboot didn’t work on F39 or 40. Now that I tried it, I’m not sure what’s the benefit of it is speed-wise, and it fit in 512 MB /boot still like GRUB

32

In many years of using fedora I have never seen anything in /boot that required a manual cleanup. What is causing that need for you?

This:
$ grep saved /etc/default/grub
GRUB_DEFAULT=“saved”

34

I have a veeeeeery long reply for this, Which i have rewritten 3x already :laughing: . So I’ll post this later because it requires a couple tangent talks, and things I learned about dnf system-upgrade too.

I do, but maybe I should explain the how’s and the why’s as well beforehand?

35

That applies to the kernel used for next boot and has nothing to do with the amount or type of data stored in /boot/. It does not affect the data stored nor the update process.

36

my bad. you’re totally right. been a long time i visited this config, maybe 5-6 months.

this however could require manual cleanup periodically:

$ grep limit /etc/dnf/dnf.conf
installonly_limit=5

37

yes please, if you have the time, it’d be much appreciated.

1 Like
38

Likely running systemd-boot. I do and I have to occasionally clean up the /boot as well as point to a new kernel if one was installed. It is still manual with systemd-boot AFAIK

39

Currently my userspace is the time hog, it takes 1min 47.785s to reach the graphical target, which is the bulk of my 2min 15.229s total startup time. I feel for most it will be in the userspace startup that you will make some available gains in startup time. I personally have gotten into the habit of turning on my PC then make coffee, it keeps me from dwelling on time wasted starting my PC. I choose to multi task in those moments.

1 Like
40

Got my boot up time down thanks to finding a configuration issue that became evident after a recent update, and trying to tune some of my btrfs mount settings. Now I start up much faster …

systemd-analyze
Startup finished in 6.248s (firmware) + 431ms (loader) + 3.188s (kernel) + 3.400s (initrd) + 58.869s (userspace) = 1min 12.137s
graphical.target reached after 58.848s in userspace.

41

Congrats for the progress Stephen.

Something’s still wrong here. On computers where I have linux installed, I still have windows 7 and the latter takes only seconds to boot.

What happened to the linux kernel to be such a hog (bloated) over the years? I remember kernels 2.2 and 2.4 booting in seconds on a 386 pc. Things began to deteriorate at 2.6 and were definetely worstened with kernel 3 and up. Not really a rant, only an observation.

Out of curiosoty, I asked the question to an AI and been answered newer kernels contained optimisations for newer hardware to be faster. Why does it have the contrary effect, then? The discussion practically ended there.

Even DOS machines were faster when BIOS still contained interrupt 10 instead of relying on graphic mode to display everything. They removed interrupt 10 from graphic cards around 1994 and display were tremendously slower from there on. Remember nnansi? It was so fast that it was impossible to read anything from a 386 booting, or from a type command (equivalent to linux ‘cat’). On a 386sx33!