Hide Forgot
Description of problem: Latest package provides only 69.pem files for lates minor releases. aka 7.2 6.7 5.11.. and does not care on which version of rhel is installed Version-Release number of selected component (if applicable): subscription-manager-migration-data-2.0.22-1.el6.noarch.rpm How reproducible: 100% Steps to Reproduce: 1.have rhel 6.5 2.install subscription-manager-migration and subscription-manager-migration-data 3. rct cat-cert /etc/pki/product-default/69.pem Actual results: Version 6.7 Expected results: Version 6.5 Additional info: This is an issue when system is subscribed to satellite 6 server with channels for minor releases. Rhel 6.5 with 69.pem from 6.7 can no get updates from 6.5 minor release repository
having different info from /etc/redhat-release and 69.pem is not a problem when the server is subcribed do cdn.redhat.com via RHSM or to satellite with 6server or 7server channel. Issue is only when system is subscribed to satellite with minor release channel.
/etc/pki/product-default/69.pem is provided by the redhat-release package, not the subscription-manager-migration-data package. rpm -q --whatprovides /etc/pki/product-default/69.pem
Part of the value of a RHEL subscription is that it entitles your RHEL system to the latest updates. It sounds like you originally installed RHEL6.5 and subscribed the system to RHEL and have been getting updates from release 6Server which is the latest and greatest. To lock your RHEL 6.5 system to content for a specific minor release. There is a "subscription-manager release --list" command that shows you the available releases. You could have used "subscription-manager release --set 6.5" BEFORE you ran yum update. That would have locked your entitled content repo paths to a 6.5 path and then a yum update will no longer get packages from the latest minor releases.
*** Bug 1331438 has been marked as a duplicate of this bug. ***
It appears that the issue was with Satellite content set and activation key configuration & the configuration of the system while the various migration scripts were run. Stefen, given that we don't see an obvious bug in the existing code can you provide an internal reproducer that engineering can access in order to debug further?