Description of problem:
LUKS prompt is not shown if there is more than one connected display. Disabling Plymouth or disconnecting additional displays solves the issue.
Version-Release number of selected component (if applicable):
Always (Tested only on one laptop for now)
Steps to Reproduce:
1. Install Fedora 31 with entire HDD encrypted with LUKS
2. Upgrade to Fedora 32
LUKS password prompt is not shown.
LUKS password prompt should be shown.
Proposed as a Blocker for 32-beta by Fedora user frantisekz using the blocker tracking app because:
A system installed with a release-blocking desktop must boot to a log in screen where it is possible to log in to a working desktop using a user account created during installation or a 'first boot' utility.
This might be a plymouth bug which I recently fixed, I have a scratchbuild with those fixes added to it here:
To install this do the following:
1) Run "rpm -qa | grep plymouth | sort"
2) Download the rpms from the link for the plymouth (sub)packages which you have installed
3) In a folder with the downloaded rpms run: "sudo rpm -Uvh plymouth*"
4) Run "sudo dracut -f" to regenerate the initrd for your currently running kernel so that the new plymouth gets added to it
5) Run "uname -a" note the kernel version
6) reboot with the external monitor connected
7) Run "uname -a" again, if the kernel version is different the kernel was upgraded since you last rebooted, go to
After doing the above steps, check if you can still reproduce the problem.
Hans, before I try your scratchbuild, this issue is not present in kernel 5.5.5 from f31 (see comments 13 and 14 in https://bugzilla.redhat.com/show_bug.cgi?id=1809681 ).
I guess you have a thunderbolt or USB Type-C dock using Display Port multi-stream transport for the displays?
There is a known issue in kernel 5.6 (which is being worked on) where only 1 display on the dock will light up in this case; and that is exactly what is triggering the bug in plymouth. The plymouth build will fix the system not booting but if you have multiple monitors on your dock only one will work (while gnome will still think they are all there).
See: https://gitlab.freedesktop.org/drm/amd/issues/1052 for some more info.
We know which kernel commit is causing this and it is likely safe to just revert the commit, as it just adds an extra sanity check which fails because of other issues, but if we leave out the extra sanity check then we get the 5.5 behavior which in most cases just works.
(In reply to Hans de Goede from comment #4)
> I guess you have a thunderbolt or USB Type-C dock using Display Port
> multi-stream transport for the displays?
I don't use Thunderbolt dock, I am using legacy thinkpad dock (T470s, looks like this one: https://www.lenovo.com/us/en/accessories-and-monitors/docking/mechanical-docks/ThinkPad-Ultra-Dock-90-W/p/40A20090US ).
(In reply to Hans de Goede from comment #2)
> This might be a plymouth bug which I recently fixed, I have a scratchbuild
> with those fixes added to it here:
> To install this do the following:
> 1) Run "rpm -qa | grep plymouth | sort"
> 2) Download the rpms from the link for the plymouth (sub)packages which you
> have installed
> 3) In a folder with the downloaded rpms run: "sudo rpm -Uvh plymouth*"
> 4) Run "sudo dracut -f" to regenerate the initrd for your currently running
> kernel so that the new plymouth gets added to it
> 5) Run "uname -a" note the kernel version
> 6) reboot with the external monitor connected
> 7) Run "uname -a" again, if the kernel version is different the kernel was
> upgraded since you last rebooted, go to
> step 4.
> After doing the above steps, check if you can still reproduce the problem.
And yes, this fixes the issue with kernel 5.6 (one display stays off, but I can type LUKS password just fine with plymouth-0.9.4-13.20191224gitd7c737d.fc31.x86_64 ). Thanks
Will you make an update for F32?
I think it's a final blocker, but I'm on the fence whether it's a beta blocker. Is documenting in Common Bugs inadequate?
I think I'd be +1 Beta FE at least for both the plymouth workaround for the kernel bug, and reverting the problematic kernel patch. Do we have a bug for the kernel issue here? CCing kernel folks...
(In reply to Adam Williamson from comment #8)
> I think I'd be +1 Beta FE at least for both the plymouth workaround for the
> kernel bug, and reverting the problematic kernel patch. Do we have a bug for
> the kernel issue here? CCing kernel folks...
The kernel side of this is being tracked in bug 1809681. This morning I tested a set of fixes from Lyude for this and those work for me, so we should be able to fix the kernel side by carrying those downstream while they trickle down upstream. I've asked Lyude if carrying these downstream is a good idea. As soon as I get an ack from her for this I will add them to the F32+ kernels (to be picked up by the next build done by the Fedora kernel folks).
As for the plymouth issue (so this bug). I plan to create an update for that tomorrow or coming Monday, the patches fix a couple of real issues and should otherwise be pretty safe, so a freeze exception would be welcome for this.
I've just finished preparing the plymouth update for this. I'll create an update for this in bodhi as soon as it is done building.
*** Bug 1729157 has been marked as a duplicate of this bug. ***
*** Bug 1809934 has been marked as a duplicate of this bug. ***
FEDORA-2020-effccc3c17 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-effccc3c17
plymouth-0.9.4-13.20200306git58a7289.fc32 has been pushed to the Fedora 32 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-effccc3c17
Proposing as a Beta freeze exception issue, the fixed build for this fix a plymouth crash whenever monitor hotplug events happen after plymouth has started (e.g. slow DP-MST enumeration on a DP-MST dock).
When plymouth crashes in this scenario; and disk-encryption is used, the boot just hangs, so this is a serious bug.
Discussed during the 2020-03-09 blocker review meeting: 
The decision to classify this bug as a "RejectedBlocker" (Beta), "AcceptedBlocker" (Final), and an "AcceptedFreezeException" was made as it violates the Final blocker critierion:
"A system installed with a release-blocking desktop must boot to a log in screen..." for encrypted installs with affected display configurations.
Accepted as a Beta FE as we obviously would like affected systems to work in Beta as well
plymouth-0.9.4-13.20200306git58a7289.fc32 has been pushed to the Fedora 32 stable repository. If problems still persist, please make note of it in this bug report.
I'm experiencing this again, but this time it's not on every boot.
I tried to play with it and if I remove `rhgb quiet` options from grub entry it's booting without issue, but I saw some weird warning in the same time LUKS prompt should be shown. I don't see it in the dmesg or journalctl, but it was something about modified unit and LUKS.
Here is the message from dracut:
dracut-initqueue: Warning: The unit file, source configuration file or drop-ins of systemd-cryptsetup@luks\x2d6098e96e\x2b4b1d\xda511\x2df4c532264803.service changed on disk. Run 'systemctl daemon-reload' to reload units.
I'm still seeing this issue with up to date Fedora 32 Silverblue.
Michal, can you describe your setup in some more detail ? E.g. is this with a desktop or a laptop, what model, what GPU(s) are being used. If it is a laptop, is there a dock, or are you plugging the monitors directly into the laptop. If there is a dock what is the model of the dock. What model monitor(s) are you using and how are they connected? Etc.
Also what kernel version and plymouth version does your up to date Fedora 32 Silverblue use?
I have three monitors connected through docking station to LENOVO ThinkPad X270.
GPU: Mesa Intel® HD Graphics 620 (KBL GT2)
Docking station: ThinkPad Ultradock Type 40A2
DELL U2415 - DisplayPort - 1920x1200
DELL U2415 - HDMI - 1920x1200
NEC MultiSync E233WM - VGA - 1920x1080
If any additional info is needed, just ask.
(In reply to Michal Konecny from comment #22)
> I have three monitors connected through docking station to LENOVO ThinkPad
> GPU: Mesa Intel® HD Graphics 620 (KBL GT2)
> Docking station: ThinkPad Ultradock Type 40A2
> DELL U2415 - DisplayPort - 1920x1200
> DELL U2415 - HDMI - 1920x1200
> NEC MultiSync E233WM - VGA - 1920x1080
Ok, so that sort of matches my setup of a X1 7th gen + dock + 2 external monitors and using the internal screen at the same time to also get 3 monitors.
I have been debugging a crash at boot when using 5.6 kernels, which happens when plymouth loads. I first targeted plymouth in my debugging, but by logging directly to a raw disk partition I've been able to pinpoint the crash to a drm/kms ioctl plymouth makes, from which the kernel never returns, so this seems to be a kernel bug.
For me this seems to only trigger when cold-booting and even then not every boot. Does that match your experience?
Yes, it's not happening every time. And it's always work when I remove `rhgb quiet` from grub entry.
Another think I didn't mentioned is that this was happening to me also on Fedora 30, it was fixed on Fedora 31. There was one difference then, I was able to restart the computer using CTRL+ALT+DEL and now I need to force it off by holding power button.