Bug 2356893 - Text Appearing under LUKS decryption box
Summary: Text Appearing under LUKS decryption box
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: plymouth
Version: 42
Hardware: x86_64
OS: Linux
unspecified
low
Target Milestone: ---
Assignee: Ray Strode [halfline]
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 2361223 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2025-04-02 12:21 UTC by Christopher Boni
Modified: 2025-06-23 15:52 UTC (History)
9 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2025-04-02 13:12:26 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Fedora 41 (19.49 KB, image/png)
2025-04-02 12:22 UTC, Christopher Boni
no flags Details
Fedora 42 (25.09 KB, image/png)
2025-04-02 12:22 UTC, Christopher Boni
no flags Details


Links
System ID Private Priority Status Summary Last Updated
freedesktop.org Gitlab plymouth plymouth issues 294 0 None opened Text under LUKS decryption box looks bad 2025-04-28 12:18:43 UTC

Description Christopher Boni 2025-04-02 12:21:26 UTC
Raising as I'm not certain if this is an intended change or a bug.

On Fedora 41 when I boot my device, I am giving a clean plymouth screen when prompted to decrypt my LUKS partition. 

When I upgrade to Fedora 42 (both via system-upgrade and nightly ISO) there now appears to be text under the box.

Screenshots attached.

Reproducible: Always

Steps to Reproduce:
1. Upgrade or install Fedora 42 with FDE option checked.
Actual Results:  
Text appears under the password input box.

Expected Results:  
No text.

Comment 1 Christopher Boni 2025-04-02 12:22:10 UTC
Created attachment 2083102 [details]
Fedora 41

Comment 2 Christopher Boni 2025-04-02 12:22:36 UTC
Created attachment 2083103 [details]
Fedora 42

Comment 3 Hans de Goede 2025-04-02 13:12:26 UTC
Thank you for reporting this.

This change is intentional, it brings Fedora in line with what RHEL has been doing for a long time already. Plymouth has always tried to draw this text but before it could not draw it since its "text label" plugin was not included in the initrd because of initrd size concerns.

plymouth upstream now has a new freetype "text label" plugin (vs the old still supported pango plugin) which brings a lot less dependencies into the initrd resolving the size concern. After this change was merged upstream, upstream's plymouth-populate-initrd script also started including the freetype "text label" plugin by default into the initrd and Fedora has basically followed what upstream is doing here.

(as for RHEL, RHEL uses to include a RHEL specific patch to plymouth-populate-initrd to include the old pango based "text label" plugin to be able to always show which disk us being unlocked under RHEL)

Comment 4 Hans de Goede 2025-04-28 09:53:01 UTC
*** Bug 2361223 has been marked as a duplicate of this bug. ***

Comment 5 Daniel Rusek 2025-04-28 10:08:20 UTC
Even though this was added on purpose, it looks very bad and half-baked. Especially since:

1. The text contains a colon at its end which makes sense for the original dialog from text console, but not for the Plymouth one.

2. The position of the Plymouth text is right below the password field. There is no empty space (line) between the password field amd the line of text. This makes it look bad.

Please, reconsider fixing this.

Comment 6 Hans de Goede 2025-04-28 11:50:38 UTC
(In reply to Daniel Rusek from comment #5)
> Even though this was added on purpose, it looks very bad and half-baked.
> Especially since:
> 
> 1. The text contains a colon at its end which makes sense for the original
> dialog from text console, but not for the Plymouth one.
> 
> 2. The position of the Plymouth text is right below the password field.
> There is no empty space (line) between the password field amd the line of
> text. This makes it look bad.
> 
> Please, reconsider fixing this.

This behavior has been been the upstream default and enabled in multiple enterprise distributions for quite a long time now.

With that said I do agree that this could use some improvements, but those really need to happen upstream and I'm afraid any improvements will need to come from the community, because I really do not have the bandwidth to work on this and AFAIK neither has anyone else at Red Hat.

As you mention 2 possible improvements would be to:

1. When plymouth gets the string to render the text, strip the colon at the end if it is in diskunlock screen mode
2. Add a couple of pixels of whitespace between the bottom of the passphrase entry box and the text line

An possible easy workaround would be to add support for a /etc/plymouth/plymouth-populate-initrd.conf file which should then just contain bourne-shell style VARIABLE=VAL lines, make /usr/libexec/plymouth/plymouth-populate-initrd parse that file and then allow setting some PLYMOUTH_XXX=VAL variable to disable the inclusion of "${PLYMOUTH_PLUGIN_PATH}/label-freetype.so" in the initrd. So basically add a line at the top to source the conf file if it exists and then add an extra condition to the if in this block:

if [ -f "${PLYMOUTH_PLUGIN_PATH}/label-freetype.so" ]; then
     inst ${PLYMOUTH_PLUGIN_PATH}/label-freetype.so $INITRDDIR
     # The label-freetype plugin expects it at this location
     mkdir -p $INITRDDIR/usr/share/fonts
     [ ! -z "$DEFAULT_FONT" ] && ln -s "$DEFAULT_FONT" $INITRDDIR/usr/share/fonts/Plymouth.ttf
     [ ! -z "$DEFAULT_MONOSPACE_FONT" ] && ln -s "$DEFAULT_MONOSPACE_FONT" $INITRDDIR/usr/share/fonts/Plymouth-monospace.ttf
fi

As you can see plymouth-populate-initrd is simply a shell script, so making this conditional based on a configfile setting should be easy.

Comment 7 Daniel Rusek 2025-04-28 12:08:28 UTC
Thanks for your reply!

I have reported is as an upstream issue here:

https://gitlab.freedesktop.org/plymouth/plymouth/-/issues/294

Comment 8 Hans de Goede 2025-04-28 12:12:55 UTC
(In reply to Daniel Rusek from comment #7)
> Thanks for your reply!
> 
> I have reported is as an upstream issue here:
> 
> https://gitlab.freedesktop.org/plymouth/plymouth/-/issues/294

Note upstream is basically me and Ray Strode who no longer is at Red Hat, so that is likely not going to do / help much. We really need an upstream pull-request with a fix, or even just the suggested plymouth-populate-initrd change so that users can configure things to get the old behavior back. I can take care of reviewing + merging upstream pull-requests for this.

Comment 9 Tomas Popela 2025-04-28 13:03:15 UTC
(In reply to Hans de Goede from comment #8)
> Note upstream is basically me and Ray Strode who no longer is at Red Hat

Just to clarify - Ray is still at Red Hat and still part of the Display group (previously called Desktop team), but actively working on different things. Luckily, we do have Adrian Vovk who started in the team just recently and he took over Plymouth maintenance.

Comment 10 Hans de Goede 2025-04-28 13:33:25 UTC
(In reply to Tomas Popela from comment #9)
> Just to clarify - Ray is still at Red Hat and still part of the Display
> group (previously called Desktop team), but actively working on different
> things. Luckily, we do have Adrian Vovk who started in the team just
> recently and he took over Plymouth maintenance.

My bad, I thought that I had seen some messages about Ray's Red Hat email no longer being valid or something amongst those lines, so I was under the impression that Ray had left Red Hat. It is good to hear that Ray is still at Red Hat.

Comment 11 Angelo Schirinzi 2025-05-06 09:15:54 UTC
(In reply to Hans de Goede from comment #6)
> (In reply to Daniel Rusek from comment #5)
> > Even though this was added on purpose, it looks very bad and half-baked.
> > Especially since:
> > 
> > 1. The text contains a colon at its end which makes sense for the original
> > dialog from text console, but not for the Plymouth one.
> > 
> > 2. The position of the Plymouth text is right below the password field.
> > There is no empty space (line) between the password field amd the line of
> > text. This makes it look bad.
> > 
> > Please, reconsider fixing this.
> 
> This behavior has been been the upstream default and enabled in multiple
> enterprise distributions for quite a long time now.
> 
> With that said I do agree that this could use some improvements, but those
> really need to happen upstream and I'm afraid any improvements will need to
> come from the community, because I really do not have the bandwidth to work
> on this and AFAIK neither has anyone else at Red Hat.
> 
> As you mention 2 possible improvements would be to:
> 
> 1. When plymouth gets the string to render the text, strip the colon at the
> end if it is in diskunlock screen mode
> 2. Add a couple of pixels of whitespace between the bottom of the passphrase
> entry box and the text line
> 
> An possible easy workaround would be to add support for a
> /etc/plymouth/plymouth-populate-initrd.conf file which should then just
> contain bourne-shell style VARIABLE=VAL lines, make
> /usr/libexec/plymouth/plymouth-populate-initrd parse that file and then
> allow setting some PLYMOUTH_XXX=VAL variable to disable the inclusion of
> "${PLYMOUTH_PLUGIN_PATH}/label-freetype.so" in the initrd. So basically add
> a line at the top to source the conf file if it exists and then add an extra
> condition to the if in this block:
> 
> if [ -f "${PLYMOUTH_PLUGIN_PATH}/label-freetype.so" ]; then
>      inst ${PLYMOUTH_PLUGIN_PATH}/label-freetype.so $INITRDDIR
>      # The label-freetype plugin expects it at this location
>      mkdir -p $INITRDDIR/usr/share/fonts
>      [ ! -z "$DEFAULT_FONT" ] && ln -s "$DEFAULT_FONT"
> $INITRDDIR/usr/share/fonts/Plymouth.ttf
>      [ ! -z "$DEFAULT_MONOSPACE_FONT" ] && ln -s "$DEFAULT_MONOSPACE_FONT"
> $INITRDDIR/usr/share/fonts/Plymouth-monospace.ttf
> fi
> 
> As you can see plymouth-populate-initrd is simply a shell script, so making
> this conditional based on a configfile setting should be easy.

This also persists when Plymouth is updated? Otherwise we should create a script to automate the overwriting of plymouth-populate-initrd every time Plymouth is updated.

Comment 12 Hans de Goede 2025-05-06 17:31:02 UTC
> This also persists when Plymouth is updated? Otherwise we should create a script to automate the overwriting of plymouth-populate-initrd every time Plymouth is updated.

No, /usr/libexec/plymouth/plymouth-populate-initrd is part of the package. The idea is to write a patch to the upstream version of the script (which is what Fedora ships) and submit a merge-request upstream with these changes:

https://gitlab.freedesktop.org/plymouth/plymouth/-/merge_requests

Comment 13 Waterboy 2025-06-23 15:52:41 UTC
Although intentional, this change seems like a poor design choice and does not make much sense from interface point of view. I agree that the newly introduced text line is unneeded and should be removed.


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