Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
Red Hat Satellite engineering is moving the tracking of its product development work on Satellite 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 "Satellite project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs will be migrated starting at the end of May. 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 "Satellite project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/SAT-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.
Description of problem:
MC990X servers seem to have a hardcoded BIOS UUID. Example from the customer env (some data has been marked with 'X')
# dmidecode -s system-uuid; hostname -s
8B2C9555-5C8E-4221-BF48-DFF30244XXXX
li-lc-XXXX
# dmidecode -s system-uuid; hostname -s
8B2C9555-5C8E-4221-BF48-DFF30244XXXX
chbbhilsvXXX
# dmidecode -s system-uuid; hostname -s
8B2C9555-5C8E-4221-BF48-DFF30244XXXX
li-lq-XXXX
Version-Release number of selected component (if applicable): 6.5.2.1
How reproducible: Always.
Steps to Reproduce (untested, but should do the trick):
1. Override UUID on host1:
echo '{"virt.uuid": "4546B285-6C41-5D6R-86G5-0BFR4B3625FD"}' > /etc/rhsm/facts/virt_uuid.facts
2. Override the UUID on host2 (same as for host1):
echo '{"virt.uuid": "4546B285-6C41-5D6R-86G5-0BFR4B3625FD"}' > /etc/rhsm/facts/virt_uuid.facts
3. Try to register host1 and host2 (second will fail)
Actual results:
While we believed that the BIOS UUID should be unique, unfortunately it may not be and therefore the recently introduced UUID check fails here.
Expected results:
UUID cannot be trusted as being as unique as we expected it and we should think about another solution.
Additional info:
Overriding the UUID with some other uuid (generated via uuidgen) works as a workaround for the moment. Customer case is going to be attached.
Bryan,
For me as user with MC990 the workaround to override the UUID in the facts with a random value as described in KB4396951 is simple and works.
I do not see the need for more support in Sat6.
For me this BZ can be closed based on the current documentation
Peter
We released an update in Satellite 6.7 that allows disabling of the UUID uniqueness constraint:
https://bugzilla.redhat.com/show_bug.cgi?id=1772199
How to use verify and use the new setting:
1. Added following configuration line to /etc/candlepin/candlepin.conf
candlepin.use_system_uuid_for_matching=false
2. satellite-maintain serivce restart
3. Set the uuid to be the same on two hosts
echo '{"virt.uuid": "4546B285-6C41-5D6R-86G5-0BFR4B3625FD", "virt.is_guest":"True"}' > /etc/rhsm/facts/virt_uuid.facts
4. Registered both hosts to the satellite
Comment 16Red Hat Bugzilla
2024-02-04 04:25:21 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days
Description of problem: MC990X servers seem to have a hardcoded BIOS UUID. Example from the customer env (some data has been marked with 'X') # dmidecode -s system-uuid; hostname -s 8B2C9555-5C8E-4221-BF48-DFF30244XXXX li-lc-XXXX # dmidecode -s system-uuid; hostname -s 8B2C9555-5C8E-4221-BF48-DFF30244XXXX chbbhilsvXXX # dmidecode -s system-uuid; hostname -s 8B2C9555-5C8E-4221-BF48-DFF30244XXXX li-lq-XXXX Version-Release number of selected component (if applicable): 6.5.2.1 How reproducible: Always. Steps to Reproduce (untested, but should do the trick): 1. Override UUID on host1: echo '{"virt.uuid": "4546B285-6C41-5D6R-86G5-0BFR4B3625FD"}' > /etc/rhsm/facts/virt_uuid.facts 2. Override the UUID on host2 (same as for host1): echo '{"virt.uuid": "4546B285-6C41-5D6R-86G5-0BFR4B3625FD"}' > /etc/rhsm/facts/virt_uuid.facts 3. Try to register host1 and host2 (second will fail) Actual results: While we believed that the BIOS UUID should be unique, unfortunately it may not be and therefore the recently introduced UUID check fails here. Expected results: UUID cannot be trusted as being as unique as we expected it and we should think about another solution. Additional info: Overriding the UUID with some other uuid (generated via uuidgen) works as a workaround for the moment. Customer case is going to be attached.