Long boot times after kernel update

I have used Fedora for a couple of months now and I am very happy with it for the most part. What has bothered me tho were the long boot times compared to other distros.
Where a Debian or Arch system have booted in a few seconds on my machine, Fedora takes up to half a minute and other times even longer.

Thats why I was happy to see that the kernel update “6.9.4-200.fc40.x86_64”, seemed to fix my problem. Boot times where a lot faster and on par with the other distros.

Shortly after tho, another update to the kernel “6.9.5-200.fc40.x86_64”, brought back the problem and boot times were as slow as before.
Knowing that the problem can be and has been fixed in the old version of the kernel, I decided to ask for help here.

Here is some information about the system I am running:

Mainboard: Gigabyte AB350-Gaming 3
CPU: AMD Ryzen 7 2700
GPU: Zotac GeForce GTX 1070 Ti
SSD: Samsung 990 PRO 2TB
OS: Fedora 40 dual booted with Windows 10 (tho I have tried it with a fresh install of Fedora as well)

I am running the NVIDIA proprietary driver version “550.90.07” from RPM Fusion. Using the open source nouveau driver does reduce boot times a few seconds but nothing significant.
What I have also noticed, is that running Fedora inside of a virtual machine does not have the same problem and boot times are as expected there. So I think it has something to do with my system configuration.

Here are also the results of systemd-analyze plot for both the kernel versions (sorry for the file size I didn’t find a way to append svg files):

Hope this helps identifying my problem.
Thanks in advance for any help :slight_smile:

Sorry I cannot read those images.
What does systemd-analyse blame and systemd-analyse critical-path report?

The other thing you can do is while the system is booting type ESC to remove the splash screen and show the boot messages. What is it doing when it get stuck?

You could use fpaste <filename> to upload the svg file then paste the link it provides here so we could download it and look at the image.
Your screenshots are not capable of being enlarged and become readable. The data is just too small to be expanded and not become pixelated

So I have run the systemd-analyze blame and systemd-analyze critical-chain commands for both kernel versions (again the old kernel being with the fast boot time and the new with the slow boot time).
I will post the output in my following reply, because this one exceeded the line limit.

I also uploaded the svg files to my Google Drive for you to download if needed:

One thing I want to add is that the delay can be observed when it shows the message, that the kernel is loading. So right after GRUB shows you the available kernel versions to boot from.

I removed the “quiet” line from the GRUB configuration file to see what it is getting stuck on and I found out that it stopped right at the end of the kernel initialization at the line:
[ OK ] Mounted sys-kernel-config.mount - Kernel Configuration File System.

After that, I get to type in the encryption passphrase for the drive and the rest of the boot process continues normally on both kernel versions.

Edit: Because I am a new user on this platform, I can only mention 2 users in a post, so I am not able to make a follow up post. Instead, I also included the output of the commands in the Google Drive link.

Again thanks for the help.

What line limit?

This forum does have a line limit for length of a single post. Not sure of what it is, but I have hit it more than once.

Svg files and often journalctl output may exceed the allowed length.

Looking at the svg file for the new kernel it seems that systemd-ask-password-plymouth.service starts at about 3.5 seconds into the boot then does not continue until about 51 seconds in when it appears the drive is unlocked and boot continues to complete at about 61 seconds total from the time the kernel begins loading. The bios takes an additional ~18 seconds for firmware and boot loader.

With the old kernel the numbers are similar except the systemd-ask-password-plymouth.service starts at about the same 3.5 seconds but ends at about 14 seconds. Total boot time is about 25.5 seconds plus 14+ seconds for firmware & boot loader.

With the old kernel the loader takes about 3.5 seconds and with the new kernel the loader takes about 7 seconds, or twice as long.

Analyzing the details it seems that with the new kernel it is taking about 49+ seconds to configure the hardware devices and with the old kernel it is only taking about 13 seconds to do the same. This seems to mean that the hardware config is adding at least 36 seconds to the boot time with the newer kernel.

I have no suggestions about why or how to change that, this is just an observation based on available information.

The only comment I have about the systemd-analyze critical-chain info is to note this for the new kernel.

                                  └─boot.mount @1.980s +11ms
                                    └─systemd-fsck@dev-disk-by\x2duuid-d9f43561\x2dc83d\x2d40c9\x2d9bf1\x2d9c73abe4097f.service @1.431s +35ms
                                      └─dev-disk-by\x2duuid-d9f43561\x2dc83d\x2d40c9\x2d9bf1\x2d9c73abe4097f.device @584542y 2w 2d 20h 1min 33.872s +17.088s
1 Like

Yea I have noticed that as well, there are some things written in the log of the new kernel that are not present in the old one.
More precisely, the two files differ in the last few lines here:

Old kernel:

└─systemd-vconsole-setup.service @5.098s +71ms

New kernel:

└─systemd-resolved.service @2.224s +99ms
  └─systemd-tmpfiles-setup.service @2.026s +164ms
    └─local-fs.target @2.016s
      └─boot-efi.mount @1.995s +20ms
        └─boot.mount @1.980s +11ms
          └─systemd-fsck@dev-disk-by\x2duuid-d9f43561\x2dc83d\x2d40c9\x2d9bf1\x2d9c73abe4097f.service @1.431s +35ms
            └─dev-disk-by\x2duuid-d9f43561\x2dc83d\x2d40c9\x2d9bf1\x2d9c73abe4097f.device @584542y 2w 2d 20h 1min 33.872s +17.088s

Other than that the times are very similar in both logs.

I don’t really know what they mean, it is just something that I have noticed comparing the two files. Especially this last line here in the new kernel: @584542y 2w 2d 20h 1min 33.872s +17.088s
Don’t know where these numbers came from but it seems odd.

Is it possible that this could be a bug of some sorts? Again, other distros don’t seem to have this problem.

Hello again,
I wanted to bring a little attention to this topic again since it got a bit lost.
Does anyone have an idea why this happens on my machine? Is it possible that this could be a bug of some sorts? Again, other distros don’t seem to have this problem.

Also when running inside of a virtual machine, Fedora boots within a few seconds on the same machine. So the problem does not occur there.

We have not seen the actual machine hardware listing nor the arch. Please post the output of inxi -Fzxx for us.

Sure here is the output:

  Kernel: 6.9.8-200.fc40.x86_64 arch: x86_64 bits: 64 compiler: gcc
    v: 2.41-37.fc40
  Desktop: GNOME v: 46.3.1 tk: GTK v: 3.24.42 wm: gnome-shell dm: GDM
    Distro: Fedora Linux 40 (Workstation Edition)
  Type: Desktop System: Gigabyte product: AB350-Gaming 3 v: N/A
    serial: <superuser required>
  Mobo: Gigabyte model: AB350-Gaming 3-CF serial: <superuser required>
    UEFI: American Megatrends LLC. v: F53 date: 03/22/2024
  Info: 8-core model: AMD Ryzen 7 2700 bits: 64 type: MT MCP arch: Zen+ rev: 2
    cache: L1: 768 KiB L2: 4 MiB L3: 16 MiB
  Speed (MHz): avg: 1835 high: 3850 min/max: 1550/3850 boost: enabled cores:
    1: 1550 2: 1550 3: 1550 4: 1550 5: 1550 6: 1550 7: 1550 8: 3840 9: 1550
    10: 3850 11: 1550 12: 1550 13: 1527 14: 1550 15: 1550 16: 1550
    bogomips: 122968
  Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm
  Device-1: NVIDIA GP104 [GeForce GTX 1070 Ti] vendor: ZOTAC driver: nvidia
    v: 555.58.02 arch: Pascal pcie: speed: 5 GT/s lanes: 16 ports: active: none
    off: DP-1,HDMI-A-1 empty: DP-2,DP-3,DVI-D-1 bus-ID: 07:00.0
    chip-ID: 10de:1b82
  Display: wayland server: X.org v: 1.20.14 with: Xwayland v: 24.1.1
    compositor: gnome-shell driver: X: loaded: nvidia unloaded: modesetting
    alternate: fbdev,nouveau,nv,vesa gpu: nvidia,nvidia-nvswitch display-ID: 0
  Monitor-1: DP-1 model: Samsung LC27RG50 res: 1920x1080 dpi: 92
    diag: 613mm (24.1")
  Monitor-2: HDMI-A-1 model: Samsung S24C300 res: 1920x1080 dpi: 92
    diag: 609mm (24")
  API: OpenGL v: 4.6.0 vendor: nvidia v: 555.58.02 glx-v: 1.4
    direct-render: yes renderer: NVIDIA GeForce GTX 1070 Ti/PCIe/SSE2
    display-ID: :0.0
  API: EGL Message: EGL data requires eglinfo. Check --recommends.
  Device-1: NVIDIA GP104 High Definition Audio vendor: ZOTAC
    driver: snd_hda_intel v: kernel pcie: speed: 8 GT/s lanes: 16
    bus-ID: 07:00.1 chip-ID: 10de:10f0
  Device-2: AMD Family 17h HD Audio vendor: Gigabyte driver: snd_hda_intel
    v: kernel pcie: speed: 8 GT/s lanes: 16 bus-ID: 09:00.3 chip-ID: 1022:1457
  Device-3: Solid State System FIFINE K669 Microphone
    driver: hid-generic,snd-usb-audio,usbhid type: USB rev: 1.1 speed: 12 Mb/s
    lanes: 1 bus-ID: 3-1:2 chip-ID: 3142:0100
  API: ALSA v: k6.9.8-200.fc40.x86_64 status: kernel-api
  Server-1: JACK v: 1.9.22 status: off
  Server-2: PipeWire v: 1.0.7 status: active (process) with:
    1: pipewire-pulse status: active 2: wireplumber status: active
    3: pipewire-alsa type: plugin
  Device-1: Realtek RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet
    vendor: Gigabyte driver: r8169 v: kernel pcie: speed: 2.5 GT/s lanes: 1
    port: f000 bus-ID: 04:00.0 chip-ID: 10ec:8168
  IF: eno1 state: up speed: 1000 Mbps duplex: full mac: <filter>
  Device-1: Cambridge Silicon Radio Bluetooth Dongle (HCI mode) driver: btusb
    v: 0.8 type: USB rev: 2.0 speed: 12 Mb/s lanes: 1 bus-ID: 1-9:4
    chip-ID: 0a12:0001
  Report: btmgmt ID: hci0 rfk-id: 0 state: down bt-service: enabled,running
    rfk-block: hardware: no software: yes address: <filter> bt-v: 4.0 lmp-v: 6
  Local Storage: total: 4.09 TiB used: 908.7 GiB (21.7%)
  ID-1: /dev/nvme0n1 vendor: Samsung model: SSD 990 PRO 2TB size: 1.82 TiB
    speed: 63.2 Gb/s lanes: 4 serial: <filter> temp: 35.9 C
  ID-2: /dev/sda vendor: Samsung model: SSD 860 EVO 500GB size: 465.76 GiB
    speed: 6.0 Gb/s serial: <filter> temp: 25 C
  ID-3: /dev/sdb vendor: Seagate model: ST2000VM003-1ET164 size: 1.82 TiB
    speed: 6.0 Gb/s serial: <filter> temp: 28 C
  ID-1: / size: 1.82 TiB used: 70.41 GiB (3.8%) fs: btrfs dev: /dev/dm-0
    mapped: luks-6bbed41d-7be3-41e4-8b34-83327c265598
  ID-2: /boot size: 973.4 MiB used: 437.8 MiB (45.0%) fs: ext4
    dev: /dev/nvme0n1p2
  ID-3: /boot/efi size: 598.8 MiB used: 19 MiB (3.2%) fs: vfat
    dev: /dev/nvme0n1p1
  ID-4: /home size: 1.82 TiB used: 70.41 GiB (3.8%) fs: btrfs dev: /dev/dm-0
    mapped: luks-6bbed41d-7be3-41e4-8b34-83327c265598
  ID-1: swap-1 type: zram size: 8 GiB used: 0 KiB (0.0%) priority: 100
    dev: /dev/zram0
  System Temperatures: cpu: 33.8 C mobo: 26.0 C
  Fan Speeds (rpm): cpu: 0 fan-1: 0 fan-3: 0
  Power: 12v: N/A 5v: N/A 3.3v: 3.33 vbat: 2.86
  Memory: total: 16 GiB available: 15.53 GiB used: 2.32 GiB (14.9%)
  Processes: 418 Power: uptime: 9m wakeups: 0 Init: systemd v: 255
    target: graphical (5) default: graphical
  Packages: pm: flatpak pkgs: 21 Compilers: gcc: 14.1.1 Shell: Bash
    v: 5.2.26 running-in: gnome-terminal inxi: 3.3.34

I edited your post and turned off the blockquote " and turned on the preformatted text </> so it appears exactly as formatted on your screen. Please use the </> instead of blockquote in the future.

That looks entirely normal, Now please show us the result of timedatectl

My experience has been that users complaining of systems getting very slow
was often a pre-fail indicator for mass storage device.

Do you have anything in /etc/tmpfiles.d?

Here I see: @584542y 2w 2d 20h 1min 47.528s +3.506s for a 6TB external USB drive. Searching for systemd-analyze critical-chain @584542y . This is a bug, but I don’t think it affects boot times.

This is the result of timedatectl:

               Local time: Di 2024-07-16 21:18:18 CEST
           Universal time: Di 2024-07-16 19:18:18 UTC
                 RTC time: Di 2024-07-16 19:18:18
                Time zone: Europe/Berlin (CEST, +0200)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no
1 Like

The /etc/tmpfiles.d folder is empty.

1 Like