Bug 2154928

I managed to get through the error by workaround below and successfully upgraded RHEL8.7 to RHEL9

1. modify file: /usr/share/leapp-repository/repositories/system_upgrade/common/actors/targetuserspacecreator/libraries/userspacegen.py
   change line:
       '--releasever', api.current_actor().configuration.version.target,  
   to:
       '--releasever', '9',

2. modify file: /usr/share/leapp-repository/repositories/system_upgrade/common/libraries/dnfplugin.py

   change line:
       '--releasever', api.current_actor().configuration.version.target,  
   to:
       '--releasever', '9',



   change line:
       'releasever': get_target_version(),
   to:
       '--releasever', '9',

once those two files modified,  leapp pre-upgrade --target 9  and leapp upgrade --target 9 pass through successful.

correct rerun: leapp pre-upgrade --target 9.0  and leapp upgrade --target 9.0 pass through successful.

Hi JXia2, thank you for the report. What is the result when you do not specify the --target option? Anyway, in this particular issue, the satelilte server has not been configured correctly as it is expected to provide specific X.Y release. We know that release 9 can be used in general also in rhsm/satellite to refer just to the latest X repositories, however in this case it's expected to go to the particular exact rhel release. In the described case, the upgrade would go now e.g. to RHEL 9.1 instead of RHEL 9.0, which is unsupported. The expected fix here is to update the satellite configuration so the 9.0 repositories are provided as expected. From this point, I am suggesting to close the ticket as a) we do not want to enable the upgrade in an unsupported way b) the workaround is to correctly configure the satellite server. But I am keeping it opened for now in case we come with a reasonable solution or an improvement (e.g. we could possibly improve the error msg to inform people they should check the satellite server configuration).

hi Petr, thanks for your reply.  

1. What is the result when you do not specify the --target option?   I got exactly same error message if I don't specify --target option
2. the upgrade would go now e.g. to RHEL 9.1 instead of RHEL 9.0, which is unsupported. The expected fix here is to update the satellite configuration so the 9.0 repositories are provided as expected 

   yes I actually got upgraded to RHEL9.1 not 9.0,   however, I am not sure how to configure the satellite to 9.0 as I only see one repository available below to add to my content view:

Red Hat Enterprise Linux 9 for x86_64 - AppStream RPMs 9

for RHEL8.X,  there are repos available named as:

Red Hat Enterprise Linux 8 for Power little endian - BaseOS RPMs 8
and
Red Hat Enterprise Linux 8 for x86_64 - BaseOS RPMs 8.6
Red Hat Enterprise Linux 8 for x86_64 - BaseOS RPMs 8.7
Red Hat Enterprise Linux 8 for x86_64 - BaseOS RPMs 8.5 ....

but RHEL9 has only one repo available in my satellite server, so that's why I can't configure it to a specific version like 9.0 or 9.1

i believe once 9.1 is available in the satellite server the issue will be gone. 


thanks,
James

sorry i mean one version kind of RHEL9 repo available currently:

Red Hat Enterprise Linux 9 for x86_64 - BaseOS RPMs 9
Red Hat Enterprise Linux 9 for x86_64 - AppStream RPMs 9

no below existed in available repo list:
aRed Hat Enterprise Linux 9 for x86_64 - BaseOS RPMs 9.0
Red Hat Enterprise Linux 9 for x86_64 - AppStream RPMs 9.0

Thank you James for the provided information. I expect it should be already possible to configure 9.0 repositories explicitly in the Sattelite server, but I am not SME in this area and not sure why you can see listings for rhel 8 but not for rhel 9. Evgeni, any tips why 9.0 is not visible in the satellite and only "9" repos are present as mentioned above?

No, not really. I would also expect this to be possible (and it is on the 6.11 I have here for our environment).

I know that Satellite 6.10 does not officially support RHEL 9 (only 6.11+ does), as RHEL 9 has some new repository metadata for modular repositories that is not compatible with 6.10 and older, but that should not affect *seeing* the repositories.

*** Bug 2154929 has been marked as a duplicate of this bug. ***

Issue migration from Bugzilla to Jira is in process at this time. This will be the last message in Jira copied from the Bugzilla bug.

This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there.

Due to differences in account names between systems, some fields were not replicated.  Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information.

To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "RHEL-" followed by an integer.  You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like:

"Bugzilla Bug" = 1234567

In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues. You can also visit https://access.redhat.com/articles/7032570 for general account information.