Bug 2027787
Summary: | Undercloud upgrade to 16.2 fails because of missing dependencies of swtpm | ||
---|---|---|---|
Product: | Red Hat OpenStack | Reporter: | Tommy Doucet <tdoucet> |
Component: | openstack-tripleo-heat-templates | Assignee: | Jesse Pretorius <jpretori> |
Status: | CLOSED ERRATA | QA Contact: | Jason Grosso <jgrosso> |
Severity: | urgent | Docs Contact: | |
Priority: | urgent | ||
Version: | 16.2 (Train) | CC: | amcleod, andeshmu, apevec, bdobreli, chrisbro, ddepaula, goberle, jamsmith, jelynch, jen, jpretori, jzaher, kchamart, kgilliga, ldenny, lhh, ltamagno, marjones, mburns, ravsingh, rbruzzon, rjones, sathlang, svigan, uemit.seren |
Target Milestone: | z2 | Keywords: | Triaged |
Target Release: | 16.2 (Train on RHEL 8.4) | ||
Hardware: | Unspecified | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | openstack-tripleo-heat-templates-11.6.1-2.20211210022751.f24ae3e.el8ost | Doc Type: | Known Issue |
Doc Text: |
Disable the advanced-virt-for-rhel-8 repository before you install RHOSP 16.2, update from RHOSP 16.2 to a newer maintenance release, or upgrade from 16.1 to 16.2.
+
RHOSP hosts do not require the advanced-virt-for-rhel-8 repository. If you do not disable it, dependency issues cause the installation, update, or upgrade to fail. The dependency failures happen because the advanced-virt-for-rhel-8-x86_64-rpms repository is based on RHEL 8.latest, which does not work with RHEL 8.4.
+
As a workaround, disable the repositories. Perform the steps appropriate for your installation, update, or upgrade scenario.
+
* Scenario: new 16.2 installation or update from 16.2 to later version of 16.2.
+
$ subscription-manager repos --disable advanced-virt-for-rhel-8-x86_64-rpms
+
$ dnf module disable -y virt:av
+
$ dnf module enable -y virt:rhel
+
* Scenario: upgrade from 16.1→16.2.
+
$ subscription-manager repos --disable advanced-virt-for-rhel-8-x86_64-rpms
+
$ dnf module disable -y virt:8.2
+
$ dnf module enable -y virt:rhel
|
Story Points: | --- |
Clone Of: | Environment: | ||
Last Closed: | 2022-03-23 22:29:33 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Tommy Doucet
2021-11-30 16:09:11 UTC
The Advanced Virt EUS repo needs to be enabled, I think. With the release of RHEL 8.4, advanced-virt stopped using RHEL-versioned module names, like "virt:8.1" or "virt:8.2" and changed it to be "virt:av". So, to get the right "virt:av" module, I believe one has to now disable the enable advanced-virt-for-rhel-8-x86_64-rpms and enable advanced-virt-for-rhel-8-x86_64-eus-rpms repositories. This would not have been noticed until after RHEL 8.5 was released. (In reply to Lon Hohberger from comment #1) > The Advanced Virt EUS repo needs to be enabled, I think. > > With the release of RHEL 8.4, advanced-virt stopped using RHEL-versioned > module names, like "virt:8.1" or "virt:8.2" and changed it to be "virt:av". > > So, to get the right "virt:av" module, I believe one has to now disable the > enable advanced-virt-for-rhel-8-x86_64-rpms and enable > advanced-virt-for-rhel-8-x86_64-eus-rpms repositories. Do I need to do anything specific to get this repository? I tried locally with version locked to 8.4 and it cannot be found: ~~~ [stack@undercloud ~]$ sudo subscription-manager repos --disable=advanced-virt-for-rhel-8-x86_64-rpms 1 local certificate has been deleted. Repository 'advanced-virt-for-rhel-8-x86_64-rpms' is disabled for this system. [stack@undercloud ~]$ sudo subscription-manager repos --enable=advanced-virt-for-rhel-8-x86_64-eus-rpms Error: 'advanced-virt-for-rhel-8-x86_64-eus-rpms' does not match a valid repository ID. Use "subscription-manager repos --list" to see valid repositories. [stack@undercloud yum.repos.d]$ sudo subscription-manager repos --list | grep "advanced-virt-for-rhel-8-x86_64" Repo ID: advanced-virt-for-rhel-8-x86_64-debug-rpms Repo ID: advanced-virt-for-rhel-8-x86_64-source-rpms Repo ID: advanced-virt-for-rhel-8-x86_64-rpms ~~~ (In reply to Tommy Doucet from comment #4) > > Do I need to do anything specific to get this repository? I tried locally > with version locked to 8.4 and it cannot be found: > ~~~ > [stack@undercloud ~]$ sudo subscription-manager repos > --disable=advanced-virt-for-rhel-8-x86_64-rpms > 1 local certificate has been deleted. > Repository 'advanced-virt-for-rhel-8-x86_64-rpms' is disabled for this > system. > [stack@undercloud ~]$ sudo subscription-manager repos > --enable=advanced-virt-for-rhel-8-x86_64-eus-rpms > Error: 'advanced-virt-for-rhel-8-x86_64-eus-rpms' does not match a valid > repository ID. Use "subscription-manager repos --list" to see valid > repositories. > > [stack@undercloud yum.repos.d]$ sudo subscription-manager repos --list | > grep "advanced-virt-for-rhel-8-x86_64" > Repo ID: advanced-virt-for-rhel-8-x86_64-debug-rpms > Repo ID: advanced-virt-for-rhel-8-x86_64-source-rpms > Repo ID: advanced-virt-for-rhel-8-x86_64-rpms > ~~~ This is a confirmed issue which we are working to address. The workaround, for now, is to remove anything from this repository that is installed on the undercloud or overcloud. We are working to update documentation to reflect the known issue. We will also recommend that custom images be built on a host which is not part of the undercloud/overcloud. The documentation change for custom images will be tracked in https://bugzilla.redhat.com/show_bug.cgi?id=2030377 For anyone doing a 13->16.2 upgrade, the following will need to be done to avoid trying to enable the advanced virt repository. The upgrades environment file (from section 8.1) will need the following added to prevent leapp from trying to enable the repository during the upgrade. parameter_defaults: UpgradeLeappCommandOptions: " --enablerepo rhel-8-for-x86_64-baseos-eus-rpms --enablerepo rhel-8-for-x86_64-appstream-eus-rpms --enablerepo rhel-8-for-x86_64-highavailability-eus-rpms --enablerepo ansible-2.9-for-rhel-8-x86_64-rpms --enablerepo fast-datapath-for-rhel-8-x86_64-rpms " This will be changed to be the default with the release of fixes included in this bug. Followup to our stack meeting: We had no issues with the upgrade with advanced-virt-for-rhel-8-x86_64-rpms enabled. Since libguestfs-tools-c is not mandatory everything went fine after uninstalling it. Also, if customer has libguestfs-tools-c installed as per documentation and tried to upgrade, will this BZ actually fix this? (In reply to Tommy Doucet from comment #20) > Also, if customer has libguestfs-tools-c installed as per documentation and > tried to upgrade, will this BZ actually fix this? This BZ's primary fix is removing the mandatory usage of this repo. The repo as it stands now is not compatible with RHEL 8.4 and only provides RHEL 8.5-based packages. Access to the EUS-based repositories will be fixed in time, but we do not have an ETA just yet. In https://bugzilla.redhat.com/show_bug.cgi?id=2030377 we are noting and changing the docs for the image creation/modification to recommend against enabling that repo on the undercloud & overcloud. This repo can be used on any other non-EUS RHEL host and that would be better for that purpose anyway. Hopefully that answers your questions? Please go ahead and needinfo me if you have further questions. "Access to the EUS-based repositories will be fixed in time, but we do not have an ETA just yet." Are we tracking progress for this somewhere? For anyone updating from 16.1.7 to 16.2.1 with KSM enabled on compute nodes and failing during the converge step because of qemu-kvm-common missing in the repo (according to ansible.log), the following worked for us : - disabling advanced-virt-for-rhel-8-x86_64-rpms repo - disabling virt:8.2 module (@modulefailsafe repo from previous step) - enabling virt:rhel module which contains qemu-kvm-common Not sure if that's the good path to follow to fix this issue with KSM enabled, but worked for us. Hi Jesse, > Sofer, should we perhaps automate this in code so that it is automated and does not require a human to do? >> - name: disable default dnf module for virt >> command: dnf module disable -y virt:rhel >> become: true >> - name: disable 8.2 dnf module for virt >> command: dnf module disable -y virt:8.2 >> become: true >> - name: set dnf module for virt:av >> command: dnf module enable -y virt:av >> become: true At first glance this seems tricky to automate: - is that always true or is there some condition for this ? - that something that would run for 16.1->16.2 but also for 16.2->16.2, does that make a difference ? Thanks, (In reply to Sofer Athlan-Guyot from comment #35) > Hi Jesse, > > At first glance this seems tricky to automate: > - is that always true or is there some condition for this ? > - that something that would run for 16.1->16.2 but also for 16.2->16.2, does > that make a difference ? Something along the lines of: 16.2->16.2: subscription-manager repos --disable <advanced-virt repo> dnf module disable -y virt:av dnf module enable -y virt:rhel 16.1->16.2: subscription-manager repos --disable <advanced-virt repo> dnf module disable -y virt:8.2 dnf module enable -y virt:rhel Note that https://bugzilla.redhat.com/show_bug.cgi?id=2016379 removes the advanced virt components from 16.1 too. 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 (Moderate: Red Hat OpenStack Platform 16.2 (openstack-tripleo-heat-templates) security update), 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-2022:0995 Hey @jpretori Could we please get an offical decision on what the required steps are to put the customers mind at ease while we get the docs updated? Are we fine to just run with: ```` $ dnf module switch-to virt:rhel $ subscription-manager repos --disable advanced-virt-for-rhel-8-x86_64-rpms ``` Thanks a lot! The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days |