+++ This bug was initially created as a clone of Bug #1730146 +++ Foreman: 1.22.0 Katello: 3.12.0 While I've been working towards migrating from Spacewalk/RHSat5, I've been rebuilding hosts left & right. I've been making changes to the host records in TFM/Katello, triggering a host build, downloading a boot ISO, and rebuilding in place. The redhat-register provisioning template has been able to re-register and connect the host record. Now, I'm finding that this registration is failing. Adding a --force option doesn't seem to make a difference: root@<host> ~]# subscription-manager register --force --name="<FQhostname>" --org='Organization' --activationkey='dev-centos7,dev-mondorescue-el7' HTTP error (422 - Unknown): Please unregister or remove hosts which match this host before registering: <FQhostname> [root@<hostname> ~]# subscription-manager unregister This system is currently not registered. [root@<hostname> ~]# subscription-manager register --force --name="<FQhostname>" --org='Land_O_Lakes' --activationkey='dev-centos7,dev-mondorescue-el7' HTTP error (422 - Unknown): Please unregister or remove hosts which match this host before registering: <FQhostname> jturel suggested running "hammer host subscription unregister host <FQhostname>" on the TFM/Katello host prior to the rebuild. This work-around now lets me successfully register the host in place. What other data or logs can I supply? /var/log/rhsm/* doesn't seem to supply much detail beyond the above. --- Additional comment from on 2019-07-16T01:39:41Z Created from redmine issue https://projects.theforeman.org/issues/27251 --- Additional comment from on 2019-07-16T01:39:43Z Upstream bug assigned to None --- Additional comment from on 2019-07-16T01:41:29Z The same error can also be seen in the logs when the host is being rebuilt. The fix will likely involve triggering an unregister before the rebuild. --- Additional comment from on 2019-07-16T01:49:46Z Since this issue was entered in Red Hat Bugzilla, the pm_ack has been set to + automatically for the next planned release. --- Additional comment from on 2019-07-16T02:03:18Z Upstream bug assigned to jturel --- Additional comment from on 2019-07-16T17:26:04Z *** Bug 1730145 has been marked as a duplicate of this bug. *** --- Additional comment from on 2019-07-22T21:05:58Z *** Bug 1717006 has been marked as a duplicate of this bug. *** --- Additional comment from on 2019-07-22T21:07:05Z Please refer to associated duplicates for more instances of this error and additional details. - bug 1717006 - bug 1730883
The upstream PR has the testing steps outlined: https://github.com/Katello/katello/pull/8232 Let me know if I can clarify on anything and I can update the PR to serve as the authoritative test plan for this change.
Moving this bug to POST for triage into Satellite 6 since the upstream issue https://projects.theforeman.org/issues/27251 has been resolved.
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/RHBA-2019:2363
The errata doesnt resolve the issue: With Satellite 6.5.2.1 we now get: "HTTP error (422 - Unknown): This host is reporting a DMI UUID that differs from the existing registration." This error is fatal and no further action can be taken until the hosts are manually removed from satellite itself. The impact here outside of anything stated in the private comments is that this change is anathma to environments where servers are rebuilt over and over again (eg. Deploying stacks in OpenStack / CICD pipelines of various flavors where the nodes are rebuilt in-place)
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.
Having the same issue after updating from Satellite 6.5.1 to 6.5.2.1 last thursday.
Having same issue after updating from Satellite 6.4.4 to 6.5.2.1 today, 19-Sep-19. We are in the exact position as others - we register and re-register virtual machines constantly in our environment.
*** Bug 1757096 has been marked as a duplicate of this bug. ***