Created attachment 1623308 [details]
dmesg.txt, kernel 5.3.2
1. Please describe the problem:
While testing kernel 5.3.2 on HP 850 G4 with encrypted root disk (LUKS), I have observed that getting a LUKS password prompt takes 6 seconds longer, compared to 5.2.17. Kernel 5.3.1 shows the same behavior. I have found by chance that the boot time of kernel 5.3 is the same as of the kernel 5.2 if I disable builtin LAN ethernet port.
Boot time until LUKS password prompt of 5.2: 5.9 seconds
Boot time until LUKS password prompt of 5.3 (eth enabled): 11.9 seconds
2. What is the Version-Release number of the kernel:
3. Did it work previously in Fedora? If so, what kernel version did the issue
*first* appear? Old kernels are available for download at
As far as I know it appeared with 5.3, for sure with 5.3.1. I did not test 5.3.0.
Last time it booted without the additional delay in 5.2.17, I did not test later 5.2 kernels.
4. Can you reproduce this issue? If so, please provide the steps to reproduce
the issue below:
Yes, the issue is 100% reproducible.
Start machine, measure the time from pressing enter in grub menu till LUKS password prompt appears.
I have measured it multiple times.
5. Does this problem occur with the latest Rawhide kernel? To install the
Rawhide kernel, run ``sudo dnf install fedora-repos-rawhide`` followed by
``sudo dnf update --enablerepo=rawhide kernel``:
Kernel 5.4.0-0.rc1.git1.1.fc32 shows the LUKS password prompt in 7.5 seconds, the time is not affected by the ethernet LAN state. So it is possible to say that the issue does not occur with the latest rawhide kernel, although the latest rawhide kernel prolongs the overall boot time by 1.6 seconds, compared to 5.2.17.
6. Are you running any modules that not shipped with directly Fedora's kernel?:
Not before LUKS container is opened. After switching root to LUKS device, I load VirtualBox modules, but these are not present in /boot kernels.
7. Please attach the kernel logs. You can get the complete kernel log
for a boot with ``journalctl --no-hostname -k > dmesg.txt``. If the
issue occurred on a previous boot, use the journalctl ``-b`` flag.
Only known recovery from the freeze is a hard reset. This is not a temporary freeze, but system hang up.
Please disr(In reply to Mirek Svoboda from comment #1)
> Only known recovery from the freeze is a hard reset. This is not a temporary
> freeze, but system hang up.
Please disregard this comment, it should have been for a different bug.