Bug 2356893
Summary: | Text Appearing under LUKS decryption box | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Christopher Boni <christopher> | ||||||
Component: | plymouth | Assignee: | Ray Strode [halfline] <rstrode> | ||||||
Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
Severity: | low | Docs Contact: | |||||||
Priority: | unspecified | ||||||||
Version: | 42 | CC: | drusek, gnome-sig, hdegoede, mail, muten619, ntwrk, rstrode, tim, tpopela | ||||||
Target Milestone: | --- | ||||||||
Target Release: | --- | ||||||||
Hardware: | x86_64 | ||||||||
OS: | Linux | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | Doc Type: | --- | |||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2025-04-02 13:12:26 UTC | Type: | --- | ||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | --- | |||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Attachments: |
|
Description
Christopher Boni
2025-04-02 12:21:26 UTC
Created attachment 2083102 [details]
Fedora 41
Created attachment 2083103 [details]
Fedora 42
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) *** Bug 2361223 has been marked as a duplicate of this bug. *** 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. (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. Thanks for your reply! I have reported is as an upstream issue here: https://gitlab.freedesktop.org/plymouth/plymouth/-/issues/294 (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. (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. (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. (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. > 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 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. |