Most often, we run across the Multilib version problems found error when we update EasyApache 4 or the MultiPHP Manager.

It will display in the interface.

Here, at Bobcares, we assist several of our customers with this error as part of our Server Management Services.

Today, let us see how our techs fix this issue with different examples.

Multilib version problems found

If we attempt the ‘Provision’ a new EasyApache 4 Profile or change the PHP version of a website, it will eventually lead to an error.

Most often, the error will look like the following:

Error: Multilib version problems found. This often means that the root
The entire output was logged to: /usr/local/cpanel/logs/packman/errors/2019-08-12_09:44:05-1

If we review the output file, it will point us to the RPM package that is having trouble.

Since both interfaces depend on ‘yum’ updating RPMs, any update issue can produce an error.

Moving ahead, our Support Techs shows few examples and what we can do about them.

• Number 1:

Our first case is when cPanel/WHM uses Perl. Excluding Perl from the yum configuration can cause issues with yum updating.

In order to diagnose we check with the following:

grep perl /etc/yum.conf

Our output will be similar to this:

# grep perl /etc/yum.conf

exclude=bind-chroot courier* dovecot* exim* filesystem httpd* mod_ssl* mydns* nsd* p0f perl* php* proftpd* pure-ftpd* spamassassin* squirrelmail*

In case Perl is in the output, we modify the “/etc/yum.conf” file and remove it from the line.

Then, we save the change and re-run the update:

yum update

• Number 2:

Sometimes, there is a possibility for duplicate RPMs on the server.

Here, we use ‘libgcc’. If it causes the error, we may have two copies of the RPM on the server.

To locate a duplicate, we run:

rpm -qa –queryformat “%{NAME}-%{VERSION}-%{ARCH} \\n” | grep libgcc | sort

Output:

libgcc-4.8.5-39.el7.x86_64 <– x86_64 is 64-bit version
libgcc-4.8.5-39.el7.i686 <– i686 is 32-bit version

However, be careful while removing the i686 version of the RPM.

rpm -e –nodeps –justdb $RPM

This removes the reference in the RPM database and allows ‘yum’ to continue updating.

After we run the above command we run the update again:

yum update

• Number 3:

Another possible cause can be third-party YUM Repositories.

It can happen because the system attempts to update RPMs to different repositories version that is available.

A list of yum repositories may cause the issue. They include:

$ ls -lahtr /etc/yum.repos.d/
total 104K
-rw-r–r– 1 root root 2.3K Jun 1 2020 remi.repo
-rw-r–r– 1 root root 206 Jun 1 2020 elasticsearch.repo
-rw-r–r– 1 root root 193 Jun 1 2020 ndeploy.repo
-rw-r–r– 1 root root 1.1K Jun 1 2020 city-fan.org.repo

If we search for the package name, we can determine what repository ‘yum’ is trying to update.

yum -v search libgcrypt

Here, the output will show packages and their repositories.

======================================== N/S matched: libgcrypt ========================================
libgcrypt.i686 : A general-purpose cryptography library
Repo : base
libgcrypt.x86_64 : A general-purpose cryptography library
Repo : @Base

If yum is attempting to update an RPM from a third-party repository, we have to disable the repository.

To do so, our Support Techs recommend to move the yum.repo file to a different directory, and redo the yum update:

For example, to disable REMI repo, we do the following:

mkdir /etc/yum.repos.disabled/
mv -v /etc/yum.repos.d/remi* /etc/yum.repos.disabled/
yum clean all
rpm –rebuilddb
yum update

• Number 4:

At times, the dependencies for an RPM will not refer the correct location.

In this scenario, we just have to reinstall the RPM that is having trouble.

yum reinstall libgcc

This helps if the issue is due to a misplaced dependency.

Once complete, we perform a ‘yum update’ to see if it can complete.

yum update

[Stuck in between? We can help you out]

Conclusion

In short, we saw how our Support Techs fix the Multilib version issue for our customers.