Bug 1810070 - LUKS password prompt is not shown with more displays connected
Summary: LUKS password prompt is not shown with more displays connected
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: plymouth
Version: 32
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Hans de Goede
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedFreezeException AcceptedBlocker
: 1729157 1809934 (view as bug list)
Depends On:
Blocks: BetaFreezeException, F32BetaFreezeException F32FinalBlocker, FinalBlocker
TreeView+ depends on / blocked
 
Reported: 2020-03-04 14:08 UTC by František Zatloukal
Modified: 2020-03-26 16:23 UTC (History)
12 users (show)

Fixed In Version: plymouth-0.9.4-13.20200306git58a7289.fc32
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-03-12 18:57:07 UTC
Type: Bug


Attachments (Terms of Use)

Description František Zatloukal 2020-03-04 14:08:29 UTC
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):
plymouth-0.9.4-12.20191022git32c097c.fc32.x86_64

How reproducible:
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

Actual results:
LUKS password prompt is not shown.

Expected results:
LUKS password prompt should be shown.

Comment 1 Fedora Blocker Bugs Application 2020-03-04 14:11:18 UTC
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.

Comment 2 Hans de Goede 2020-03-04 14:22:24 UTC
This might be a plymouth bug which I recently fixed, I have a scratchbuild with those fixes added to it here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=41654795

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.

Comment 3 František Zatloukal 2020-03-04 14:32:28 UTC
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 ).

Comment 4 Hans de Goede 2020-03-04 14:46:00 UTC
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.

Comment 5 František Zatloukal 2020-03-04 15:10:06 UTC
(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 ).

Comment 6 František Zatloukal 2020-03-04 15:18:47 UTC
(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:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=41654795
> 
> 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?

Comment 7 Chris Murphy 2020-03-06 01:19:47 UTC
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?

Comment 8 Adam Williamson 2020-03-07 18:19:11 UTC
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...

Comment 9 Hans de Goede 2020-03-07 18:23:42 UTC
(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.

Comment 10 Hans de Goede 2020-03-09 09:51:27 UTC
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.

Comment 11 Hans de Goede 2020-03-09 10:41:09 UTC
*** Bug 1729157 has been marked as a duplicate of this bug. ***

Comment 12 Hans de Goede 2020-03-09 10:45:38 UTC
*** Bug 1809934 has been marked as a duplicate of this bug. ***

Comment 13 Fedora Update System 2020-03-09 10:49:59 UTC
FEDORA-2020-effccc3c17 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-effccc3c17

Comment 14 Fedora Update System 2020-03-09 14:54:51 UTC
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

Comment 15 Hans de Goede 2020-03-09 16:09:16 UTC
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.

Comment 16 Geoffrey Marr 2020-03-10 00:41:53 UTC
Discussed during the 2020-03-09 blocker review meeting: [0]

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

[0] https://meetbot.fedoraproject.org/fedora-blocker-review/2020-03-09/f32-blocker-review.2020-03-09-16.01.txt

Comment 17 Fedora Update System 2020-03-12 18:57:07 UTC
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.

Comment 18 Michal Konecny 2020-03-17 09:25:31 UTC
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.

Comment 19 Michal Konecny 2020-03-18 11:43:56 UTC
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.
```

Comment 20 Michal Konecny 2020-03-26 09:28:01 UTC
I'm still seeing this issue with up to date Fedora 32 Silverblue.

Comment 21 Hans de Goede 2020-03-26 09:33:16 UTC
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?

Comment 22 Michal Konecny 2020-03-26 09:44:40 UTC
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
Monitors: 
DELL U2415 - DisplayPort - 1920x1200
DELL U2415 - HDMI - 1920x1200
NEC MultiSync E233WM - VGA - 1920x1080

Packages:
kernel-5.6.0-0.rc7.git0.2.fc32.x86_64
plymouth-0.9.4-13.20200306git58a7289.fc32.x86_64

If any additional info is needed, just ask.

Comment 23 Hans de Goede 2020-03-26 15:23:20 UTC
(In reply to Michal Konecny from comment #22)
> 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
> Monitors: 
> 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?

Comment 24 Michal Konecny 2020-03-26 16:23:51 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.