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.
*********** MASS BUG UPDATE **************
We apologize for the inconvenience. There are a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 31 kernel bugs.
Fedora 31 has now been rebased to 5.5.7-200.fc31. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.
If you have moved on to Fedora 32, and are still experiencing this issue, please change the version to Fedora 32.
If you experience different issues, please open a new bug report for those.
(In reply to Justin M. Forbes from comment #3)
> *********** MASS BUG UPDATE **************
> We apologize for the inconvenience. There are a large number of bugs to go
> through and several of them have gone stale. Due to this, we are doing a
> mass bug update across all of the Fedora 31 kernel bugs.
> Fedora 31 has now been rebased to 5.5.7-200.fc31. Please test this kernel
> update (or newer) and let us know if you issue has been resolved or if it is
> still present with the newer kernel.
> If you have moved on to Fedora 32, and are still experiencing this issue,
> please change the version to Fedora 32.
> If you experience different issues, please open a new bug report for those.
I am currently running 5.5.7-200.fc31.x86_64 and the issue is still present.
The issue does not happen with kernel 5.5.13.
The new 5.3 release of the Linux kernel introduced a 6 second delay in early boot stage, which is meant to provide an additional layer of protection against hackers trying to access your computer during this vulnerable time period. However, for some users this can create a https://www.rush-my-essay.com/buy-college-essays/ problem if their BIOS does not support autofreeze before hibernation (which is necessary for the system to resume from hibernation), because any malware that was running when the machine went into sleep mode will still be active on resuming from hibernation.