See also https://bugzilla.redhat.com/show_bug.cgi?id=1490490 - Plymouth has been partially broken with AMDGPU + LUKS for over a year now, with zero response to that bug. Now, with kernel 4.18 (and all up to date packages as of today), there is no Plymouth LUKS password screen at all. After Grub disappears, the screen changes to a blank black screen, and blindly typing the password no longer works as it previously did per the above bug. Esc also does not work to fall back to the text boot screen/password entry. Removing rhgb from the kernel boot line results in a working text mode boot with the ability to enter the LUKS password. Booting with kernel 4.17.x results in the behaviour per the above bug - Plymouth LUKS screen appears, but no character bullets are shown when typing the password, and no boot progress is shown (instead GDM just eventually replaces the blank Plymouth LUKS screen). It would be great if this bug doesn't also go completely ignored as the above one was.
I am also experiencing a similar issue but only after updating from kernel 4.18.7 to 4.18.8 (issue also exists with 4.18.9) I have an MSI R9 390 GPU which has only just became usable for me with AMDGPU. As of kernel 4.18.7 my GPU was working perfectly with the "amdgpu.dc=1 amdgpu.dpm=1 amdgpu.cik_support=1 radeon.cik_support=0" kernel command line parameters. The RHGB was working fine and Plymouth was correctly prompting for and accepting my LUKS passphrase. Unfortunately this only lasted for about 1 1/2 weeks until the kernel 4.18.8 release. I updated my Fedora 28 install to kernel 4.18.8 and now my PC does not boot. It seems that once the boot process gets to the point where it needs to switch to graphics mode in order for the Plymouth boot screen to display it just hangs. I can see the switch to graphics mode as the font for the boot messages changes to the smaller hi-rez font but Plymouth does not load and there's no text prompt for my LUKS passphrase. So far the only way for me to now boot my PC is either reverting to the radeon driver (which causes my GPU to crash later when it needs to change power states) or to remove "rhgb quiet" from the kernel command line and to use a text only boot. So in contrast to Stephens experience above, everything was working with kernel 4.18.7 and it seems that something has changed between it and 4.18.8 (The Fedora release notes for the 4.18.8 kernel mention that AMDGOU DPM code has enabled by default for Southern Island GPUs could this new code be causing a conflict with Sea Island GPUs?)
> remove "rhgb quiet" You shouldn't need to remove 'quiet', only 'rhgb'. WRT Plymouth bug (non-)responses, see https://bugzilla.redhat.com/show_bug.cgi?id=1629393
(In reply to Stephen from comment #2) > > remove "rhgb quiet" > > You shouldn't need to remove 'quiet', only 'rhgb'. > > WRT Plymouth bug (non-)responses, see > https://bugzilla.redhat.com/show_bug.cgi?id=1629393 Thanks Stephen, I wasn't aware I could leave the 'quiet' parameter in place, it does make it a little easier to see the LUKS passphrase prompt now without all the other noise.
Proposed as a Blocker for 29-final by Fedora user catanzaro 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. [I]f any system partitions were encrypted as part of the installation, the boot process must prompt for the passphrase(s) and correctly unlock the partition(s) when provided with the correct passphrase(s).
I'm considering amdgpu to be a major driver that would affect many users if broken. At least my next machine will definitely have an RX 500, and I won't be very happy if I can't use Fedora on it....
CCing kernel folks, as this obviously involves the kernel drivers too.
This is a graphics driver issue so we need to make sure the graphics team is involved as well.
CCing the usual suspects!
Just a note on this, I've updated from F28 to the F29 pre-release and the issue I was experiencing seems to have been resolved. I have added "rhgb" back into the kernel boot parameters and the graphical boot is now working as before. If there are any tests I can run or if there are any logs or system information I can provide that might help pin point where the issue was resolved please let me know. I am now running kernel 4.18.11-300 but I noticed the issue was not present when I updated yesterday to F29 with kernel 4.18.10-300
Hm... I assume the bug still affects Stephen, given his recent complaints on fedora-devel@? The usual suspects should please check related bug #1490490 as well. :)
Just did a full update including 4.18.10 and re-enabled rhgb and seems to be back to the previous behaviour now. So it's no longer hanging without showing the Plymouth LUKS screen or the ability to enter the password or escape to text mode. It's now back to #1490490 behaviour with Plymouth not updating its output after showing the blank LUKS entry - just shows that all the way to GDM still.
I don't know how to edit the whiteboard for the other bug to nominate it for prioritisation as well, since I didn't create it, can someone else do it?
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. Note that you can still make your system boot by blindly typing in the disk password and then hitting enter. 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 ***