Bug 2161029

Summary: 6.1.5-200 stuck _before_ LUKS at "Booting a Command List"
Product: [Fedora] Fedora Reporter: nesdeq
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 37CC: acaringi, adscvr, airlied, alciregi, bskeggs, davide, fotheringham.paul, hdegoede, hpa, jarodwilson, jglisse, josef, js314592, kernel-maint, kparal, lgoncalv, linville, masami256, mchehab, nesdeq, ptalbert, steved, todoleza
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2023-01-16 10:50:10 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:
Embargoed:

Description nesdeq 2023-01-15 11:43:02 UTC
1. Please describe the problem:

All Kernels newer than 6.0.18 do not boot a LUKS encrypted system. When removing all parameters and even nomodeset (...=0), removing rhgb and quiet we see it is stuck at "Booting a Command List" - nothing happens.


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

6.1.5-200, however this issue is there with all kernels newer than 6.0.18 from vanilla-repo, updates-testing and even rawhide


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 :

It seems to appear with every Kernel starting from 6.1.x+. HOWEVER when building vanilla (kernel.org) from 6.1.x or 6.2.x from source with make localmodconfig (not fedpkg or rpmbuild) AT least those boot.


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

Install any kernel 6.1.x+ from any fedora-repository and stare at "Booting a Command List"


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

Yes.

6. Are you running any modules that not shipped with directly Fedora's kernel?:

Nvidia, via akmod. But even nomodeset does not help.


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.

No boot, no kernel log. Nothing in dmesg. Stuck BEFORE decrypting and prompting for LUKS PW.

Comment 1 nesdeq 2023-01-15 11:45:16 UTC
This is Fedora37.

Comment 2 nesdeq 2023-01-15 13:13:05 UTC
On a hunch tried to just type in the luks pw and system boots. Seems kernel updates after 6.1+ break LUKS password prompt both graphical (rhgb) AND text-based (only shows "Booting a Command List") - there is _no_ hint that a password is expected AT ALL.

Comment 3 Paul Fotheringham 2023-01-15 18:52:51 UTC
(In reply to nesdeq from comment #2)
> On a hunch tried to just type in the luks pw and system boots. Seems kernel
> updates after 6.1+ break LUKS password prompt both graphical (rhgb) AND
> text-based (only shows "Booting a Command List") - there is _no_ hint that a
> password is expected AT ALL.

Confirmed on my system (Fedora 37, kernel 6.1.5). Booted fine after typing encryption password even though there was no password prompt displayed. Thanks for pointing that out, I should have thought of that but didn't.

Comment 4 leigh scott 2023-01-15 22:42:01 UTC
VT switching is broken.

It looks like the kernel devs have forgotten to compile efifb support for 6.1.x stable release again! :-(

Comment 5 nesdeq 2023-01-15 22:44:49 UTC
and 6.2rc as well.... thats why manual compile from oldconfig 6.0.18 works out I guess

Comment 6 Kamil Páral 2023-01-16 10:50:10 UTC
I believe this is a duplicate of bug 2161104, merging.

*** This bug has been marked as a duplicate of bug 2161104 ***