Bug 1306543

Summary: Provide a mechanism to set a custom splash screen string
Product: Red Hat Enterprise Linux 7 Reporter: Fabian Deutsch <fdeutsch>
Component: plymouthAssignee: Ray Strode [halfline] <rstrode>
Status: CLOSED ERRATA QA Contact: Desktop QE <desktop-qa-list>
Severity: unspecified Docs Contact:
Priority: urgent    
Version: 7.3CC: bmcclain, cshao, dfediuck, lkolacek, mgoldboi, rstrode, tpelka, weiwang, yaniwang, ycui, ylavi
Target Milestone: alpha   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Fixed In Version: plymouth-0.8.9-0.25.20140113.el7 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1339769 (view as bug list) Environment:
Last Closed: 2016-11-04 07:53:15 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On: 1339769    
Bug Blocks: 1329957, 1331318    

Description Fabian Deutsch 2016-02-11 09:05:38 UTC
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)

Comment 1 Fabian Deutsch 2016-02-11 09:10:01 UTC
The pretty name can be used if we drop the bugzilla product frmo os-release, but this will break abrt - thus it is not an option.

Comment 3 Fabian Deutsch 2016-02-22 15:42:06 UTC
Maybe the patch in comment 2 can be even reverted. Because IIUIC the boot media (for which teh patch got introduced) is just created once for a minor release

Comment 4 Fabian Deutsch 2016-04-29 07:13:35 UTC
Please consider this as a blocker for 7.3, as this is pretty important for RHEV.

Comment 6 Ray Strode [halfline] 2016-05-25 19:51:09 UTC
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 7 Fabian Deutsch 2016-06-09 10:45:14 UTC

The problem I see is that
FAMILY_NAME and PRETTY_FAMILY_NAME are not covered by the upstream spec:

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"
PRETTY_NAME="Red Hat Enterprise Virtualization Hypervisor 4.0"
PRETTY_FAMILY="Red Hat Enterprise Virtualization 4.0"
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"

= Fedora =
NAME="oVirt Node"
PRETTY_NAME="oVirt Node 4.0"
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.


Comment 8 Ray Strode [halfline] 2016-06-09 12:31:22 UTC
we should probably chat on bug 1339769, but just a few comments…

I don't think it's a problem to use fields not specified in the spec.  the spec explicitly allows for this:

   Operating system vendors may extend the file format and introduce
   new fields. It is highly recommended to prefix new fields with an
   OS specific name in order to avoid name clashes. Applications
   reading this file must ignore unknown fields.

Though given the above, maybe the field name should be RED_HAT_PRODUCT_FAMILY= It probably doesn't matter in practice. another option is we could get the spec extended

Otherwise, what you're saying makes sense to me.  Can you post it on bug 1339769?

As to whether or not its worth it…  the advantage is I can strip out code that assumes the strings are in a specific format and tries to munge out parts of them.  The disadvantage is we'll have to fix all the os-release files in redhat-release-* (and dracut too?).  In the end, we have a good enough solution for RHEL 7, but there's a bit of technical debt with the current situation.  We could just shelf this whole initiative, though, and reopen Red Hatbug 911553 against lorax or something.  At the end of the day, the real problem is the file is wrong, and all of these solutions are trying to work around that problem.  We already have per-product files for the installer, so I don't see why this os-release, fundamentally can't be per-product too.

Comment 9 Fabian Deutsch 2016-06-09 13:38:31 UTC
For RHEV-H we actually moved to have a os-release for this product.
I think what is missing here a bit is a scheme how we can represent the "layering" in the os-release file.

I.e. one problem is that many consuming packages depend on the ID string, thus for our layerd product (RHEVH) we kept the ID (and all the non pretty variables) to how rhel set it.
We just adjusted PRETTY* and VARIANT* variables to represent our product.

I'd actually expect that other layered products do it the same.
At best we'd have a method which scales to this layering.
I.e. RHEl -> RHEV -> RHEV-H can currently not be presented.
Or RHEL -> CF -> CF Appliance

Currently we just have a wo-step layering mechanism.

Myabe it makes sense to have a nice way ready when we get to the more modular approach.

Comment 14 errata-xmlrpc 2016-11-04 07:53:15 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.