Description of problem: Undercloud 16.2 upgrade fails because missing rpm dependencies from libguestfs-tools-c. Customer had libguestfs-tools-c installed based on https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.1/html-single/creating_and_managing_images/index#section-create-custom-images . If you try to upgrade you will get a dependency error running 'openstack undercloud upgrade'. Version-Release number of selected component (if applicable): Red Hat OpenStack Platform 16.2 Red Hat Enterprise Linux 8.4 (installation locked to 8.4) libguestfs-tools-c.x86_64 1:1.44.0-3.module+el8.5.0+10681+17a9b157 @advanced-virt-for-rhel-8-x86_64-rpms Repositories set as per https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.2/html/director_installation_and_usage/preparing-for-director-installation#enabling-repositories-for-the-undercloud How reproducible: Always. Steps to Reproduce: Reproduced at step 'openstack undercloud upgrade': https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.2/html-single/keeping_red_hat_openstack_platform_updated/index#proc_performing-a-minor-update-of-a-containerized-undercloud_updating-undercloud Actual results: Getting dependencies error: ~~~ ``` 2021-11-24 15:08:01.126496 | 005056bd-1f66-e263-128f-00000000021f | FATAL | Update all packages | director-test2 | error={"changed": false, "failures": [], "msg": "Depsolve Error occured: \n Problem 1: cannot install the best update candidate for package swtpm-0.4.2-1.20201201git2df14e3.module+el8.4.0+9341+96cf2672.x86_64\n - nothing provides selinux-policy >= 3.14.3-80.el8 needed by swtpm-0.6.0-2.20210607gitea627b3.module+el8.5.0+12696+4ce1c6bc.x86_64\n - nothing provides selinux-policy-base >= 3.14.3-80.el8 needed by swtpm-0.6.0-2.20210607gitea627b3.module+el8.5.0+12696+4ce1c6bc.x86_64\n Problem 2: package swtpm-tools-0.6.0-2.20210607gitea627b3.module+el8.5.0+12696+4ce1c6bc.x86_64 requires swtpm = 0.6.0-2.20210607gitea627b3.module+el8.5.0+12696+4ce1c6bc, but none of the providers can be installed\n - cannot install the best update candidate for package swtpm-tools-0.4.2-1.20201201git2df14e3.module+el8.4.0+9341+96cf2672.x86_64\n - nothing provides selinux-policy >= 3.14.3-80.el8 needed by swtpm-0.6.0-2.20210607gitea627b3.module+el8.5.0+12696+4ce1c6bc.x86_64\n - nothing provides selinux-policy-base >= 3.14.3-80.el8 needed by swtpm-0.6.0-2.20210607gitea627b3.module+el8.5.0+12696+4ce1c6bc.x86_64\n Problem 3: problem with installed package swtpm-0.4.2-1.20201201git2df14e3.module+el8.4.0+9341+96cf2672.x86_64\n - package swtpm-0.4.2-1.20201201git2df14e3.module+el8.4.0+9341+96cf2672.x86_64 requires swtpm-libs = 0.4.2-1.20201201git2df14e3.module+el8.4.0+9341+96cf2672, but none of the providers can be installed\n - cannot install both swtpm-libs-0.6.0-2.20210607gitea627b3.module+el8.5.0+12696+4ce1c6bc.x86_64 and swtpm-libs-0.4.2-1.20201201git2df14e3.module+el8.4.0+9341+96cf2672.x86_64\n - cannot install the best update candidate for package swtpm-libs-0.4.2-1.20201201git2df14e3.module+el8.4.0+9341+96cf2672.x86_64\n - nothing provides selinux-policy >= 3.14.3-80.el8 needed by swtpm-0.6.0-2.20210607gitea627b3.module+el8.5.0+12696+4ce1c6bc.x86_64\n - nothing provides selinux-policy-base >= 3.14.3-80.el8 needed by swtpm-0.6.0-2.20210607gitea627b3.module+el8.5.0+12696+4ce1c6bc.x86_64", "rc": 1, "results": []} ~~~ We can see details when running the command manually: ~~~ [stack@undercloud ~]$ sudo dnf update -y Updating Subscription Management repositories. Last metadata expiration check: 3:55:47 ago on Fri 26 Nov 2021 11:47:30 AM EST. Error: Problem 1: cannot install the best update candidate for package swtpm-0.4.2-1.20201201git2df14e3.module+el8.4.0+9341+96cf2672.x86_64 - nothing provides selinux-policy >= 3.14.3-80.el8 needed by swtpm-0.6.0-2.20210607gitea627b3.module+el8.5.0+12696+4ce1c6bc.x86_64 - nothing provides selinux-policy-base >= 3.14.3-80.el8 needed by swtpm-0.6.0-2.20210607gitea627b3.module+el8.5.0+12696+4ce1c6bc.x86_64 Problem 2: package swtpm-tools-0.6.0-2.20210607gitea627b3.module+el8.5.0+12696+4ce1c6bc.x86_64 requires swtpm = 0.6.0-2.20210607gitea627b3.module+el8.5.0+12696+4ce1c6bc, but none of the providers can be installed - cannot install the best update candidate for package swtpm-tools-0.4.2-1.20201201git2df14e3.module+el8.4.0+9341+96cf2672.x86_64 - nothing provides selinux-policy >= 3.14.3-80.el8 needed by swtpm-0.6.0-2.20210607gitea627b3.module+el8.5.0+12696+4ce1c6bc.x86_64 - nothing provides selinux-policy-base >= 3.14.3-80.el8 needed by swtpm-0.6.0-2.20210607gitea627b3.module+el8.5.0+12696+4ce1c6bc.x86_64 Problem 3: problem with installed package swtpm-0.4.2-1.20201201git2df14e3.module+el8.4.0+9341+96cf2672.x86_64 - package swtpm-0.4.2-1.20201201git2df14e3.module+el8.4.0+9341+96cf2672.x86_64 requires swtpm-libs = 0.4.2-1.20201201git2df14e3.module+el8.4.0+9341+96cf2672, but none of the providers can be installed - cannot install both swtpm-libs-0.6.0-2.20210607gitea627b3.module+el8.5.0+12696+4ce1c6bc.x86_64 and swtpm-libs-0.4.2-1.20201201git2df14e3.module+el8.4.0+9341+96cf2672.x86_64 - cannot install the best update candidate for package swtpm-libs-0.4.2-1.20201201git2df14e3.module+el8.4.0+9341+96cf2672.x86_64 - nothing provides selinux-policy >= 3.14.3-80.el8 needed by swtpm-0.6.0-2.20210607gitea627b3.module+el8.5.0+12696+4ce1c6bc.x86_64 - nothing provides selinux-policy-base >= 3.14.3-80.el8 needed by swtpm-0.6.0-2.20210607gitea627b3.module+el8.5.0+12696+4ce1c6bc.x86_64 (try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages) ~~~ Expected results: Either fix dependencies issues with this or update documentation telling customer to first remove libguestfs-tools-c before moving forward with upgrade. Additional Information: Workaround from case was uninstalling libguestfs-tools-c and proceed then reinstall if needed once everything is complete, which will probably lead to the same issue on the next version upgrade.
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