yum fails with Error: Protected multilib versions: package.i686 != package.x86_64

Solution Verified - Updated -

Environment

  • Red Hat Enterprise Linux 6
  • Red Hat Enterprise Linux 7

Issue

  • Unable to install multilib package; Yum gives the error: Protected multilib versions: package-2.x86_64 != package-1.i686

Resolution

  • This occurs when yum is attempting to install different architectures, and different versions, of the same package.

  • Verify that the packages which you want to update are all available in the repository and at the same version

NOTE: Replace package with the name of the package you are experiencing the yum issue with

# yum list "package*" --showduplicates

  • If you find "package" has a higher version then a similar "package-*"

    • If using Satellite or a local repository, it may not be sync'd properly
    • You need to enable a repository which provides the update for installed packages
      - Identify what repository has the packages you need by searching the portal. Below are links for Red Hat Enterprise Linux Server x86_64
      - RHEL 7 Package Search
      - RHEL 6 Package Search
      - RHEL 5 Package Search
    • Your system may have pre-existing rpm database problems. Verify with:
    • If you install a package that is a different version, and architecture, then a package you already have installed.
      • # yum list package --showduplicates
      • Install the intended package at the version matching what you already have installed
      • Update the existing installed rpms before attempting to install the package
    • If you already have installed different versions of different architectures, this will show as a duplicate in yum check output, but it is a protected multilib caused by forcing a package installation or by disabling protected_multilib.
    • Verify that you are not excluding packages
      • # grep exclude /etc/yum.conf
    • If you are using the versionlock plugin, verify that the packages necessary to update are not being locked at a specific version
      • # yum versionlock list
    • When registered with Red Hat Subscription Manager, if the system is locked to a minor release, that may be causing the issue
      • # subscription-manager release
  • If the error is from yum installing a .i686 version that was not present before the update, ensure that all variants of that package (package-devel, package-static, package-libs, package-*) are being updated. Generally these versions all must match.
    • If package is updated, but package-devel is not, yum may pull in package.i686 as a dependency which creates the multilib error. The resolution is to update the -devel package
  • If you are still encountering a multilib error, please open a case with Red Hat Support

Root Cause

  • Multilib means support for multiple architectures
  • This issue arises when .x86_64 and .i686 packages are not the same version
  • If both the 64 bit and the 32 bit version of a package are available in the repository, they must be the same version.

Diagnostic Steps

  • Verify your yum cache is up to date with the repo

    • # yum clean all

    • List out all the packages and check to see if everything is available that you need available

    • # yum list all --showduplicates
    • # yum list <package> --showduplicates

  • Verify there are no excludes or version locks applied to your system

    • # grep exclude /etc/yum.conf
    • # yum versionlock list
    • # subscription-manager release

  • Check for pre-existing problems in the rpm database

    • # yum check
    • # package-cleanup --dupes
    • # package-cleanup --problems

  • Rebuild the database with
    rpm --rebuilddb

Removing the Conflicting Packages

  • If only after you have run the yum clean commands and rebuilt the database and you are still receiving the issue, then the only other option is to remove the package forcefully. But please note: If the package has many core dependencies and its removed, then this could break the server and it would be very difficult to recover from. Therefore this option is not recommended, in this case seek Red Hat support
    For non production servers, use this option at your own risk.

*Prerequisite: Ensure you have a dvd copy of the current version you are running.
How to create a dvd yum repository

Example of a real multilib issue:

$ yum update
Protected multilib versions: iptables-1.4.21-28.el7.x86_64 != iptables-1.4.21-24.1.el7_5.i686
Error: Protected multilib versions: 14:libpcap-1.5.3-11.el7.x86_64 != 14:libpcap-1.5.3-9.el7.i686

$ yum remove libpcap 
This removed 40 packages that werent core to the server such as libvirt.

`$ yum remove iptables`, would remove too many core applications and services.
So to rectify this, we need to remove it without its dependencies.

First we list the packages. In this case, there was no packages with i686.
rpm -qa | egrep iptables
iptables-services-*
iptables-utils-*

Then we remove these packages without their dependencies and we have an understanding that these packages will not interfere with the rpm database, core applications like glibc, the network or yum.  

 rpm -e --justdb --nodeps iptables
 rpm -e --justdb --nodeps iptables-services
 rpm -e --justdb --nodeps iptables-utils

Then you should be able to run the command
$ yum update

The final test is 
$ reboot
  • Component
  • yum

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.

6 Comments

Log in to comment
AR Newbie 7 points
12 June 2017 3:17 PM

Do you have any update as to when this issue is likely to be resolved. I am experiencing this issue on my system. Thanks.

Roeland Jansen's picture Community Member 74 points
14 December 2018 1:35 PM

maybe sending in the githib repos of zypper and it's friends. that would make yum a lot faster as well.

LT Community Member 20 points
11 November 2022 1:56 AM

suggest how to fix this error:

Protected multilib versions: libgcc-4.8.5-44.el7.x86_64 != libgcc-4.8.5-36.el7.i686

rpm -qa --last | grep -i libgcc libgcc-4.8.5-36.el7.i686 Mon 23 Mar 2020 12:26:20 AM +08 libgcc-4.8.5-36.el7.x86_64 Mon 23 Mar 2020 12:26:15 AM +08

JC Red Hat Expert 984 points
11 November 2022 12:29 PM

If you open a case with a sosreport, and the full yum output, I can assist better. Looking at the error, something could require libgcc-4.8.5-36.i686 preventing it from updating or you could be excluding or version locking the libgcc package preventing you from seeing the update.

AD Community Member 52 points
16 April 2023 10:08 PM

I am happy to say most of these fixes are applicable to RHEL8, and the "gist" of this article is true for RHEL8 though not yet mentioned. (and I'd bet endures in rhel9).
Also it should be stated that there is some very nice maturity here with the package-management tools. Yum (actually now a shortcut to dnf) can be considered a mature, stable, enterprise-grade python app for package management.
The letters "dnf" should be your anagram for "Do Not Fudge with..." with the yum dependency tree. You will have a long and happy existence if you always defer to what yum's dependency instincts, and never give in to the temptation to override it's preferences with "--skip broken": (No no nay nay to "--skip broken"! Only use that option if you completely understand the ramifications, or if you are willing to accept that update as possibly your last.) Also, do not be confused by the 30% (or more) functional overlap between yum and rpm commands. "rpm" does a lot of things that you can do with "yum/dnf". So do not be confused by that. However, it's always best to do your work thru yum, if you desire a long an happy co-existence with it. Thanks for this good article. That all said, if you should have duplicates of vital packages, they can be comprehensively identified, and they can be safely removed, following the instructions here. I just now removed 136 dupes, many of which were "vital". That is a scary thing to do. In this case, I think they were installed all at the same time, and they were all "lower version" dupes at the time they got installed, so there was no complex interactions with dependencies.

Roeland Jansen's picture Community Member 74 points
18 April 2023 6:35 AM

Alex,

I'm sorry to say to you that most people think that yum, dnf should prevent this from happening to start with. So whatever halelujah stories you tell about yum, dnf -- I can assure you that there are more mature solutions that actually don't get you in the trouble you see here.

If you don't break things, there is no need to fix. And we all know that RH breaks things (evenwhile knowing, I can tell you) and they do their best to have you sign up and pay for their own problems.

Did I mention Satellite yet, by the way? Urrgghh.