RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1339769 - Provide a mechanism to set a custom splash screen string
Summary: Provide a mechanism to set a custom splash screen string
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: redhat-release
Version: 7.3
Hardware: Unspecified
OS: Unspecified
urgent
unspecified
Target Milestone: alpha
: ---
Assignee: Lubos Kocman
QA Contact: Release Test Team
URL:
Whiteboard:
Depends On:
Blocks: 1306543
TreeView+ depends on / blocked
 
Reported: 2016-05-25 19:53 UTC by Ray Strode [halfline]
Modified: 2017-08-31 18:49 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1306543
Environment:
Last Closed: 2017-01-04 12:17:07 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Ray Strode [halfline] 2016-05-25 19:53:19 UTC
+++ This bug was initially created as a clone of Bug #1306543 +++

Description of problem:
Normally plymouth is using the pretty name as a the splash screen string.
But currently RHEL has a hack to use the bugzilla product name for the splash screen string.
This is a problem for RHEV, because the bugzilla product name is "Red Hat Enterprise Virtualization Manager", but the splash screen is for the "Red Hat Enterprise Linux Virtualization Hypervisor".

Please either revert the hack or provide a mechanism to specifically set the plymouth splash screen (i.e. by looking for another field in os-release, like PLYMOUTH_TITLE)

--- Additional comment from Ray Strode [halfline] on 2016-05-25 15:51:09 EDT ---

So what I've done is reverted the initial patch and then special cased "Red Hat Enterprise Linux" to strip out its variant (and some dracut gook that's snuck in).  This is probably good enough for now, but it's pretty messy.

What we really need, going forward is a new field in /etc/os-release that we can use wholesale. I don't think it should be called PLYMOUTH_TITLE as suggested in comment 0, since it's not really plymouth specific in any way.  Maybe PRETTY_FAMILY_NAME or something, and if it's not there we should fall back to PRETTY_NAME.

I'll file a separate bug about that.

Comment 1 Ray Strode [halfline] 2016-05-25 19:56:23 UTC
so to be clear, the request is to add

PRETTY_FAMILY_NAME="Red Hat Enterprise Linux 7"

(or something like that) to all the redhat-release packages.

See bug 911553 for the original problem and workaround and bug 1306543 for where that workaround proved inadequate.

Comment 3 Fabian Deutsch 2016-06-09 13:34:33 UTC
Copy-n-paste from bug 1306543

PRETTY_FAMILY_NAME sounds good.

The problem I see is that
FAMILY_NAME and PRETTY_FAMILY_NAME are not covered by the upstream spec:
https://www.freedesktop.org/software/systemd/man/os-release.html

Maybe we should have a complete story around this, as in:
What do we need to differentiate, and why isn't NAME enough?
How is NAME different from FAMILY_NAME?
What is the difference between PRETTY_NAME and PRETTY_FAMILY_NAME?

Is teh story that FAMILY is something like the product family, and NAME referring to the specific product in a family, i.e.:

Family: RHEL
Name: RHEL Atomic Host

Family: RHEV
Name: RHEV Hypervisor

Family: Fedora
Name: Fedora
Family: CentOS
Name: CentOS
^^ This is awkward

Family: Fedora
Name: Workstation
^^ Makes more sense

Specififc examples:

= RHEV =
FAMILY="Red Hat Enterprise Virtualization"
NAME="Red Hat Enterprise Virtualization Hypervisor"
VARIANT="Hypervisor"
PRETTY_NAME="Red Hat Enterprise Virtualization Hypervisor 4.0"
PRETTY_FAMILY="Red Hat Enterprise Virtualization 4.0"
ID="rhel"
VARIANT_ID="ovirt-node"
VERSION_ID="7.2"     <- We keep RHEL's version, but use RHEV's version in PRETTY

= Atomic =
FAMILY="Red Hat Enterprise Linux"
NAME="Red Hat Enterprise Linux Atomic Host"
VARIANT="Atomic Host"
PRETTY_NAME="Red Hat Enterprise Linux Atomic Host 7.2"
PRETTY_FAMILY="Red Hat Enterprise Linux 7.2"
ID="rhel"
VARIANT_ID="atomic-host"
VERSION_ID="7.2"

= Fedora =
NAME="oVirt Node"
FAMILY="oVirt"
VARIANT="Node"
PRETTY_NAME="oVirt Node 4.0"
PRETTY_FAMILY="oVirt 4.0"
ID="rhel"
VARIANT="ovirt-node"
VERSION_ID="7.2"     <- We keep RHEL's version, but use RHEV's version in PRETTY


In the end I am not sure if we benefit from this.

Thoughts?

Comment 4 Lubos Kocman 2017-01-04 12:17:07 UTC
Hello team,

I do agree, if we involve some custom fields that only Red Hat ships, we'll diverge even more from upstream.

Closing as WON'T FIX unless there would be part of systemd documentation. Feel free to reopen bug and move it to systemd.

Otherwise I generally agree about the idea, but would use bit different methodology

Layered Product/Base product which is what we use in PDC, Productmd ...

Lubos


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