Need help understanding confusing error message on Rocky 8.7 update

[roc]

When running dnf upgrade --security on a Rocky 8.7 vm, we received an error message that I do not understand. One error appears to be that the upgrade cannot be performed because the upgrade would re-install existing glibc packages and re-installing the existing packages would conflict with the upgrade of those packages. The other error appears to be that the upgrade cannot be performed on account of the requirements of an existing package that will be replaced in the upgrade.

Error:
  Problem 1: glibc-2.28-211.el8.i686 has inferior architecture
   - cannot install both glibc-2.28-225.el8_8.6.x86_64 and glibc-2.28-211.el8.x86_64
   - cannot install the best update candidate for package glibc-2.28-211.el8.i686
   - cannot install the best update candidate for package glibc-2.28-211.el8.x86_64
  Problem 2: package glibc-gconv-extra-2.28-211.el8.i686 requires glibc-common = 2.28-211.el8, but none of the providers can be installed
   - cannot install both glibc-common-2.28-225.el8_8.6.x86_64 and glibc-common-2.28-211.el8.x86_64
   - cannot install the best update candidate for package glibc-gconv-extra-2.28-211.el8.i686
   - cannot install the best update candidate for package glibc-common-2.28-211.el8.x86_64

dnf list --installed glibc* shows the 2.28-211.el8 versions of the glilbc packages already is installed:

# dnf list --installed glibc*
Installed Packages
glibc.i686                            2.28-211.el8 
glibc.x86_64                       2.28-211.el8 
glibc-common.x86_64        2.28-211.el8 
glibc-devel.x86_64             2.28-211.el8 
glibc-gconv-extra.i686        2.28-211.el8 
glibc-gconv-extra.x86_64   2.28-211.el8 
glibc-headers.x86_64         2.28-211.el8
glibc-langpack-en.x86_64  2.28-211.el8

dnf check-update glilbc* shows all would be updated to 2.28-225:

# dnf check-update glibc*
Last metadata expiration check: 0:27:57 ago on Sun 19 Nov 2023 05:55:06 PM PST.

glibc.i686                                2.28-225.el8_8.6
glibc.x86_64                           2.28-225.el8_8.6
glibc-common.x86_64            2.28-225.el8_8.6
glibc-devel.x86_64                 2.28-225.el8_8.6
glibc-gconv-extra.i686            2.28-225.el8_8.6
glibc-gconv-extra.x86_64       2.28-225.el8_8.6
glibc-headers.x86_64             2.28-225.el8_8.6
glibc-langpack-en.x86_64      2.28-225.el8_8.6

Why does dnf upgrade indicate glibc-2.28-211.el8.x86_64 would re-installed (Problem 1) when it already is installed and, as shown by dnf check-update, would be upgraded to 2.28-225?

Why are the requirements of glibc-gconv-extra-2.28-211.el8.i686 taken into account (Problem 2) when dnf check-update shows that package will be replaced by glibc-gconv-extra.i686.2.28-225.el8_8.6?

What would be the best way to resolve these errors so that we can proceed with the upgrade?

[nazunalika]

The issue is you have i686 packages (32-bit packages) installed, which is where this problem stems from. The errata that dnf is picking up is likely not taking the i686 versions of glibc into account, and thus this issue. If you do not need the i686 packages for glibc, then you can remove them and attempt to update again.

However, the best way to resolve this issue is to update your system to the latest packages available using dnf update. 8.7 is no longer supported. 8.8 is soon to be out of support with the pending release of 8.9.

Rocky Linux Release Version Guide - Rocky Linux Wiki

[roc]

@nazunalika

i686 packages (

Thank you for your reply. Our goal is to upgrade to 8.8, but space limitations require that we upgrade in stages and our plan was to first to update 8.7 security and then upgrade to 8.8, which worked perfectly on a similarly-configured machine.

As far as I know, no 32-bit application was intentionally installed. Running rpm -q --whatrequires glibc-2.28-211.el8.i686 gives this response no package requires glibc-2.28-211.el8.i686 and rpm -q --whatrequires glibc-gconv-extra.2.28-211.el8.i686 gives no package requires glibc-gconv-extra.2.28-211.el8.i686. Is this sufficient to confirm that we do not need these i686 packages and that it is safe to remove them?

[jlehtone]

@roc

As far as I know, no 32-bit application was intentionally installed.

You can do:

dnf remove glibc.i686

just don’t automatically say ‘yes’. Look at what dnf proposes to do. If there are
application packages in the “dependents to remove”, then you have to evaluate
whether they are really needed. If the list has only 32-bit “system packages”, then
let them go.

A user could install themselves an application that is not from a RPM package.
Such 32-bit binaries cannot be detected by dnf. I’d say: remove and reinstall
later, if such need shows up.

---

One can run dnf --enablerepo=* clean all between sets of packages, if the cached content is in the limited space.

[roc]

Brilliant!

dnf remove glibc.i686 revealed that the two 32-bit glibc packages were required by a long-unused agent for our backup system. Oddly, the agent is a 64-bit package which makes it hard to understand why dnf considered it to require 32-bit packages. In any case, because the agent is not being used, I let it be removed along with the two 32-bit glibc packages and then proceeded with the Rocky upgrade.

Thank you both very much for your help.