Symptoms
You may run across this error when updating EasyApache 4 or the MultiPHP Manager. The "Error: Multilib version problems found. " will display in the interface.
Description
Attempting the 'Provision' a new EasyApache 4 Profile or changing the PHP version of a website, an error will appear after a certain amount of time.
Example error:
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
Reviewing the output file can point you to the RPM package that is having trouble.
Since both interfaces depend on 'yum' updating RPMs, an issue with updating can produce the error.
Below we have identified some examples and what you can do about them.
Workaround
Number 1:
cPanel/WHM uses Perl. Excluding Perl from the yum configuration can cause issues with yum updating.
Check with the following.
Command:
grep perl /etc/yum.conf
Example output:
# 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*
If perl* is present in the output, modify the "/etc/yum.conf" file. Please remove it from the line. Then, save the change, and re-run the update.
Command:
yum update
Done with the first one.
Number 2:
Sometimes, there will duplicate RPMs installed on the server. More than likely, this is because one is 32-bit while the second is 64-bit.
In this example, we will use 'libgcc'. * Please use caution when interacting with it. *
If you find 'libgcc' is causing the error, you may have two copies of the RPM on the server.
To locate a duplicate, use the following.
Command:
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
You should be safe to remove the i686 version of the RPM.
Command:
rpm -e --nodeps --justdb $RPM
The above command removes the reference in the RPM database and should allow 'yum' to continue updating.
Run the above command, and run the update again.
Command:
yum update
Done with the second one.
Number 3:
We find that using third-party YUM Repositories can cause RPM conflicts. This is due to the system attempting to update RPMs to different repositories version that is available.
The following list of yum repositories MAY be causing the issue.
$ 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
By searching for the package name, you can determine what repository 'yum' is trying to update.
Example Command:
yum -v search libgcrypt
The output shows packages and their related repositories.
Sample Output:
======================================== N/S matched: libgcrypt ========================================
libgcrypt.i686 : A general-purpose cryptography library
Repo : base
libgcrypt.x86_64 : A general-purpose cryptography library
Repo : @Base
If you find that 'yum' is attempting to update an RPM from a third-party repository, you would want to disable the repository.
To disable a yum repository, you can use the following steps. Move the yum.repo file to a different directory, redo the yum update:
Example (disable REMI repo):
mkdir /etc/yum.repos.disabled/
mv -v /etc/yum.repos.d/remi* /etc/yum.repos.disabled/
yum clean all
rpm --rebuilddb
yum update
Done with the third one.
Number 4:
Sometimes the dependencies for an RPM are not referencing the correct location. There is not an easy way to tell this.
You may wish to simply reinstall the RPM that is having trouble.
Example: libgcc
Command:
yum reinstall libgcc
If the issue is caused by a misplaced dependency, this should help. Once complete, do a 'yum update' to see if it can complete.
Command:
yum update
Done with the fourth one.