GRUB2 takes way too long to load kernel and initrd

Ask Fedora
1

GRUB2 takes too long to load the necessary files, by this I mean the time from selecting a fedora kernel to the LUKS prompt appearing.

This problem actually started way back, when I finally upgraded to a SATA SSD from an HDD, which made boot slower for Linux, and my patience finally ran out.

As for the exact numbers:

Output of systemd-analyze time:

Startup finished in 7.106s (firmware) + 1min 17.573s (loader) + 1.322s (kernel) + 34.012s (initrd) + 13.299s (userspace) = 2min 13.314s
graphical.target reached after 13.299s in userspace.

now using a chronometer, I found that the time from selection of boot entry to LUKS prompt is approx. 1m 26s, with most time being wasted on GRUB loading files.

As for the file sizes:

initramfs weighs 139mb despite being made with --host-only
vmlinuz is at 17mb

Please remember that even an HDD did not struggle loading these sizes on GRUB, this is a healthy SSD and reading these files is supposed to take a fragment of a second:

❯ sudo time cat initramfs-6.19.11-200.fc43.x86_64.img vmlinuz-6.19.11-200.fc43.x86_64 >/tmp/something
0.00user 0.05system 0:00.05elapsed 98%CPU (0avgtext+0avgdata 2228maxresident)k
0inputs+0outputs (0major+215minor)pagefaults 0swaps

When I was on Void Linux, I worked around this by crafting a feather-light 2mb initrd and used EFI-stub (the heavy initrd did not play well with EFI stub either), however that only worked because init was simple and no LUKS or systemd was involved, not to mention whatever Fedora uses for offline upgrades.

I don’t know if this is the right place to post this, as I am very sure this isn’t exclusive to Fedora, but an issue with GRUB, I did not find a proper place for posting such problems.

Sorry for the long post, this is just years of frustration with windows11-on-hdd levels of boot slowness.

What should I do to solve this boot time problem?

Any help would be appreciated, and thank you.

some extra informations about the computer:

System:
  Kernel: 6.19.11-200.fc43.x86_64 arch: x86_64 bits: 64
  Desktop: KDE Plasma v: 6.6.4 Distro: Fedora Linux 43 (KDE Plasma Desktop
    Edition)
Machine:
  Type: Desktop Mobo: ASRock model: H310M-DGS serial: <superuser required>
    Firmware: UEFI vendor: American Megatrends v: P3.00 date: 07/16/2018
CPU:
  Info: 6-core model: Intel Core i5-8400 bits: 64 type: MCP cache: L2: 1.5 MiB
  Speed (MHz): avg: 800 min/max: 800/4000 cores: 1: 800 2: 800 3: 800 4: 800
    5: 800 6: 800
Graphics:
  Device-1: NVIDIA GP107 [GeForce GTX 1050 Ti] driver: nvidia v: 580.126.18
  Display: wayland server: Xwayland v: 24.1.9 compositor: kwin_wayland
    driver: gpu: nvidia,nvidia-nvswitch
Drives:
  ID-1: /dev/sda vendor: TeamGroup model: T253256GB size: 238.47 GiB
Info:
  Memory: total: 16 GiB available: 15.53 GiB used: 6.78 GiB (43.7%)
  Processes: 415 Uptime: 1h 11m Shell: Bash inxi: 3.3.40

grub version:

❯ dnf repoquery --installed 'grub2*'
grub2-common-1:2.12-43.fc43.noarch
grub2-efi-ia32-1:2.12-43.fc43.x86_64
grub2-efi-ia32-cdboot-1:2.12-43.fc43.x86_64
grub2-efi-x64-1:2.12-43.fc43.x86_64
grub2-efi-x64-cdboot-1:2.12-43.fc43.x86_64
grub2-efi-x64-modules-1:2.12-43.fc43.noarch
grub2-pc-1:2.12-43.fc43.x86_64
grub2-pc-modules-1:2.12-43.fc43.noarch
grub2-tools-1:2.12-43.fc43.x86_64
grub2-tools-efi-1:2.12-43.fc43.x86_64
grub2-tools-extra-1:2.12-43.fc43.x86_64
grub2-tools-minimal-1:2.12-43.fc43.x86_64
2

Your bios is extremely old and that mobo has newer bios dated 1/2/2020
https://www.asrock.com/MB/Intel/H310M-DGS/index.asp#BIOS

I strongly suggest that you update the bios for better support for newer kernels then try again.

Also please be aware that the GTX 1050 GPU will not be supported by the 595 driver that is coming out with the upgrade to f44. You will need to update the nvidia driver to the 580xx legacy version before upgrading to the upcoming f44 release.

3

Check

 sudo dmesg

and/or

journalctl -k

to find out any specific issues.
Something is definitely off, SSD vs. HDD wouldn’t make a big difference for just bringing up the Luks unlock screen.

4

Thank you for the quick reply, I will try updating the BIOS and see if it helps.

Also huge thanks for the heads-up about the GPU driver, you might have just saved me multiple hours of frustration in advance!

5

Yes I find it really weird that booting takes almost 2 minutes on an SSD, and that an HDD outperforms it by a large margin!, I doubted the SSD at first however it really seems optimal once the Linux kernel boots.

I just checked the kernel logs as suggested, no abnormality of note was observed, aside from the usual ACPI error, but that one was there since day one even before I switched to an SSD.

Actually the relevant part of the kernel logs spanned only 2 seconds of initialization before a pause that I assume is the LUKS prompt because it is imediately followed by BTRFS logs. This makes me think that the problem must be with GRUB because everything seems to be good as soon as the Linux kernel takes over, and also because windows (dual-booted) does not seem to suffer from such problems.

6

Does these relevant part include the very first log entry after boot? That is, the line with “kernel: Linux version …”

7

Yes the part that i was talking about is from the very first Linux version... line to a gap after 2 seconds (<2 actually) of hardware detection. I assumed this gap to be LUKS prompt because the next line was BTRFS initializing the decrypted drive.

Oh if your looking for the exact line here it is:

Apr 21 21:39:44 theeyefive kernel: Linux version 6.19.11-200.fc43.x86_64 (mockbuild@c637461aac0e4ac194cc1ec6e0c0a1c1) (gcc (GCC) 15.2.1 20260123 (Red Hat 15.2.1-7), GNU ld version 2.45.1-4.fc43) #1 SMP PREEMPT_DYNAMIC Thu Apr  2 16:55:52 UTC 2026
8

Well I tried updating the BIOS to the latest version and well, I was greeted with a record-breaking 6mins boot time:

❯ systemd-analyze time
Startup finished in 9.386s (firmware) + 6min 18.006s (loader) + 1.434s (kernel) + 47.576s (initrd) + 14.884s (userspace) = 7min 31.287s
graphical.target reached after 14.884s in userspace.

I wouldn’t say its the BIOS update that strictly did this since similar times were reached before, and 2 mins is what I consider to be average.

9

Please show us the output of sudo dmesg so we can see the exact steps as the system is loading. It seems it took ~9.4 seconds in bios then 6 min in the boot loader before the kernel loads.

We really need the details of what was happening during that time. Apparently it is being very slow to configure all the hardware before loading the kernel. This may be due to missing firmware for devices or something else. It may also be related to the SSD itself and the firmware on it.

10

The output reached the character limit, so here a paste:

11

Appears to be struggling badly with USB detection.

Got some form of hub or docking station attached?

12

nothing of the sort, only a cheap mouse and a less-cheaper keyboard

edit: and a USB headset

13

Unplug all USB devices (all!), turn on the machine.

14

Appears to be an ADATA USB flashdrive in there too, according to what it detected.

[   10.461129] usb 1-8: Product: ADATA USB Flash Drive
[   10.461130] usb 1-8: Manufacturer: ADATA
[   10.461131] usb 1-8: SerialNumber: 28C1020220090097
[   10.473132] usb-storage 1-8:1.0: USB Mass Storage device detected
15

I’d also check the BIOS to see if there’s any option to turn off legacy USB support and suchlike.

16

Ahh that one was only there to do the suggested BIOS update, its a one-time thing.

17

I remember there was something similar in UEFI setup, will try to disable.

18

Was your Redmi plugged in to boot with or did you plug it in after 7300 seconds or so?

19

Will also try this.

20

It was indeed plugged in way later, and so was the other USB drive.