cPanel EasyApache 4 Build Failed? Here's How to Fix It

You added a PHP extension in WHM, or ran a routine EasyApache 4 rebuild after a cPanel update, and instead of the usual "Build Succeeded" screen you're staring at a wall of red text and a build that never finished. Apache is probably still running on the old binary, which is the only reason your sites are still up right now — but the next update, the next extension change, or a server reboot could leave you stuck. Here's how to actually read the failure and get the build green again.

Symptom: The Build Fails Partway Through

In WHM > EasyApache 4, you click "Provision" (or "Start Build" if you're already in the interface) and the progress bar stalls, then throws an error instead of finishing. Common ways it shows up:

• A yum/dnf transaction error mid-build, often mentioning a package "conflicts with" another or a "nothing provides" dependency message
• The build finishes the Apache portion but fails on a specific ea-php8x package or one PECL extension
• WHM shows "Build Failed" with a generic message and you have to dig into the actual log to find the real cause
• The build hangs for a long time and then times out

If you triggered this from the command line instead of the UI, you'll see the raw yum/dnf output directly, which is actually easier to work with.

Cause: Almost Always a Package Conflict, Not EasyApache Itself

EasyApache 4 (EA4) isn't a custom compiler the way EasyApache 3 was — it's a yum/dnf profile system. It picks a set of ea-* RPM packages (Apache, PHP versions, PHP extensions, Apache modules) and asks the system package manager to install them together. When the build fails, it's almost always yum/dnf refusing the transaction, for one of these reasons:

The single most common root cause on cPanel servers specifically is CloudLinux's alt-php conflicting with cPanel's own ea-php packages, or a manually pecl install'd extension sitting outside RPM's tracking and blocking a clean upgrade.

Fix: Read the Real Log First

Don't guess — the WHM UI often truncates the useful part. Pull the full build log from the server:

tail -n 200 /var/cpanel/logs/easyapache4_build.log

or, for the yum/dnf transaction itself:

tail -n 100 /var/log/yum.log
# or on AlmaLinux/Rocky (dnf-based)
tail -n 100 /var/log/dnf.log

Look for the first error, not the last — yum/dnf often cascades several follow-on failures after the real conflict.

Fix: Clear Stuck Transactions and Cache

If the build hung or was killed mid-way, finish or roll back the incomplete transaction before retrying:

# RPM-based, works on both yum and dnf systems
yum-complete-transaction --cleanup-only
# or, on newer AlmaLinux/Rocky
dnf history list
dnf history undo <last-failed-transaction-id>

Then clear the package manager cache, which resolves a surprising number of "nothing provides" errors caused by stale metadata:

yum clean all && yum makecache
# dnf
dnf clean all && dnf makecache

Fix: Check for Disk Space and Conflicting RPMs

EA4 downloads and unpacks RPMs under /usr, so a full root partition kills the build with a confusing error rather than an obvious "disk full" message:

df -h /usr /var /

If space is tight, clear old kernel packages and cached RPMs before retrying:

yum clean packages
package-cleanup --oldkernels --count=2   # keeps the current + 1 backup kernel

Next, check for packages that were installed outside cPanel's package manager and are now blocking the transaction:

rpm -qa | grep -E 'ea-php|ea-apache24|alt-php'
yum check

yum check lists broken dependencies across the whole system, which is usually where the actual conflicting package shows up by name.

Fix: Isolate the Bad Extension

If the build only fails when one specific extension is in the profile, don't fight it inline. In WHM > EasyApache 4 > Customize, remove that one extension, save, and rebuild without it. Once the base profile builds cleanly:

1. Add the extension back by itself and rebuild — this isolates whether it's the extension or something else in the mix
2. If it still fails, install its underlying system dependency manually (for php-imagick, that's usually ImageMagick-devel; for php-ldap, openldap-devel) then retry
3. If you're on CloudLinux, confirm you're not mixing alt-php (CloudLinux's own PHP stack) with the same PHP version managed under EA4 — pick one management layer per PHP version, not both

Fix: Rebuild From the Command Line

Once you've cleared the underlying issue, you don't need to go back through the WHM wizard. Trigger a rebuild directly:

/usr/local/cpanel/scripts/easyapache4 --build

This runs the exact same build EA4's UI would trigger, using your currently saved profile, and streams the real yum/dnf output to your terminal instead of a paginated web log — much faster for iterating when you're troubleshooting.

Prevention

• Never install PHP extensions with a bare pecl install on a cPanel server — use WHM's EA4 Customize screen or whmapi1 so the extension stays tracked as an RPM and survives future rebuilds
• Before any EA4 change, save your current profile (WHM > EasyApache 4 > the "gear" icon > Save Currently Installed Packages as a Profile) so you can restore it if a new build goes badly
• Run yum check as a monthly habit on busy production boxes — catching a broken dependency before you need to rebuild is a lot less stressful than during an incident
• If you're on CloudLinux, standardize on either alt-php or cPanel's ea-php per PHP version across the whole server, not a mix decided per-account
• Keep at least a few GB of headroom on /usr and /var; EA4 builds are one of the few maintenance tasks that silently fail rather than clearly reporting "disk full"

Frequently Asked Questions

Will a failed EasyApache 4 build take my site down?

Not immediately. EA4 builds a new configuration alongside the running one and only swaps it in on success, so a failed build leaves your existing Apache/PHP setup running untouched. The risk is leaving it unresolved — a future cPanel update or a reboot can expose the underlying package conflict at a worse time.

Can I roll back to my previous PHP or Apache version after a bad build?

Yes, if you saved a profile beforehand (WHM > EasyApache 4 > Save Currently Installed Packages as a Profile). Without a saved profile, you can still manually reinstall the previous ea-php package version with yum/dnf, though it's slower and easier to get wrong under pressure.

Why does the build only fail when I add one specific PHP extension?

Almost always a missing or mismatched system library that extension depends on — ImageMagick, LDAP, and GD-related extensions are the usual suspects. Removing the extension, confirming the base build succeeds, then re-adding it after installing its dependency is the fastest way to confirm this.

Do I need to restart Apache or PHP-FPM after a successful EA4 rebuild?

EA4 restarts the necessary services automatically as part of a successful build. You shouldn't need to restart anything manually unless you also changed PHP-FPM pool settings outside of EA4, in which case restart the specific pool.

Is it safe to run the EA4 rebuild directly from SSH instead of WHM?

/usr/local/cpanel/scripts/easyapache4 --build runs the same process WHM's UI triggers, just with unbuffered output in your terminal, which makes it easier to see exactly where a build fails. It's the same operation either way — the CLI is just a better troubleshooting view, not a different or riskier path.