Long boot times after kernel update

Ask Fedora
, , , , ,
1

Hello,
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):

boot_old_kernel
boot_old_kernel1920×4566 1.17 MB

boot_new_kernel
boot_new_kernel1920×2262 497 KB

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

2

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?

3

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

4

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:
https://drive.google.com/drive/folders/1l5ttVIW3lOzQOvyUBOwDGv-AVez8_xXW?usp=sharing

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.

5

What line limit?

6

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.

7

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
8

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
  └─systemd-journald.socket
    └─system.slice
      └─-.slice

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.

9

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.

10

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

12

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

13

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.