Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 2127663 - Display stops immediately after LUKS passphrase prompt appears, rather than immediately before
Summary: Display stops immediately after LUKS passphrase prompt appears, rather than i...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: plymouth
Version: 37
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Hans de Goede
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-09-17 22:03 UTC by Michael Catanzaro
Modified: 2022-10-03 00:20 UTC (History)
3 users (show)

Fixed In Version: plymouth-22.02.122-3.fc38 plymouth-22.02.122-3.fc37
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-09-28 22:10:08 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
dmesg (deleted)
2022-09-17 22:03 UTC, Michael Catanzaro
no flags Details
plymouth-debug (deleted)
2022-09-17 22:04 UTC, Michael Catanzaro
no flags Details
New plymouth-debug log (deleted)
2022-09-28 21:07 UTC, Michael Catanzaro
no flags Details

Description Michael Catanzaro 2022-09-17 22:03:45 UTC
Created attachment 1912599 [details]
dmesg

In Fedora 36, plymouth's graphics briefly disappear immediately before displaying the LUKS password prompt. The timing is clearly coordinated to ensure the display blank occurs immediately before the prompt appears.

In Fedora 37, the timing is messed up and the graphics instead disappear shortly _after_ displaying the prompt. This is very disruptive and confusing as I have just enough time to begin typing my password before the display goes away.

You might need an AMD CPU to test this. I understand that since https://fedoraproject.org/wiki/Changes/FlickerFreeBoot, there is not supposed to be any blank at all when using Intel CPUs.

At Hans's suggestion, I booted using plymouth.debug=stream:/dev/null and have attached two logs.

Comment 1 Michael Catanzaro 2022-09-17 22:04:10 UTC
Created attachment 1912600 [details]
plymouth-debug

Comment 2 Hans de Goede 2022-09-28 13:03:52 UTC
Thank you for the log that helps. I believe I know what is going on here, here is the commit message for a patch I'm writing for this:

"""
Plymouth has 2 hw discovery paths:
1. Enumerating devices already known by udev at plymouth startup
2. Devices which are hotplugged after startup

At boot we have udevd which is enumerating hw and plymouthd racing
with each other, which means that plymouthd may discover the new
SimpleDRM device through either 1. or 2.

Before this patch a check for SimpleDRM was missing from path 1, causing
it to be treated as a normal device instead of being ignored as intended:

plymouth-debug.log for the simpledrm being enumerated in path 1:

ply-device-manager.c:344: create_devices_for_subsystem:
 found device /sys/devices/platform/simple-framebuffer.0/drm/card0
ply-device-manager.c:351: create_devices_for_subsystem:
 device is initialized
ply-device-manager.c:360: create_devices_for_subsystem:
 found node /dev/dri/card0
ply-device-manager.c:283: create_devices_for_udev_device:
 found DRM device /dev/dri/card0
ply-device-manager.c:885: create_devices_for_terminal_and_rende:
 creating devices for /dev/dri/card0 (renderer type: 1)

plymouth-debug.log for the simpledrm *not* being enumerated in path 1:

ply-device-manager.c:344: create_devices_for_subsystem:
 found device /sys/devices/platform/simple-framebuffer.0/drm/card0
ply-device-manager.c:367: create_devices_for_subsystem:
 it's not initialized

followed by path 2 enumerating the device very shortly after this:

ply-device-manager.c:532: on_udev_event:
 got add event for device /dev/dri/card0
ply-device-manager.c:462: verify_add_or_change:
 ignoring since we only handle SimpleDRM devices after timeout

Note how path 2 does correctly ignore SimpleDRM devices, where as
path 1 does not. This commit fixes this by moving the verify_drm_device()
check in to create_devices_for_udev_device() which runs in both paths.

Link: https://bugzilla.redhat.com/show_bug.cgi?id=2127663
"""

Your system is following path 1. here; where as with my system it seems to be a coin toss which path it follows (when it follows path 2 there is a 6 ms time-difference between the cold-plug and hot-plug enumerations).

I'm going to run some local tests with the patch and then I'll do a plymouth scratch build for you to test and confirm that the issue is resolved.

Comment 3 Hans de Goede 2022-09-28 14:38:45 UTC
Here is a scratch-build, please install this and after the regenerate your initrd before rebooting :

https://koji.fedoraproject.org/koji/taskinfo?taskID=92399189

Also please provide a new plymouth-debug.log from a boot with this version so that I can check it is behaving as expected now, thanks.

Comment 4 Michael Catanzaro 2022-09-28 21:07:51 UTC
Created attachment 1914902 [details]
New plymouth-debug log

Comment 5 Michael Catanzaro 2022-09-28 21:12:40 UTC
I'm pretty confident your new build fixed it. Thanks!

Comment 6 Fedora Update System 2022-09-28 22:06:14 UTC
FEDORA-2022-c66bb240b7 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2022-c66bb240b7

Comment 7 Fedora Update System 2022-09-28 22:10:08 UTC
FEDORA-2022-c66bb240b7 has been pushed to the Fedora 38 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 8 Fedora Update System 2022-09-29 07:01:24 UTC
FEDORA-2022-938267a276 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2022-938267a276

Comment 9 Fedora Update System 2022-09-30 01:13:49 UTC
FEDORA-2022-938267a276 has been pushed to the Fedora 37 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-938267a276`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-938267a276

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 10 Fedora Update System 2022-10-03 00:20:03 UTC
FEDORA-2022-938267a276 has been pushed to the Fedora 37 stable repository.
If problem still persists, please make note of it in this bug report.


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