Bug 1747177
Summary: | Allow registration when host is unregistered and DMI UUID has changed - Error: This host is reporting a DMI UUID that differs from the existing registration | ||||||
---|---|---|---|---|---|---|---|
Product: | Red Hat Satellite | Reporter: | Jonathon Turel <jturel> | ||||
Component: | Content Management | Assignee: | Jonathon Turel <jturel> | ||||
Status: | CLOSED ERRATA | QA Contact: | Lai <ltran> | ||||
Severity: | medium | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | 6.6.0 | CC: | achadha, aganbat, ahumbe, avroy, bernd.nies, bkearney, ehelms, ekirby, gprocunier, jbhatia, jcastran, jeanpaul.gatt, jjansky, kkinge, ktordeur, kupadhya, ltsai, mmccune, rbertolj, saydas, vmeghana, wpinheir, zhunting | ||||
Target Milestone: | 6.6.0 | Keywords: | Triaged | ||||
Target Release: | Unused | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Whiteboard: | |||||||
Fixed In Version: | rubygem-katello-3.12.0.21-1 | Doc Type: | If docs needed, set a value | ||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | |||||||
: | 1756056 (view as bug list) | Environment: | |||||
Last Closed: | 2019-10-22 12:47:58 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
Jonathon Turel
2019-08-29 20:04:34 UTC
Created from redmine issue https://projects.theforeman.org/issues/27739 Upstream bug assigned to jturel This is seen during registration when subscription-manager returns the error: HTTP error (422 - Unknown): This host is reporting a DMI UUID that differs from the existing registration. Hi, We are experiencing the same issue. We have satellite registering Virtual machines provisioned in openstack. We keep hitting the error: "HTTP error (422 - Unknown): This host is reporting a DMI UUID that differs from the existing registration.". Error was introduced when upgrading from 6.4 to 6.5. Running on 6.5.2.1 Can you suggest a fix? This has destroyed the ability of clients to create and destroy their machines on demand. *** Satellite 6.5.2.1 Hotfix Available *** 1) Download tfm-rubygem-katello-3.10.0.55-3.HOTFIXBZ17422041747177.el7sat.noarch.rpm from this bugzilla to your Satellite 2) Install: rpm -Uvh tfm-rubygem-katello-3.10.0.55-3.HOTFIXBZ17422041747177.el7sat.noarch.rpm 3) restart: satellite-maintain service restart 4) resume operations Created attachment 1614654 [details]
tfm-rubygem-katello-3.10.0.55-3.HOTFIXBZ17422041747177.el7sat.noarch.rpm
3 successful re-deploys, however I just got a new error .. not sure if its related but it occurs right after loading the katello-ca-consumer-latest and running the re-registration. HTTP error (400 - Bad Request): Problem creating unit ConsumerDTO [uuid: e85efceb-f79e-4b0d-81eb-59551fa0736e, name: cfme-database-0.idm.example.com, owner id: null] Having the same issue after updating from Satellite 6.5.1 to 6.5.2.1 last thursday. Steps to test: 1. Register a content host to a satellite 2. Unregister it 3. Create a file with the content host's DMI UUID in it: echo '{"dmi.system.uuid": "this-is-made-up"}' > /etc/rhsm/facts/uuid.facts 4. Reregister it to see that it works 5. Unregister content host 6. change the content host's DMI UUID: echo '{"dmi.system.uuid": "another-made-up"}' > /etc/rhsm/facts/uuid.facts 7. Reregister content host Expected result: Successfully registers host Actual result: Successfully registers host Note, you can update the DMI UUID multiple times and unregister and reregister the content host as you see fit. It will pass every time. Marking issue as verified. Tested on 6.6.0 snap 21 Hi, About the steps to test ... those would have worked even pre-patch, because a 'subscription-manager unregister' cleans up the instance from satellite (it was our work around)' However, deleting the instance or doing a 'subscription-manager clean' would only delete the local copy of the registration, and would probabbly cause the previous bug to be triggered. I should not that with this patch, the issue seems to have been mitigated. Maybe a 'dirty' deletion example should be included in the automated build testing to avoid this bug springing up again. *** Bug 1754596 has been marked as a duplicate of this bug. *** 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. https://access.redhat.com/errata/RHSA-2019:3172 The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days |