Startup time longer in F31 than F30

Has anyone else experience longer startup/boot times on Fedora 31 than on 30?

Startup now takes noticeably longer before and after the LUKS password prompt. It takes me a while to enter my long password, but 1 minute 22 seconds is still much longer than I expect on a modern system with an SSD.

$ systemd-analyze time
Startup finished in 22.833s (firmware) + 5.129s (loader) + 4.690s (kernel) + 33.586s (initrd) + 16.015s (userspace) = 1min 22.255s reached after 10.154s in userspace
$ systemd-analyze blame
32.819s dracut-initqueue.service                                               >
23.258s systemd-cryptsetup@luks\[]                                             >
 9.725s NetworkManager-wait-online.service                                     >
 3.775s plymouth-quit-wait.service                                             >
 2.659s firewalld.service                                                      >
 2.386s akmods.service                                                         >
 2.372s x2gocleansessions.service                                              >
 2.316s udisks2.service                                                        >
 2.271s ModemManager.service                                                   >
 2.136s accounts-daemon.service                                                >
 2.092s lightdm.service                                                        >
 2.054s systemd-udev-settle.service                                            >
 1.220s abrtd.service                                                          >
 1.214s dkms.service                                                           >
 1.103s systemd-journal-flush.service                                          >
  964ms libvirtd.service                                                       >
  895ms polkit.service                                                         >
  791ms lvm2-monitor.service                        
$ systemd-analyze critical-chain dracut-initqueue.service
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.

dracut-initqueue.service +32.819s
└─systemd-udev-trigger.service @592ms +69ms
  └─systemd-udevd-kernel.socket @582ms


Try add a bit more of information:

(after that your system is booted)

1. dmesg information

You can paste the content directly here, in fedora paste or with the command dmesg | fpaste

2.systemd-analyze plot

Print an image of the load times
systemd-analyze plot > ~/output.svg

And attach the image what will be saved in the path /home//output.svg.

it is important information than can help, you can also try to see what both files show at the time the delay starts.


Thanks for the suggestions.

dmesg output:

systemd-analyze plot:

Hi @fasulia;

Both devices appear as Keyboards, the Logitech M720 Triathlon mouse appears only as Keyboard. I don’t know if this is normal or not when using the Logitech Unifying Receiver. If you look there is a delay between the recognition of your keyboard and your mouse a little more than 20 seconds after the password request appears.

Try disconnecting one of them, disconnecting the keyboard after entering the password, changing the keyboard or disconnecting the mouse.

It may be a bug in the current kernel, if you have other kernels try another and compare the outputs of dmesg and systemd-analyze plot.

Maybe someone can contribute a little more.

[    5.612343] logitech-hidpp-device 0003:046D:4032.0007: input,hidraw4: USB HID v1.11 Keyboard [Logitech K830] on usb-0000:01:00.0-13/input2:2
[   15.773146] logitech-hidpp-device 0003:046D:4032.0007: HID++ 4.1 device connected.
[   28.431131] audit: type=1130 audit(1573790619.179:10): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel

Or simply it is just a problem with luks and the time than it takes to unlock this.

Hmm… I’m not sure I follow. I have a Logitech Unifying Receiver, and a M720 mouse and K830 keyboard with trackpad paired to it. The K830 is sometimes detected as both a keyboard and mouse due to the built-in pointing device. In any case I don’t see this as being involved in the delay.

It can take me ~15 seconds to enter my LUKS password, and more if I make a mistake, so the time for the cryptsetup section isn’t too surprising to me. It’s the overall 1m22s that’s just rather long.

After the F31 upgrade, I noticed longer pauses on the boot screen after mentions of dracut before the LUKS password and also a pause after. But it’s difficult to read and remember boot messages.

The only times what look a bit too much to me are related with the load of firmware 22 s and initrd 33 s. About firmware i don’t know if you can do too much and about initrd time the delay is coming after you did put the password so it looks like than this is the time that the system need to be unlocked.

Try locate them trough journalctl:

journalctl --list-boots

journalctl -b <numer of boot you wish see>

for example journalctl -b -3

or for example

journalctl --since "2019-11-8" --until "2019-11-15 03:00"

More information man journalctl


I took a look at the logs again and again. Nothing stands out to me.

Yes, not much can be done about the firmware. I compared with an older weaker system which boots more quickly (~50s). Aside from firmware and the password entry in initrd, kernel loading time was about half (2s vs 4s) and a few other small differences.

I don’t reboot often so it’s not really worth putting much more effort into this, but it’s still surprising and a bit disappointing to wait over a minute on a modern system. I guess I would expect 10-30s on a recent system with a modern OS with a SSD. At the very least I don’t expect boot time to get worse after upgrading the OS.

In any case, thanks for taking a look and for your troubleshooting suggestions.

1 Like