Bug 1779044

Summary: LUKS boot password prompt does not appear at boot after updating to kernel-5.3.12-300.fc31
Product: [Fedora] Fedora Reporter: Vinu Moses <vinu>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 31CC: airlied, bskeggs, hdegoede, ichavero, itamar, jarodwilson, jeremy, jglisse, john.j5live, jonathan, josef, kernel-maint, linville, masami256, mchehab, mjg59, steved
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-03-03 18:26:18 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Description Flags
Log of kernel messages at a normal boot none

Description Vinu Moses 2019-12-03 06:45:38 UTC
Created attachment 1641559 [details]
Log of kernel messages at a normal boot

1. Please describe the problem:

After upgrading to kernel-5.3.12-300.fc31 I do not get a LUKS password prompt at boot and the entire PC hangs with a blank screen. This behaviour is reproducible with kernel-5.3.13-300.fc31 as well.

If I reboot to an earlier kernel (kernel-5.3.11-300.fc31), the system asks for the LUKS password at boot and boots up fine.

2. What is the Version-Release number of the kernel:

kernel-5.3.12-300.fc31 and kernel-5.3.13-300.fc31

3. Did it work previously in Fedora? If so, what kernel version did the issue
   *first* appear?  Old kernels are available for download at
   https://koji.fedoraproject.org/koji/packageinfo?packageID=8 :


4. Can you reproduce this issue? If so, please provide the steps to reproduce
   the issue below:

* Reboot from a kernel-5.3.11-300.fc31 after upgrading to the kernel-5.3.12-300.fc31.
* Select kernel-5.3.12-300.fc31 at boot
* System shows a blank screen and hangs, instead of displaying a LUKS password prompt.

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``:

Not tested. But the latest kernel update kernel-5.3.13-300.fc31 also causes the same problem.

6. Are you running any modules that not shippekernel-5.3.13-300.fc31d with directly Fedora's kernel?:


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.

I'm unable to attach kernel logs because the boot is not logged. System hangs without displaying a LUKS password prompt and therefore nothing is logged.

Comment 1 Vinu Moses 2019-12-09 04:50:13 UTC
The bug persists with kernel-5.3.14-300.fc31.x86_64 as well.

Comment 2 Vinu Moses 2019-12-16 14:06:59 UTC
The bug persists with kernel-5.3.15-300.fc31.x86_64 as well.

Comment 3 Vinu Moses 2020-01-03 15:51:13 UTC
The bug persists with 5.3.16-300.fc31.x86_64 as well.

Comment 4 Vinu Moses 2020-01-03 15:54:22 UTC
kernel-5.4.5-301.fc31 does not have this bug. Similar behaviour as kernel-5.3.11-300.fc31.

Comment 5 Justin M. Forbes 2020-03-03 16:33:05 UTC
*********** 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.

Comment 6 Hans de Goede 2020-03-03 17:02:55 UTC
Vinu, you mentioned that 5.4.5 does not have this problem, what about later kernels, e.g. the current 5.5.7 does that work?

If 5.3.xx where xx > 11 does not work and 5.4.5 does work and say 5.4.6 again does not work, then we should be able to pin this down to a single commit causing the issue which swill hopefully allow us to fix this.

Comment 7 Vinu Moses 2020-03-03 17:19:26 UTC
The official 5.5.x kernels do not have this problem and they all work fine. 
The bug starts from kernel-5.3.12-300.fc31 and all the official kernels released after until it is resolved in kernel-5.4.5-301.fc31 and all subsequent kernels.

Comment 8 Hans de Goede 2020-03-03 18:26:18 UTC
Ok, so this can be closed then, thank you for letting us know that this is solved now.