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.
Created attachment 1912600 [details] plymouth-debug
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.
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.
Created attachment 1914902 [details] New plymouth-debug log
I'm pretty confident your new build fixed it. Thanks!
FEDORA-2022-c66bb240b7 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2022-c66bb240b7
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.
FEDORA-2022-938267a276 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2022-938267a276
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.
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.