# cPanel upcp Failed: Fix Upgrade Blocked Problems Source: https://srvscripts.com/guides/cpanel-upcp-failed-upgrade-blocked/ Updated: 2026-10-03 Publisher: srvScripts (https://srvscripts.com/) A cPanel server that has stopped updating is a server that is missing the 2026 root-escalation fixes, so an `upcp` failure is a security incident in waiting, not a cosmetic issue. The update script is verbose about why it stopped, but the reason is buried in a long log, and several of the 2026 causes are policy decisions (dropped operating systems, tier retirements) rather than bugs. This guide covers how to find the reason and what to do for each. In short: Run /scripts/upcp –force and read the first [FATAL] or blocker line in /var/cpanel/updatelogs/last; that line names the cause. **Short answer:** Run `/scripts/upcp --force` and read the first `[FATAL]` or blocker line in `/var/cpanel/updatelogs/last`; that line names the cause. An unsupported operating system such as Rocky Linux or Ubuntu 22.04 needs a migration, not a setting; a tier blocker is fixed by moving one tier at a time with `whmapi1 set_tier`; package errors are cleared with `dnf clean all`, disabling foreign repositories and `/scripts/check_cpanel_pkgs --fix`; and a corrupt tree is repaired with `/scripts/upcp --sync`. ## Find the failure in the log Run the update in the foreground so you see it live, then inspect the log: ``` /scripts/upcp --force less /var/cpanel/updatelogs/last grep -iE 'fatal|error|blocker|blocked' /var/cpanel/updatelogs/last | head -40 ``` The first `[FATAL]` or `blocker` line is the cause. Everything after it is fallout. Also check **WHM » Server Configuration » Update Preferences** for the tier and **WHM » cPanel » Upgrade to Latest Version**, which shows blockers in the interface with a short explanation. Confirm what you are on and what you are trying to reach: ``` whmapi1 version cat /etc/cpupdate.conf cat /etc/redhat-release 2>/dev/null || lsb_release -d ``` ## Unsupported operating system This is the most common 2026 cause and there is no configuration fix; it needs a migration plan. - **Rocky Linux 8 and 9**: support ended with version 134. A Rocky server stays on 133 and receives no further updates, including security builds. The supported route is the in-place conversion to AlmaLinux using the deployment script, covered in [migrating Rocky to AlmaLinux](/guides/rocky-linux-cpanel-to-almalinux/). - **Ubuntu 22.04**: last supported in 136. Version 138 requires 24.04. Move to 24.04 with `do-release-upgrade` following the cPanel-specific steps, or rebuild. - **CentOS 7, CloudLinux 7, AlmaLinux 8 below the required minor**: the 110 tier is the last for EL7 and reaches end of life in December 2026. RHEL 9-family systems must be at 9.5 or later since 132. - **AlmaLinux 8 or 9 wanting AlmaLinux 10 features**: use ELevate, covered in [our ELevate guide](/guides/cpanel-elevate-almalinux-8-9-10/). The log message in these cases mentions the OS name and says the target version does not support it. Do not try to edit `/etc/redhat-release` or fake the version; the update will half-apply and leave a broken server. ## Tier blockers Moving between tiers has rules. You cannot skip from 110 to 138 in one hop, and you cannot go backwards. If `/etc/cpupdate.conf` says `CPANEL=release` but the server is on 110, the update logic first evaluates whether 134 is reachable on this OS before allowing 138. Set the tier explicitly and run upcp once per hop: ``` whmapi1 set_tier tier=134 /scripts/upcp --force whmapi1 set_tier tier=release /scripts/upcp --force ``` A blocker also appears if a feature the target version removed is in use. Version 136 removed Ruby on Rails and RubyGems support; if a server still has the ea-ruby packages installed and applications registered, the upgrade refuses until they are removed. The blocker text names the feature. Remove the packages and any app registrations with `/scripts/ea_ruby_migrate` or by uninstalling them from EasyApache 4, then retry. ## Package and repository failures When the log shows `dnf` or `yum` errors, the OS package layer is the problem rather than cPanel: ``` dnf clean all dnf makecache dnf check rpm -Va --nofiles --nodigest 2>&1 | grep -v '^\.\.\.' | head ``` Typical findings are a third-party repository (Remi, a stale CloudLinux mirror, an old MariaDB repo) with a broken metadata URL, a partial transaction left by a crash (`dnf history` and `dnf history redo` help), or a package conflict between an EA4 PHP and a Remi PHP. Disable the offending repository and rerun `upcp`. If `cpanel-` packages themselves show as modified in `rpm -V`, run: ``` /scripts/check_cpanel_pkgs --fix ``` It reinstalls anything cPanel considers corrupt from its own mirror. ## Disk, clock and package repair `upcp` needs a few gigabytes free on `/usr` and `/var` and enough RAM to run the perl installer. Check `df -h /usr /var /tmp` and `free -m`. The other silent killer is the system clock: a drift of more than a few minutes causes TLS failures against the update mirrors that look like connectivity errors. `chronyc tracking` should show a small offset; fix with `chronyc makestep`. Also confirm that outbound HTTPS to `httpupdate.cpanel.net` is open in CSF’s `TCP_OUT`. When the log is a mess of partially applied files, cPanel provides a resync that compares every installed file with the mirror and replaces differences: ``` /scripts/upcp --sync ``` If even that fails because the local cPanel perl or the update script itself is broken, the recovery path is the installer in update mode, which reinstalls the cPanel tree without touching accounts: ``` cd /home && curl -o latest -L https://securedownloads.cpanel.net/latest && sh latest --force ``` Take a full backup first; our [backup-verify script](/scripts/backup-verify/) confirms the archives are usable before you rely on them. ## A common pitfall: disabled auto-updates Many servers that “cannot update” simply have updates turned off in **Update Preferences** from a migration years ago, and then hit multiple blockers at once because they are far behind. Set the daily updates back on: ``` whmapi1 set_cpanel_updates updates=daily grep -E 'UPDATES|RPMUP' /etc/cpupdate.conf ``` `UPDATES=daily` and `RPMUP=daily` are what you want. Manual-only updates mean you are the security team, and 2026 has shown the vendor patches faster than most teams can schedule. ## Verify After a successful run, `whmapi1 version` reports the target build, `/var/cpanel/updatelogs/last` ends with a completion line and no `[FATAL]`, and the version banner in WHM matches. Check that all services restarted cleanly with `/scripts/restartsrv_cpsrvd --check` and `systemctl --failed`. Then compare the build against the [CVE-to-build mapping](/guides/cpanel-cve-build-numbers-2026/) to confirm you are past the September bulletins. Add a weekly check of `/var/cpanel/updatelogs/last` to your monitoring so the next failure surfaces within days, not months. ## CPanel upcp failed at a glance **Official documentation:** [cPanel & WHM documentation](https://docs.cpanel.net/), [Linux man pages](https://man7.org/linux/man-pages/). **Related guides:** [What changed in cPanel 138: Meridian, Ask AI, Nova, MCP and domain rename](https://srvscripts.com/guides/what-changed-in-cpanel-138/) · [Install ImageMagick and PHP Imagick for EA-PHP on AlmaLinux 8/9/10 (and CloudLinux CageFS)](https://srvscripts.com/guides/install-imagick-ea-php-almalinux/) · [Managing web log retention and Apache log cleanup on cPanel (v136+)](https://srvscripts.com/guides/cpanel-apache-log-retention/). ## Frequently asked questions ### Does a failed upcp run break the server or its accounts? Usually not. `upcp` checks blockers before it changes files, and a failure at the blocker stage leaves the server exactly as it was. A failure mid-way through the file sync is rarer and is what `/scripts/upcp --sync` exists to repair. ### How long does /scripts/upcp –force take? A routine update finishes in ten to thirty minutes depending on how many builds behind the server is and the speed of the mirror. A multi-tier catch-up runs once per hop, and `--sync` or the installer in update mode can take an hour. ### Can I skip cPanel versions, for example from 110 straight to 138? No. Tier moves are one hop at a time and only forwards, and each target must support the operating system. Set the tier to the next LTS, run `upcp`, then set the next tier and repeat.