Fixing the “cannot install both ea-profiles-cpanel” Conflict on CloudLinux 8 / WHM

If you manage a cPanel/WHM server running CloudLinux 8, you may have run into this error while trying to run a routine yum update:

Problem: cannot install both ea-profiles-cpanel-4:1.0-53.el8.cloudlinux.1.x86_64 from cloudlinux8 and ea-profiles-cpanel-5:1.0-73.79.1.cpanel.x86_64 from @System
  - cannot install the best update candidate for package ea-profiles-cpanel-5:1.0-73.79.1.cpanel.x86_64
  - cannot install the best update candidate for package ea-profiles-cloudlinux-4:1.0-75.el8.cloudlinux.1.x86_64
(try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)

This is a known, recurring issue affecting CloudLinux 8 servers, and it’s worth understanding exactly why it happens before reaching for a fix — because the obvious-looking solutions only patch the symptom, not the cause.

What’s Actually Going On

Two different vendors both ship a package called ea-profiles-cpanel, and they aren’t meant to compete:

• cPanel manages its own version internally, tagged with epoch 5 (e.g. ea-profiles-cpanel-5:1.0-73.79.1.cpanel). This is the version your server is actually supposed to run.
• CloudLinux’s repositories also carry a build of the same package name, tagged with epoch 4 (e.g. ea-profiles-cpanel-4:1.0-53.el8.cloudlinux.1), bundled alongside a related package called ea-profiles-cloudlinux.

In RPM package resolution, epoch always wins — epoch 5 is considered “newer” than epoch 4 regardless of the version numbers that follow. So cPanel’s package is correctly treated as authoritative. The problem is that CloudLinux’s repo keeps offering its epoch-4 build as an “update,” and yum can’t reconcile the two — hence the cannot install both error, and the update grinding to a halt.

This isn’t a broken server. It’s two package sources quietly fighting over ownership of the same file, and yum refusing to guess who should win.

Why the Obvious Fixes Don’t Fully Work

Adding --allowerasing or --nobest to yum update, as the error message suggests, can get you past the error for one run — but it doesn’t resolve the underlying conflict. CloudLinux’s repo will offer the same package again on the next update, and you’ll be right back where you started. Some attempts to force a yum update even trigger a broken %posttrans scriptlet during the CloudLinux package’s install/obsolete process (a Lua error: attempt to call a nil value), which is a packaging bug in the profile-writing step — non-fatal, but confusing if you don’t know what it means.

The Real Fix: Stop the Conflict at the Source

The durable solution is to tell CloudLinux’s repository to stop offering these two packages entirely, since cPanel already owns and manages them.

Step 1 — Identify the correct repo section

The repo ID shown in the error (cloudlinux8) is a shorthand for the section defined in /etc/yum.repos.d/cloudlinux.repo:

[cloudlinux-$basearch-server-$releasever]

Confirm this on your own server with:

grep -H "^\[" /etc/yum.repos.d/cloudlinux*.repo

Step 2 — Exclude the conflicting packages from that repo

Edit /etc/yum.repos.d/cloudlinux.repo and add an exclude= line inside the [cloudlinux-$basearch-server-$releasever] block:

[cloudlinux-$basearch-server-$releasever]
name=CloudLinux $releasever - Updates
mirrorlist=https://repo.cloudlinux.com/cloudlinux/mirrorlists/cl-mirrors/cloudlinux-$basearch-server-$releasever
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CloudLinux
exclude=ea-profiles-cpanel ea-profiles-cloudlinux

⚠️ Important: the exclude= line must go inside the correct [section] block, not appended blindly to the end of the file. Doing it wrong (e.g. with a careless echo ... >> file) can corrupt the file’s syntax and cause yum to skip the entire repo — blocking every package it provides, not just the two you meant to exclude. Always verify the file structure with cat -n or sed -n before and after editing.

Step 3 — Refresh and update

yum clean metadata
yum update --best --allowerasing -y

With the exclude in place, CloudLinux’s repo no longer proposes its ea-profiles-cpanel/ea-profiles-cloudlinux packages as update candidates. cPanel’s own epoch-5 package stays exactly where it should, and yum update completes cleanly with no conflict.

Step 4 — Verify

rpm -q ea-profiles-cpanel
whmapi1 ea4_get_currently_installed_packages

You should see cPanel’s package version intact, and a normal, complete list of your EasyApache 4 packages (Apache, PHP handlers, modules, etc.) confirming your server’s actual configuration is untouched.

A Note on the “Missing” Vendor Profile File

If you check /etc/cpanel/ea4/profiles/vendor/, you may find it empty. This is a leftover from the earlier failed scriptlet attempts and is purely cosmetic — it only affects WHM’s optional “restore to vendor default profile” feature. It has no effect on your live Apache/PHP configuration, which cPanel tracks independently via RPM state. If you want it regenerated, WHM → EasyApache 4 → Manage → Save your current setup as a profile will recreate an equivalent file.

Summary

Once the exclude is in place, yum update runs cleanly going forward, and there’s nothing further to do unless CloudLinux and cPanel formally reconcile package ownership in a future release — at which point you can simply remove the exclude= line.

Got stuck mid-update on your own server? PrenHost’s support team can walk through repo configuration, EasyApache 4 recovery, and general CloudLinux/cPanel maintenance — reach out any time.