Bug 1429033 - Host provisioned with RHEL Workstation OS, after provisioning displayed as generic RedHat 7.3
Summary: Host provisioned with RHEL Workstation OS, after provisioning displayed as ge...
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: Subscription Management
Version: 6.2.7
Hardware: Unspecified
OS: Linux
high with 5 votes
Target Milestone: 6.8.0
Assignee: Marek Hulan
QA Contact: Cole Higgins
: 1497329 1510450 1685650 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2017-03-03 22:01 UTC by Pablo Hess
Modified: 2023-12-15 15:54 UTC (History)
29 users (show)

Fixed In Version: foreman-2.1.0-0
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2020-10-27 12:57:17 UTC
Target Upstream Version:

Attachments (Terms of Use)
Host displaying correct OS while provisioning (15.00 KB, image/png)
2017-03-03 22:01 UTC, Pablo Hess
no flags Details
Host changed after provisioning (38.14 KB, image/png)
2017-03-03 22:04 UTC, Pablo Hess
no flags Details
Content Host information displaying incorrect OS and correct Product (22.47 KB, image/png)
2017-03-03 22:05 UTC, Pablo Hess
no flags Details

System ID Private Priority Status Summary Last Updated
Foreman Issue Tracker 1513 0 Normal Closed RFE: more granular support for RedHat Enterprise Linux 2021-01-24 17:33:14 UTC
Red Hat Knowledge Base (Solution) 3189362 0 None None None 2017-09-19 15:20:15 UTC
Red Hat Product Errata RHSA-2020:4366 0 None None None 2020-10-27 12:57:53 UTC

Internal Links: 1905734 1917509 2056582

Description Pablo Hess 2017-03-03 22:01:25 UTC
Created attachment 1259739 [details]
Host displaying correct OS while provisioning

Description of problem:
Satellite server is hosting RHEL 7.3 Server and Workstation flavors.
Operating System named "RedHat 7.3" (the auto-created default) is configured to serve both Server and Workstation kickstart trees.
Operating System named "RHEL_Workstation 7.3" is configured to serve only the Workstation kickstart tree.
After PXE- or Discovery-installing a new host using "RHEL_Workstation 7.3" Satellite WebUI will display the correct OS i.e. "RHEL_Workstation 7.3" at Hosts > All hosts.
Once the new host registers with Satellite the OS is changed to "RedHat 7.3" which should not happen.
Clicking Hosts > All hosts > {hostname}, one will see:
* Installed Products > Product: "Red Hat Enterprise Linux Workstation 7.3"
* Content Host Properties > OS: RedHat 7.3    <---- This is what is wrong.

Version-Release number of selected component (if applicable):
Satellite 6.2.7

How reproducible:

Steps to Reproduce:

1. Add RHEL7 Workstation and Server repos/products to Satellite
2. Let the auto-generated Operating System i.e. "RedHat 7.3" serve both Server and Workstation kickstart trees
3. Create a new Operating System named e.g. "RHEL_Workstation 7.3" that serves only the Workstation kickstart tree
4. Provision a new host based on the "RHEL_Workstation 7.3" OS

Actual results:

Watch as Satellite displays the "RHEL_Workstation 7.3" Operating System during the install at Hosts > All hosts.

However, after the install finishes and the host reboots, Satellite displays "RedHat 7.3" on the Operating System column at Hosts > All hosts

Expected results:

Satellite should display "RHEL_Workstation 7.3" on the Operating System column at Hosts > All hosts.

Additional info:
picture Host--All_Hosts_during_install.png shows how the host appears during provisining.

picture Host--All_Hosts_after_provision.png shows how the host appears after provisioning.

picture Host--Content_Host_after_provision.png shows the Host OS and Product under Hosts > Content Host > {select host} > Details tab.

Comment 1 Pablo Hess 2017-03-03 22:04:41 UTC
Created attachment 1259740 [details]
Host changed after provisioning

Comment 2 Pablo Hess 2017-03-03 22:05:53 UTC
Created attachment 1259741 [details]
Content Host information displaying incorrect OS and correct Product

Comment 4 Bengt Giger 2017-06-13 12:03:04 UTC
We see the same problem. We have customized OSes which adapt the installation to our needs. This bug leads to some issues:

no bookkeeping of how many hosts are using a OS, customized OSes always report zero hosts. We have no clue which OSes have been used by our clients.

if someone reinstalls a system and forgets to change the OS back to the customized version, the installation will end up in a unusable state.

Comment 6 Natale Vinto 2017-06-30 09:06:18 UTC
Same issue here with Satellite 6.2.9 where customers need to modify newly created Hosts with parameters or just rebuilding them, and they fallback to RedHat default Operating System losing any customization in terms of Operating System, Provisioning templates and Partition table templates.

Comment 7 Pablo Hess 2017-08-07 19:48:02 UTC
Additional case hitting this bug where customer uses a custom partition table, provisioning template, and multiple parameters that are lost when Satellite sets up PXE provisioning i.e. before even provisioning the client system.

For instance, although Satellite is correctly building /var/lib/tftpboot/boot/my-custom-RHEL-7.4-x86_64-initrd.img the PXE provisioning template for this custom OS says:

APPEND initrd=boot/RedHat-7.4-x86_64-initrd.img

...instead of the expected:

APPEND initrd=boot/my-custom-RHEL-7.4-x86_64-initrd.img

In addition, customer gets multiple error messages from the webUI when reviewing or deleting or editing this host after it's provisioned, e.g.:

  partition table my-custom-parttable does not belong to RedHat 7.4 operating system

  Medium MyOrg/Library/MyCustom/Red_Hat_Enterprise_Linux_7_Server_Kickstart_x86_64_7_4 does not belong to RedHat 7.4 operating system

Both error messages above stem from the fact that the specified partition table and medium indeed belong to the custom OS instead of the default RedHat 7.4 OS.

Comment 11 jbury 2017-09-22 15:26:45 UTC
The following work arounds have been submitted for this bug - https://access.redhat.com/solutions/3189362 - Satellite 6: Customized OS and templates no longer associated with newly provisioned host.

Resolution #2 does not work. Set OS back to desired state via UI after is has been set back, like so: Hosts -> all Hosts -> <select_host> -> edit -> Operating System -> change to desired/actually configured OS.

If changed back manually as described in workaround, this does not start permanently until the host gets reinstalled. It will revert back after the next time the host reports back...

Note: I have not tried resolution 1.

Comment 12 Vincent S. Cojot 2017-10-04 19:51:12 UTC
*** Bug 1497329 has been marked as a duplicate of this bug. ***

Comment 15 Ivan Necas 2017-11-01 12:29:15 UTC
The reason for this behaviour is an attempt to unify the hosts being provisioned from the Satellite vs. those that are reported to the system via subscription-manager or puppet. Currently, the Satellite doesn't distinguish between the flavours, when parsing the facts.

In https://access.redhat.com/solutions/3189362, the resolution 1: "Change Settings -> Provisioning -> Ignore facts for operating system-> to true", should turn off assigning the operating system when parsing facts.

Comment 16 Ivan Necas 2017-11-08 13:06:15 UTC
*** Bug 1510450 has been marked as a duplicate of this bug. ***

Comment 17 Bengt Giger 2018-04-20 09:28:45 UTC
If my observations are correct, the "Ignore facts" setting now causes the issue, that systems upgraded ie. from 7.4 to 7.5 don't update the OS release information. We now have an growing number of systems displaying a wrong OS, which raises more and more discussions with our customers/sysadmins.

Comment 20 Marek Hulan 2019-03-06 08:04:47 UTC
*** Bug 1685650 has been marked as a duplicate of this bug. ***

Comment 21 Marek Hulan 2019-03-06 08:06:13 UTC
*** Bug 1510450 has been marked as a duplicate of this bug. ***

Comment 22 asamad 2019-03-12 19:33:30 UTC
Hello Marek,

I would require your help in updating the case as the customer is waiting for the resolution for more than 18 months and have an raised an escalation.

Customer has upgraded the satellite from 6.2 to 6.4 version, But still the issue persists.

Please let us know how long will it take to be fixed and on which version?

Comment 23 jayce 2019-03-13 18:34:35 UTC
Satellite 6.4.2- Same issue here

Comment 24 Marek Hulan 2019-03-25 11:40:51 UTC
Sadly, there hasn't been much progress on this yet. Both Workstation and Server are considered the same RHEL in terms of configuration management reporting. There's is no ETA at this moment. We need to see, what information we can get out of puppet facter (and other fact sources) and update the mapping.

Comment 26 Bryan Kearney 2019-04-01 12:13:12 UTC
The Satellite Team is attempting to provide an accurate backlog of bugzilla requests which we feel will be resolved in the next few releases. We do not believe this bugzilla will meet that criteria, and have plans to close it out in 1 month. This is not a reflection on the validity of the request, but a reflection of the many priorities for the product. If you have any concerns about this, feel free to contact Red Hat Technical Support or your account team. If we do not hear from you, we will close this bug out. Thank you.

Comment 27 Pablo Hess 2019-04-01 13:54:12 UTC
As you can see we have plenty of people hitting this bug ever since it was filed.  Chances are high that if this bug gets closed it will be re-opened pretty soon afterwards.

Alternatively, providing a reliable and not too burdensome workaround that will allow customers to track which systems of each flavor they have and what each system's flavor is would be nice before closing this bug. For example, /etc/redhat-release in those systems is probably displaying the "right" flavor, so couldn't we have Satellite use that as a source for the fact that will set a system's flavor?

Comment 32 Bryan Kearney 2019-05-02 18:52:49 UTC
Thank you for your interest in Satellite 6. We have evaluated this request, and while we recognize that it is a valid request, we do not expect this to be implemented in the product in the foreseeable future. This is due to other priorities for the product, and not a reflection on the request itself. We are therefore closing this out as WONTFIX. If you have any concerns about this, please do not reopen. Instead, feel free to contact Red Hat Technical Support. Thank you.

Comment 35 Bengt Giger 2019-05-02 22:05:52 UTC
WONTFIX? Other priorities? Red Hat product incapable of dealing with Red Hat products? This is a confession of failure, after 2 years we still have no solution. I have dozends of internal customers asking for fixing this bug, honestly, I'm upset. Looks as if RH is fading out the Workstation branch, maybe we should stop supporting Red Hat Workstations here and suggest to our customers to switch to another distribution.

Comment 37 Bryan Kearney 2019-05-06 13:00:39 UTC
I spoke with the developer and he stated this was being worked upstream. I am re-opening this.

Comment 40 Bryan Kearney 2020-03-17 16:07:11 UTC
Upstream bug assigned to mhulan

Comment 41 Bryan Kearney 2020-03-17 16:07:15 UTC
Upstream bug assigned to mhulan

Comment 42 Bryan Kearney 2020-04-01 14:06:47 UTC
Moving this bug to POST for triage into Satellite 6 since the upstream issue https://projects.theforeman.org/issues/1513 has been resolved.

Comment 51 errata-xmlrpc 2020-10-27 12:57:17 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 (Important: Satellite 6.8 release), and where to find the updated
files, follow the link below.

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


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