Multilib version problems on CentOs 7

Question

When I try to update YUM with sudo yum update --exclude=kernel*,python* --skip-broken, I get Multilib version problems found. Protected multilib-versions:

systemd-libs-219-30.el7_3.7.x86_64!=systemd-libs-219-30.el7_3.6.i686.

How can I solve this? I have CentOS 7.3, and my architecture is x86_64.

Fout:  Multilib version problems found. This often means that the root
      cause is something else and multilib version checking is just
      pointing out that there is a problem. Eg.:

        1. You have an upgrade for systemd-libs which is missing some
           dependency that another package requires. Yum is trying to
           solve this by installing an older version of systemd-libs of the
           different architecture. If you exclude the bad architecture
           yum will tell you what the root cause is (which package
           requires what). You can try redoing the upgrade with
           --exclude systemd-libs.otherarch ... this should give you an error
           message showing the root cause of the problem.

        2. You have multiple architectures of systemd-libs installed, but
           yum can only see an upgrade for one of those architectures.
           If you don't want/need both architectures anymore then you
           can remove the one with the missing update and everything
           will work.

        3. You have duplicate versions of systemd-libs installed already.
           You can use "yum check" to get yum show these errors.

      ...you can also use --setopt=protected_multilib=false to remove
      this checking, however this is almost never the correct thing to
      do as something else is very likely to go wrong (often causing
      much more problems).

      Beschermde multilib-versies: systemd-libs-219-30.el7_3.7.x86_64!=systemd-libs-219-30.el7_3.6.i686

Answer 1

Yum is complaining that the 64-bit and 32-bit versions of the RPM for systemd-libs in your system do not match.

You'll see that it has version 219-30.el7_3.7 for x86_64 (64-bit) and version 219-30.el7_3.6 for i686 (32-bit).

You can check the version of the package for each architecture in your system with this command:

$ rpm -q systemd-libs
systemd-libs-219-30.el7_3.6.i686
systemd-libs-219-30.el7_3.7.x86_64

See if you see some anomaly there, such as having two versions of systemd-libs for i686...

If the versions match, then the problem might be that yum is trying to upgrade the x86_64 version, but leaving the i686 version behind.

It's possible that your --skip-broken is triggering this somehow, if the i686 version of the package is somehow "broken" to yum...

It's also possible that your system was reconfigured to only consider 64-bit packages and no longer try to install (or maintain) 32-bit ones...

You can try some utilities from the yum-utils package to troubleshoot this.

Can you install it?

$ sudo yum install yum-utils

If you do, try this command to complete yum transactions that were interrupted (which might have caused the issue in the first place):

$ sudo yum-complete-transaction

You can also use the package-cleanup command. For instance, if it seems you have duplicate packages (multiple versions installed for the 32-bit one), try this:

$ sudo package-cleanup --cleandupes

I hope this helps!

Answer 2

Problems like this usually appear when you have two different versions of one package installed on your system.

Answer 3

yum list installed | grep systemd-libs
yum update systemd-libs.i686
yum reinstall systemd-libs.x86_64

and then reboot system

Answer 4

I had similar issue and solved it by deleting duplicate versions of several packages:

package-cleanup --dupes

Then delete all newer versions from rdmdb

rpm -e --justdb --nodeps <package-version>

Then yum upgrade works again and installs all pending upgrades.

Answer 5

I had the exact same problem. Centos 7, latest release installed with both Epel and Remi repos installed. And then I tried to upgrade as I always do by going into : /etc/yum.repos.d and on the epel.repo file one finds under [epel]:

enabled=1

the line

enabled=1

must be set to 1

On the other file :

remi.repo

the Exact same line must be set to 0.

In this manner we are choosing to go for updates on the epel repo and Not the remi repo to avoid conflicts on the PHP versions.

So with the epel repo enabled and the remi repo disabled the error came out. I ran the command :

yum --skip-broken update

Notice that I need to use the --skip-broken to avoid the errors on the PHP updates since they are newer version installed from remi.

Has I do not have two systemd-libs installed, only one the x86_64, I thought this was a repo dependency problem.

So instead of First using the update with the Epel repo I made this time First the update with the remi repo. All went well ... no errors, the update took care of kernel and other updates from Centos update repo as usual and the remi took care of the PHP stuff. After that I disabled the remi repo:

• making enabled=0 on the remi.repo file.

And then enabled the epel repo:

• making enabled=1 on the epel.repo file.

Then I simply made yum update since all the php would not show any more conflicts, no more need for the --skip-broken parameter...

And it worked !

In the end I usualy disable the remi and enable the epel once again for the next time. Hope this helps.

Answer 6

Try first:

yum install systemd-libs

and then

yum update --exclude=kernel*,python* --skip-broken