Hide Forgot
Description of problem: If a leapp upgrade attempt from RHEL7.6 to RHEL8 fails, subscription-manager reports that the system is unregistered. The system must then be re-registered with RHSM. Worth noting that this happens with multiple kinds of leapp failure. I observed this behaviour after: ============================================================ ERRORS ============================================================ 2019-04-23 18:56:15.249035 [ERROR] Actor: prepare_upgrade_transaction Message: Cannot find any required target repository. The list of available required repositories is empty. ============================================================ END OF ERRORS ============================================================ and ============================================================ ERRORS ============================================================ 2019-04-23 18:51:38.848719 [ERROR] Actor: prepare_upgrade_transaction Message: Cannot get release setting. A Leapp Command Error occurred. ============================================================ END OF ERRORS ============================================================ How reproducible: RHEL7.6 VM, registered directly to RHSM. Actual results: Run a leapp upgrade which fails, then check subscription status: [root@localhost ~]# subscription-manager list --installed +-------------------------------------------+ Installed Product Status +-------------------------------------------+ Product Name: Red Hat Enterprise Linux Server Product ID: 69 Version: 7.6 Arch: x86_64 Status: Not Subscribed Status Details: Starts: Ends: Expected results: Run a leapp upgrade which fails, then check subscription status: [root@localhost ~]# subscription-manager list --installed +-------------------------------------------+ Installed Product Status +-------------------------------------------+ Product Name: Red Hat Enterprise Linux Server Product ID: 69 Version: 7.6 Arch: x86_64 Status: Subscribed Status Details: Starts: 01/04/19 Ends: 31/03/20 Additional info: This occurs in the same manner on both leapp-0.6.0 and latest leapp-0.7.0 versions. As well as latest 0.7.0-1 version, I also tested on: leapp-0.6.0-1.201904110917Z.ac3f6a7.master.el7_6.noarch.rpm leapp-0.7.0-0.201904181545Z.ec8ba0a.fix_specfile.PR496.el7_6.noarch.rpm
Hi Russel, it's known issue. In my case the behaviour you described is same even when there is not fail in the preparation phase (just when you run `rhsm list` on the original RHEL 7 system after run of leapp). Kevin, you tried that time ago and it worked. Would you check it whether it is broken again or whether it is something related to configuration of system?
This isn't a bug, but rather a Redhat official document issue. The doc didn't provide all details you need to perform a in-place upgrade. I experienced same error but managed to make it working by doing this: 1. Follow all steps in this page: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/upgrading_to_rhel_8/index#preparing-a-rhel-7-system-for-the-upgrade_upgrading-to-rhel-8 2. Switch the server to a new Content View which has rhel 8 repos (baseOS, appstream); This step is needed because a repo mapping file stated that rhel 8 repo is needed for this upgrade: # cat /etc/leapp/files/repomap.csv RHEL 7 repo ID,RHEL 8 repo id,RHEL 7 minor versions,RHEL 8 minor versions,architecture,type(rpm/srpm/debuginfo) rhel-7-server-rpms,rhel-8-for-x86_64-baseos-rpms,all,all,x86_64,rpm rhel-7-server-rpms,rhel-8-for-x86_64-appstream-rpms,all,all,x86_64,rpm rhel-7-server-optional-rpms,codeready-builder-for-rhel-8-x86_64-rpms,all,all,x86_64,rpm 3. Continue the upgrade steps in chapter 3: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/upgrading_to_rhel_8/index#performing-the-upgrade-from-rhel-7-to-rhel-8_upgrading-to-rhel-8
Just update that information about satellite is now in the documentation as well.
The related PR in upstream: https://github.com/oamg/leapp-repository/pull/456
Sorry, I mean "test added", and verified in upstream. Proper VERIFIED will be once this runs with Brew build, so reverting back for now.
Since the test has been automated and part of our regression test suite, verification will be done by OAMG-2997.
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-2020:1959