After upgrading from F41 to F42 beta on my laptop (Lenovo P1 Gen.2), luks prompt frame is shown several times during the rest of the boot process. - Once passphares is typed and Enter is pressed it switches back to the original frame when no password was typed, however system is already booting - On first modset (?) - Once the sddm password is typed, but before plasma boot animation is played This is very confusing, especially the first one, because it feels like the passphrase was typed incorrectly Reproducible: Always Steps to Reproduce: 1. I had Fedora 41 KDE Plasma 2. Upgraded to F42 beta 3. Cold Boot/Reboot Actual Results: LUKS prompt is shown in between boot screen changes Expected Results: Either black screen, Lenovo logo or something else should be displayed, but not the luks prompt I don't know whether it is a plymouth issue or not, but I don't know where else to open this issue
Created attachment 2084633 [details] Said screen Here is a screen shot of the screen I'm referring to
Here is a video of what's happening after the passphrase is typed: https://e.pcloud.link/publink/show?code=XZe8IdZWJnPSh2IUAQM5TTHHwFne7GXIYJy Here is a video of what's happening after the sddm password is typed: https://e.pcloud.link/publink/show?code=XZT8IdZlD4glVBEhBX6zOVK7SXnSzHss4M7
Same issue with Fedora Silverblue 42 after upgrade.
I'm experiencing a similar issue on a cleanly installed F42 (Workstation Edition, RX 6650 XT): what seems to be a static image of LUKS password prompt appears for a couple of seconds (no typing goes through), then the screen goes blank for a bit, and then the actual prompt finally shows up. If that helps, here's a slightly edited output of `journalctl | grep -i plymouth` for the most recent reboot cycle: 12:07:35 fedora systemd[1]: plymouth-quit-wait.service: Deactivated successfully. 12:07:35 fedora systemd[1]: Stopped plymouth-quit-wait.service - Hold until boot process finishes up. 12:07:35 fedora audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=plymouth-quit-wait comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' 12:07:35 fedora systemd[1]: Starting plymouth-reboot.service - Show Plymouth Reboot Screen... 12:07:35 fedora systemd[1]: Received SIGRTMIN+20 from PID 9693 (plymouthd). 12:07:35 fedora audit[9693]: AVC avc: denied { read write } for pid=9693 comm="plymouthd" name="event1" dev="devtmpfs" ino=201 scontext=system_u:system_r:plymouthd_t:s0 tcontext=system_u:object_r:event_device_t:s0 tclass=chr_file permissive=0 12:07:35 fedora audit[9693]: AVC avc: denied { read write } for pid=9693 comm="plymouthd" name="event0" dev="devtmpfs" ino=200 scontext=system_u:system_r:plymouthd_t:s0 tcontext=system_u:object_r:event_device_t:s0 tclass=chr_file permissive=0 12:07:35 fedora audit[9693]: AVC avc: denied { read write } for pid=9693 comm="plymouthd" name="event14" dev="devtmpfs" ino=983 scontext=system_u:system_r:plymouthd_t:s0 tcontext=system_u:object_r:event_device_t:s0 tclass=chr_file permissive=0 12:07:35 fedora audit[9693]: AVC avc: denied { read write } for pid=9693 comm="plymouthd" name="event15" dev="devtmpfs" ino=984 scontext=system_u:system_r:plymouthd_t:s0 tcontext=system_u:object_r:event_device_t:s0 tclass=chr_file permissive=0 12:07:35 fedora audit[9693]: AVC avc: denied { read write } for pid=9693 comm="plymouthd" name="event16" dev="devtmpfs" ino=985 scontext=system_u:system_r:plymouthd_t:s0 tcontext=system_u:object_r:event_device_t:s0 tclass=chr_file permissive=0 12:07:35 fedora audit[9693]: AVC avc: denied { read write } for pid=9693 comm="plymouthd" name="event17" dev="devtmpfs" ino=986 scontext=system_u:system_r:plymouthd_t:s0 tcontext=system_u:object_r:event_device_t:s0 tclass=chr_file permissive=0 12:07:35 fedora audit[9693]: AVC avc: denied { read write } for pid=9693 comm="plymouthd" name="event18" dev="devtmpfs" ino=987 scontext=system_u:system_r:plymouthd_t:s0 tcontext=system_u:object_r:event_device_t:s0 tclass=chr_file permissive=0 12:07:35 fedora audit[9693]: AVC avc: denied { read write } for pid=9693 comm="plymouthd" name="event2" dev="devtmpfs" ino=497 scontext=system_u:system_r:plymouthd_t:s0 tcontext=system_u:object_r:event_device_t:s0 tclass=chr_file permissive=0 12:07:35 fedora audit[9693]: AVC avc: denied { read write } for pid=9693 comm="plymouthd" name="event3" dev="devtmpfs" ino=500 scontext=system_u:system_r:plymouthd_t:s0 tcontext=system_u:object_r:event_device_t:s0 tclass=chr_file permissive=0 12:07:35 fedora audit[9693]: AVC avc: denied { read write } for pid=9693 comm="plymouthd" name="event4" dev="devtmpfs" ino=503 scontext=system_u:system_r:plymouthd_t:s0 tcontext=system_u:object_r:event_device_t:s0 tclass=chr_file permissive=0 12:07:35 fedora audit[9693]: AVC avc: denied { read write } for pid=9693 comm="plymouthd" name="event5" dev="devtmpfs" ino=504 scontext=system_u:system_r:plymouthd_t:s0 tcontext=system_u:object_r:event_device_t:s0 tclass=chr_file permissive=0 12:07:35 fedora audit[9693]: AVC avc: denied { read write } for pid=9693 comm="plymouthd" name="event6" dev="devtmpfs" ino=505 scontext=system_u:system_r:plymouthd_t:s0 tcontext=system_u:object_r:event_device_t:s0 tclass=chr_file permissive=0 12:07:35 fedora audit[9693]: AVC avc: denied { read write } for pid=9693 comm="plymouthd" name="event7" dev="devtmpfs" ino=506 scontext=system_u:system_r:plymouthd_t:s0 tcontext=system_u:object_r:event_device_t:s0 tclass=chr_file permissive=0 12:07:35 fedora audit[9693]: AVC avc: denied { read write } for pid=9693 comm="plymouthd" name="event8" dev="devtmpfs" ino=532 scontext=system_u:system_r:plymouthd_t:s0 tcontext=system_u:object_r:event_device_t:s0 tclass=chr_file permissive=0 12:07:35 fedora audit[9693]: AVC avc: denied { read write } for pid=9693 comm="plymouthd" name="event10" dev="devtmpfs" ino=535 scontext=system_u:system_r:plymouthd_t:s0 tcontext=system_u:object_r:event_device_t:s0 tclass=chr_file permissive=0 12:07:35 fedora audit[9693]: AVC avc: denied { read write } for pid=9693 comm="plymouthd" name="event11" dev="devtmpfs" ino=536 scontext=system_u:system_r:plymouthd_t:s0 tcontext=system_u:object_r:event_device_t:s0 tclass=chr_file permissive=0 12:07:35 fedora audit[9693]: AVC avc: denied { read write } for pid=9693 comm="plymouthd" name="event12" dev="devtmpfs" ino=538 scontext=system_u:system_r:plymouthd_t:s0 tcontext=system_u:object_r:event_device_t:s0 tclass=chr_file permissive=0 12:07:35 fedora audit[9693]: AVC avc: denied { read write } for pid=9693 comm="plymouthd" name="event9" dev="devtmpfs" ino=534 scontext=system_u:system_r:plymouthd_t:s0 tcontext=system_u:object_r:event_device_t:s0 tclass=chr_file permissive=0 12:07:35 fedora audit[9693]: AVC avc: denied { read write } for pid=9693 comm="plymouthd" name="event19" dev="devtmpfs" ino=1007 scontext=system_u:system_r:plymouthd_t:s0 tcontext=system_u:object_r:event_device_t:s0 tclass=chr_file permissive=0 12:07:35 fedora audit[9693]: AVC avc: denied { read write } for pid=9693 comm="plymouthd" name="event20" dev="devtmpfs" ino=1008 scontext=system_u:system_r:plymouthd_t:s0 tcontext=system_u:object_r:event_device_t:s0 tclass=chr_file permissive=0 12:07:35 fedora audit[9693]: AVC avc: denied { read write } for pid=9693 comm="plymouthd" name="event21" dev="devtmpfs" ino=1009 scontext=system_u:system_r:plymouthd_t:s0 tcontext=system_u:object_r:event_device_t:s0 tclass=chr_file permissive=0 12:07:35 fedora audit[9693]: AVC avc: denied { read write } for pid=9693 comm="plymouthd" name="event22" dev="devtmpfs" ino=1010 scontext=system_u:system_r:plymouthd_t:s0 tcontext=system_u:object_r:event_device_t:s0 tclass=chr_file permissive=0 12:07:35 fedora audit[9693]: AVC avc: denied { read write } for pid=9693 comm="plymouthd" name="event23" dev="devtmpfs" ino=1011 scontext=system_u:system_r:plymouthd_t:s0 tcontext=system_u:object_r:event_device_t:s0 tclass=chr_file permissive=0 12:07:35 fedora audit[9693]: AVC avc: denied { read write } for pid=9693 comm="plymouthd" name="event13" dev="devtmpfs" ino=885 scontext=system_u:system_r:plymouthd_t:s0 tcontext=system_u:object_r:event_device_t:s0 tclass=chr_file permissive=0 12:07:35 fedora systemd[1]: Started plymouth-reboot.service - Show Plymouth Reboot Screen. 12:07:35 fedora audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=plymouth-reboot comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' 12:07:35 fedora systemd[1]: plymouth-switch-root-initramfs.service - Tell Plymouth To Jump To initramfs was skipped because no trigger condition checks were met. 12:07:36 fedora systemd[1]: systemd-ask-password-plymouth.path: Deactivated successfully. 12:07:36 fedora systemd[1]: Stopped systemd-ask-password-plymouth.path - Forward Password Requests to Plymouth Directory Watch. 12:08:05 fedora systemd[1]: Starting plymouth-start.service - Show Plymouth Boot Screen... 12:08:05 fedora systemd[1]: Received SIGRTMIN+20 from PID 555 (plymouthd). 12:08:05 fedora systemd[1]: Started plymouth-start.service - Show Plymouth Boot Screen. 12:08:05 fedora systemd[1]: systemd-ask-password-console.path - Dispatch Password Requests to Console Directory Watch was skipped because of an unmet condition check (ConditionPathExists=!/run/plymouth/pid). 12:08:05 fedora systemd[1]: Started systemd-ask-password-plymouth.path - Forward Password Requests to Plymouth Directory Watch. 12:08:05 fedora systemd[1]: Started systemd-ask-password-plymouth.service - Forward Password Requests to Plymouth. 12:08:13 fedora systemd[1]: Starting plymouth-switch-root.service - Plymouth switch root service... 12:08:13 fedora systemd[1]: Finished plymouth-switch-root.service - Plymouth switch root service. 12:08:13 fedora systemd[1]: systemd-ask-password-plymouth.service: Deactivated successfully. 12:08:13 fedora systemd[1]: systemd-ask-password-console.path - Dispatch Password Requests to Console Directory Watch was skipped because of an unmet condition check (ConditionPathExists=!/run/plymouth/pid). 12:08:13 fedora systemd[1]: plymouth-switch-root.service: Deactivated successfully. 12:08:13 fedora systemd[1]: Stopped plymouth-switch-root.service - Plymouth switch root service. 12:08:14 fedora systemd[1]: systemd-ask-password-console.path - Dispatch Password Requests to Console Directory Watch was skipped because of an unmet condition check (ConditionPathExists=!/run/plymouth/pid). 12:08:14 fedora systemd[1]: systemd-ask-password-console.path - Dispatch Password Requests to Console Directory Watch was skipped because of an unmet condition check (ConditionPathExists=!/run/plymouth/pid). 12:08:14 fedora systemd[1]: systemd-ask-password-console.path - Dispatch Password Requests to Console Directory Watch was skipped because of an unmet condition check (ConditionPathExists=!/run/plymouth/pid). 12:08:14 fedora systemd[1]: Starting plymouth-read-write.service - Tell Plymouth To Write Out Runtime Data... 12:08:14 fedora systemd[1]: Received SIGRTMIN+20 from PID 555 (plymouthd). 12:08:14 fedora systemd[1]: Finished plymouth-read-write.service - Tell Plymouth To Write Out Runtime Data. 12:08:14 fedora audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=plymouth-read-write comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' 12:08:21 fedora systemd[1]: Starting plymouth-quit-wait.service - Hold until boot process finishes up... 12:08:21 fedora systemd[1]: Received SIGRTMIN+21 from PID 555 (plymouthd). 12:08:23 fedora systemd[1]: Received SIGRTMIN+21 from PID 555 (plymouthd). 12:08:23 fedora systemd[1]: Finished plymouth-quit-wait.service - Hold until boot process finishes up. 12:08:23 fedora audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=plymouth-quit-wait comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Hi All, Thank you for reporting this. This is related to: https://fedoraproject.org/wiki/Changes/PlymouthUseSimpledrm There appear to be 2 problems here: 1. The luks unlock screen re-showing on logout / shutdown 2. The keyboard not being responsive during the initial showing of the luks unlock screen About 1. the re-showing, the problem is that the GPU mode-setting driver needs to have a framebuffer to scan out from and by default the kernel will free all application allocated framebuffers as soon as the process exits. This means that when a gnome-session exits because of logout / shutdown, the GNOME installed framebuffer will get free-ed and to not let the monitor/LCD-panel immediately go into power-saving the mode-setting driver needs another framebuffer to scan-out from. For this reason the driver keeps around a fallback framebuffer and typically it re-uses the firmware framebuffer for this. This was already an issue before plymouth switched to using simpledrm, e.g. if there were some BIOS messages rather then a logo in the firmware framebuffer when Fedora starts those BIOS messages would get re-shown. But with plymouth now drawing the disk unlock screen on the firmware framebuffer, the firmware framebuffer will contain the unlock screen which I agree looks weird on logout / shutdown. To fix this I plan to make plymouth not use simpledrm when luks is in use. Can you please run: cat /proc/cmdline cat /etc/fstab and provide the output of these commandos ? ATM the moment I'm wondering how to best detect that luks will be used... Note above I wrote "by default the kernel will free all application allocated framebuffers" applications can now use a new ioctl on /dev/dri/card# before exiting to tell the kernel to keep their latest framebuffer around. This would be a better fix, but this will require work in GNOME / KDE / etc. ### About 2. The keyboard not being responsive, are you perhaps using a USB keyboard ? On my laptop with ps2 keyboard I can successfully start typing the unlock passphrase the first 1-2 seconds that plymouth shows it. What I think is happening here is that USB is still being probed while plymouth already shows the unlock screen. In the past plymouth was slower with showing the unlock screen, masking that USB probing also takes time.
Hi, Hans, Thank you for responding. > PlymouthUseSimpledrm That's what I thought. I do indeed use a USB keyboard, but the odd thing here is the blank screen between the "unresponsive" prompt and the "working" one. It's almost as if `amdgpu` ends up loading in the end. For what it's worth, when I tried to boot without "plymouth.use-simpledrm", everything seemed to go back to the old behavior of F41 (as expected).
P.S.: Another oddity is that the "first" prompt often shows the keyboard layout as "us", while the "second" one displays "English (US)".
Hi Hans, thanks for getting us a background. Here is my cmdline: BOOT_IMAGE=(hd0,gpt2)/vmlinuz-6.14.3-300.fc42.x86_64 root=UUID=<uuid reducted> ro rootflags=subvol=root rd.luks.uuid=luks-<uuid reducted> rhgb quiet I guess "rd.luks" can be a string to look for. Also as a suggestion, maybe to look for non-zero sized /etc/crypttab? From /etc/fstab perspective, afaict, there is no indication that luks is in use.
(In reply to Hasshu from comment #7) > P.S.: Another oddity is that the "first" prompt often shows the keyboard > layout as "us", while the "second" one displays "English (US)". Right, so that confirms that the issue with the keyboard not working is it not being enumerated/probed yet when there are no /dev/input/event# nodes plymouth can use (because of e.g. missing XKB mapping info in /etc/vconsole.conf) it will fallback to using /dev/tty0 for input. In the fallback case it will show a console keymap name (so "us") instead of a XKB keymap name ("English (US)"). But the /dev/tty0 fallback does not work for you because the problem is not an incomplete /etc/vconsole.conf but rather the keyboard not being enumerated/probed yet. There is little plymouth can do here. The issue here is that using efifb/simpledrm nows shows the unlock dialog before the keyboard driver is ready (oops).
Aha, makes sense. Actually, I was planning to post a relevant update: surprisingly enough, connecting the keyboard to a different bank of USB ports has solved the enumeration delay, so that's one mystery less. Still, there's the issue of flicker, which seems to have been reported under bug 2339068 and/or bug 2339072. Sorry for the noise, and thanks for the information!
This will be fixed by this upstream merge-request: https://gitlab.freedesktop.org/plymouth/plymouth/-/merge_requests/355 I'm working on preparing a plymouth update addressing several issues including this one.
FEDORA-2025-bea98bd9ab (plymouth-24.004.60-19.fc43) has been submitted as an update to Fedora 43. https://bodhi.fedoraproject.org/updates/FEDORA-2025-bea98bd9ab
FEDORA-2025-bea98bd9ab (plymouth-24.004.60-19.fc43) has been pushed to the Fedora 43 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2025-84de48bce5 (plymouth-24.004.60-19.fc42) has been submitted as an update to Fedora 42. https://bodhi.fedoraproject.org/updates/FEDORA-2025-84de48bce5
FEDORA-2025-84de48bce5 has been pushed to the Fedora 42 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2025-84de48bce5` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-84de48bce5 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
(In reply to Hans de Goede from comment #11) > This will be fixed by this upstream merge-request: > > https://gitlab.freedesktop.org/plymouth/plymouth/-/merge_requests/355 > > I'm working on preparing a plymouth update addressing several issues > including this one. Do we need any other pieces of the puzzle, except the plymouth? I'm trying plymouth-24.004.60-19.fc42, but there is no difference in behavior on my laptop.
> Do we need any other pieces of the puzzle, except the plymouth? I'm trying plymouth-24.004.60-19.fc42, but there is no difference in behavior on my laptop. plymouth is copied into the initrd when it is generated, so upgrading just plymouth does not change anything, since your initrd will still have the old copy. You need to regenerate your initrd for your currently running kernel (see "uname -a" output) using "sudo dracut -f" then reboot and check that your still in the same kernel version (see "uname -a" output). If you "uname -a" shows you've installed a kernel update between the 2 boots, then the "sudo dracut -f" command will have regenerated the initrd for the old kernel. Run "sudo dracut -f" again and reboot again.
FEDORA-2025-84de48bce5 (plymouth-24.004.60-19.fc42) has been pushed to the Fedora 42 stable repository. If problem still persists, please make note of it in this bug report.
(In reply to Hans de Goede from comment #17) > > Do we need any other pieces of the puzzle, except the plymouth? I'm trying plymouth-24.004.60-19.fc42, but there is no difference in behavior on my laptop. > > plymouth is copied into the initrd when it is generated, so upgrading just > plymouth does not change anything, since your initrd will still have the old > copy. You need to regenerate your initrd for your currently running kernel > (see "uname -a" output) using "sudo dracut -f" then reboot and check that > your still in the same kernel version (see "uname -a" output). > > If you "uname -a" shows you've installed a kernel update between the 2 > boots, then the "sudo dracut -f" command will have regenerated the initrd > for the old kernel. Run "sudo dracut -f" again and reboot again. Thanks, indeed regenerating initrd fixed it.