Bug 1629387 - Plymouth completely prevents boot with 4.18 + AMDGPU + LUKS
Summary: Plymouth completely prevents boot with 4.18 + AMDGPU + LUKS
Keywords:
Status: CLOSED DUPLICATE of bug 1490490
Alias: None
Product: Fedora
Classification: Fedora
Component: plymouth
Version: 28
Hardware: Unspecified
OS: Unspecified
unspecified
urgent
Target Milestone: ---
Assignee: Ray Strode [halfline]
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: PrioritizedBug
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-09-15 15:46 UTC by fednuc
Modified: 2019-06-12 08:44 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-10-02 18:36:28 UTC
Type: Bug


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1490490 0 unspecified CLOSED Plymouth doesn't echo LUKS keypresses or show boot progress with amdgpu+LUKS 2021-02-22 00:41:40 UTC

Internal Links: 1490490

Description fednuc 2018-09-15 15:46:13 UTC
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.

Comment 1 Shecks 2018-09-23 18:49:26 UTC
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?)

Comment 2 fednuc 2018-09-23 22:36:59 UTC
> 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

Comment 3 Shecks 2018-09-24 18:48:40 UTC
(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.

Comment 4 Fedora Blocker Bugs Application 2018-10-02 08:52:33 UTC
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).

Comment 5 Michael Catanzaro 2018-10-02 08:55:21 UTC
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....

Comment 6 Adam Williamson 2018-10-02 16:14:00 UTC
CCing kernel folks, as this obviously involves the kernel drivers too.

Comment 7 Laura Abbott 2018-10-02 16:22:11 UTC
This is a graphics driver issue so we need to make sure the graphics team is involved as well.

Comment 8 Adam Williamson 2018-10-02 16:23:14 UTC
CCing the usual suspects!

Comment 9 Shecks 2018-10-02 16:40:18 UTC
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

Comment 10 Michael Catanzaro 2018-10-02 17:35:46 UTC
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. :)

Comment 11 fednuc 2018-10-02 18:04:36 UTC
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.

Comment 12 fednuc 2018-10-02 18:38:49 UTC
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?

Comment 13 Hans de Goede 2019-06-12 08:44:25 UTC
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 ***


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