RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1996681 - yum tries to install packages with incompatible architecture when multilib_policy=all
Summary: yum tries to install packages with incompatible architecture when multilib_po...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: yum
Version: 9.0
Hardware: Unspecified
OS: Unspecified
low
unspecified
Target Milestone: rc
: ---
Assignee: Jaroslav Mracek
QA Contact: Eva Mrakova
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-08-23 13:11 UTC by Jan Stodola
Modified: 2022-06-24 12:32 UTC (History)
5 users (show)

Fixed In Version: dnf-4.10.0-2.el9
Doc Type: No Doc Update
Doc Text:
Clone Of: 1995630
Environment:
Last Closed: 2022-05-17 15:55:05 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHELPLAN-94441 0 None None None 2021-08-23 13:11:55 UTC
Red Hat Product Errata RHBA-2022:3957 0 None None None 2022-05-17 15:55:12 UTC

Description Jan Stodola 2021-08-23 13:11:04 UTC 
+++ This bug was initially created as a clone of Bug #1995630 +++

Description of problem:
When multilib_policy=all is specified in yum.conf, yum tries to install even packages with incompatible architecture and fails.

Version-Release number of selected component (if applicable):
yum-4.7.0-2.el8

How reproducible:
always

Steps to Reproduce:
1. create a repository containing a package for multiple architectures, where at least one is not compatible with the running system, for example x86_64, i686 and aarch64
2. create a repo file for the new repository
3. echo multilib_policy=all >> /etc/yum.conf
4. yum install $multilib_package

Actual results:

# yum install zsh
Failed to set locale, defaulting to C.UTF-8
Updating Subscription Management repositories.
Unable to read consumer identity

This system is not registered with an entitlement server. You can use subscription-manager to register.

Last metadata expiration check: 0:08:51 ago on Thu Aug 19 09:53:59 2021.
Error: 
 Problem: conflicting requests
  - package zsh-5.5.1-8.el8.aarch64 does not have a compatible architecture
  - nothing provides libdl.so.2(GLIBC_2.17)(64bit) needed by zsh-5.5.1-8.el8.aarch64
  - nothing provides libm.so.6(GLIBC_2.17)(64bit) needed by zsh-5.5.1-8.el8.aarch64
  - nothing provides ld-linux-aarch64.so.1()(64bit) needed by zsh-5.5.1-8.el8.aarch64
  - nothing provides ld-linux-aarch64.so.1(GLIBC_2.17)(64bit) needed by zsh-5.5.1-8.el8.aarch64
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)
# uname -m
x86_64
#

Expected results:
As written in man yum.conf, only packages with compatible architectures are installed:

multilib_policy
Controls how multilib packages are treated during install operations. Can  either  be  "best"  (the
default)  for the depsolver to prefer packages which best match the system's architecture, or "all"
to install all available packages with compatible architectures.

Additional info:
The same problem exists on RHEL-9 with yum-4.7.0-2.el9
Comment 1 Jaroslav Mracek 2021-09-06 10:35:48 UTC 
Thank you very much for the report. There is not much what we can do. It is only possible to enhance documentation and remove `compatible architecture` from there.

It will be may be surprising, but the issue was resolved by distribution. Distributions split content according to base arch and compatibility (X86_64 can be together with i686) nad in the path to repository they uses BASEARCH variable.
Comment 2 Jaroslav Mracek 2021-09-06 10:44:39 UTC 
I created PR that improves documentation https://github.com/rpm-software-management/dnf/pull/1789.

AC: It is only the man page change therefore no tests are required.
Comment 5 Jiri Kortus 2021-10-15 14:18:58 UTC 
I wonder if there really isn't any solution to that problem? I hit the same issue when debugging why one of our tests (with inst.multilib) failed and found out that it happened because restraint-rhts package (available for all RHEL-9-supported architectures from internal beaker harness repo) hadn't been installed. The test actually uses our tool for automated testing of GUI installations (anabot), which performs the installation and when it's finished, it installs the restraint-rhts package and does all necessary setup steps for other beaker tasks to continue after reboot.

The issue is that the package from the aforementioned repo containing packages for all architectures can't be installed as yum just ignores it (error message from an x86_64 machine):
Error: 
 Problem 1: cannot install the best candidate for the job
  - package restraint-rhts-0.4.0-1.el9.aarch64 does not have a compatible architecture
  - nothing provides restraint(aarch-64) = 0.4.0-1.el9 needed by restraint-rhts-0.4.0-1.el9.aarch64
 Problem 2: cannot install the best candidate for the job
  - package restraint-rhts-0.4.0-1.el9.ppc64le does not have a compatible architecture
  - nothing provides restraint(ppc-64) = 0.4.0-1.el9 needed by restraint-rhts-0.4.0-1.el9.ppc64le
 Problem 3: cannot install the best candidate for the job
  - package restraint-rhts-0.4.0-1.el9.s390x does not have a compatible architecture
  - nothing provides restraint(s390-64) = 0.4.0-1.el9 needed by restraint-rhts-0.4.0-1.el9.s390x

When the architecture is specified, it works as expected though:
[root@localhost ~]# yum install restraint-rhts-0.4.0-1.el9.x86_64
Updating Subscription Management repositories.
Unable to read consumer identity

This system is not registered with an entitlement server. You can use subscription-manager to register.

Last metadata expiration check: 0:01:47 ago on Fri 15 Oct 2021 04:11:33 PM CEST.
Dependencies resolved.
======================================================================================================================
 Package                       Architecture          Version                      Repository                     Size
======================================================================================================================
Installing:
 restraint-rhts 
...

I still feel like this isn't a desired behaviour, despite the fact that the architectures for repositories are separated under normal circumstances. At least (as I'm not familiar with the yum/dnf internals) I don't understand why yum takes into account all of the other architectures first, but not the appropriate one. Jardo, could you please shed some more light on it? Thank you!
Comment 13 errata-xmlrpc 2022-05-17 15:55:05 UTC 
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 (new packages: dnf), 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-2022:3957
Comment 14 Jaroslav Mracek 2022-06-24 12:32:07 UTC 
(In reply to Jiri Kortus from comment #5)
> I wonder if there really isn't any solution to that problem? I hit the same
> issue when debugging why one of our tests (with inst.multilib) failed and
> found out that it happened because restraint-rhts package (available for all
> RHEL-9-supported architectures from internal beaker harness repo) hadn't
> been installed. The test actually uses our tool for automated testing of GUI
> installations (anabot), which performs the installation and when it's
> finished, it installs the restraint-rhts package and does all necessary
> setup steps for other beaker tasks to continue after reboot.
> 
> The issue is that the package from the aforementioned repo containing
> packages for all architectures can't be installed as yum just ignores it
> (error message from an x86_64 machine):
> Error: 
>  Problem 1: cannot install the best candidate for the job
>   - package restraint-rhts-0.4.0-1.el9.aarch64 does not have a compatible
> architecture
>   - nothing provides restraint(aarch-64) = 0.4.0-1.el9 needed by
> restraint-rhts-0.4.0-1.el9.aarch64
>  Problem 2: cannot install the best candidate for the job
>   - package restraint-rhts-0.4.0-1.el9.ppc64le does not have a compatible
> architecture
>   - nothing provides restraint(ppc-64) = 0.4.0-1.el9 needed by
> restraint-rhts-0.4.0-1.el9.ppc64le
>  Problem 3: cannot install the best candidate for the job
>   - package restraint-rhts-0.4.0-1.el9.s390x does not have a compatible
> architecture
>   - nothing provides restraint(s390-64) = 0.4.0-1.el9 needed by
> restraint-rhts-0.4.0-1.el9.s390x
> 
> When the architecture is specified, it works as expected though:
> [root@localhost ~]# yum install restraint-rhts-0.4.0-1.el9.x86_64
> Updating Subscription Management repositories.
> Unable to read consumer identity
> 
> This system is not registered with an entitlement server. You can use
> subscription-manager to register.
> 
> Last metadata expiration check: 0:01:47 ago on Fri 15 Oct 2021 04:11:33 PM
> CEST.
> Dependencies resolved.
> =============================================================================
> =========================================
>  Package                       Architecture          Version                
> Repository                     Size
> =============================================================================
> =========================================
> Installing:
>  restraint-rhts 
> ...
> 
> I still feel like this isn't a desired behaviour, despite the fact that the
> architectures for repositories are separated under normal circumstances. At
> least (as I'm not familiar with the yum/dnf internals) I don't understand
> why yum takes into account all of the other architectures first, but not the
> appropriate one. Jardo, could you please shed some more light on it? Thank
> you!

I think that the issue is partially created by repository that is usually not in standard distribution. Normal distribution does not contain incompatible architecture together. Then such a request is difficult to resolve correctly for DNF because we do not know what was intended behavior for the particular request. Please fix your repositories to prevent such an issue or use multilib_policy=best - then DNF will pick the best architecture for you automatically.
Note You need to log in before you can comment on or make changes to this bug.