Description of problem: After upgrading from Fedora 29 to Fedora 30 the Plymouth graphical boot no longer provides keyboard input feedback when typing the LUKS passphrase to decrypt LUKS volumes on boot. While no feedback is shown, keyboard input is still accepted so if the passphrase is typed correctly when return the return key is pressed the boot sequence will continue, however the usual progress bar is also not shown. Note: I think this is a similar bug to #1490490, however it was original logged against Fedora 26 and update to Fedora 28. I added a comment about the issue re-appearing with Fedora 30 but I don't know if the issue will be followed up as it was just marked with a comment to say that Fedora 28 is EOL. As per comments in bug #1490490 I am using an MSI R9 390 GPU and using the following kernel parameters: radeon.cik_support=0 amgdpu.cik_support=1 amdgpu.dc=1 Version-Release number of selected component (if applicable): Fedora 30 How reproducible: Always Steps to Reproduce: 1. Boot Fedora 30 system with LUKS encrypted volume (and possibly old GCN 1.2 or older AMD GPU) 2. Wait for Plymouth graphical boot screen to display 3. Type LUKS passphrase into the edit box and hit the return key Actual results: 1. No feedback is provided as each character is typed (previously a dot would be displayed in the passphrase edit box) 2. When the return key is hit no progress bar is shown as the LUKS volume is decrypted and the boot process continues Expected results: 1. A dot or other passphrase placeholder character should be entered into the passphrase edit box with each key press 2. The boot progress bar (or other progress indicator) should be display once the return key is pressed. Additional info: Hitting the ESC or arrow keys to switch to text mode during boot results in a black screen. Also, I note that there is a commit to the Plymouth source repo where the background colour was changed to black for situations where the firmware boot-splash screen is not shown. Is it possible that the keyboard feedback character and progress bar as also being drawn in black so cannot be seen? https://src.fedoraproject.org/rpms/plymouth/c/56277ff72140c8e7d70a97ff8d35c146d24a8a0d?branch=master
Just wanted to add an update to this bug. I've noticed that when I remove the "radeon.cik_support=0" kernel parameter the Plymouth graphical boot seems to work as expected. The passphrase placeholder bullet graphics are correctly rendered and the progress spinner is displayed when I hit the enter key. The side effect of this however is that when my PC boots and I log in to my DE audio of HDMI/DP (via my AMD GPU) no longer works and my PC is unstable (The GPU will crash after a few minutes of use) No sure if this is useful, but it looks like the issue is with the AMDGPU support, as using the Radeon module during boot correctly renders the passphrase bullet placeholder and spinner graphics.
(In reply to Shecks from comment #1) > Just wanted to add an update to this bug. > > I've noticed that when I remove the "radeon.cik_support=0" kernel parameter > the Plymouth graphical boot seems to work as expected. > The passphrase placeholder bullet graphics are correctly rendered and the > progress spinner is displayed when I hit the enter key. > > The side effect of this however is that when my PC boots and I log in to my > DE audio of HDMI/DP (via my AMD GPU) no longer works > and my PC is unstable (The GPU will crash after a few minutes of use) > > No sure if this is useful, but it looks like the issue is with the AMDGPU > support, as using the Radeon module during boot correctly > renders the passphrase bullet placeholder and spinner graphics. There are multiple bugs open about the bullets not being rendered with the amdgpu driver, I'm going to consolidate these into 1 bug. What really needs to happen here is that someone opens a bug with the upstream amdgpu developers so that they can fix this. I will add instructions for filing a bug upstream to bug 1490490 which is the original / first filed bug for this. *** This bug has been marked as a duplicate of bug 1490490 ***