Cannot upgrade until needed system packages are installed.

Symptoms

When running /scripts/upcp (or when the automatic nightly cPanel update runs) on a server whose underlying OS version differs from what cPanel last recorded — for example, after an Ubuntu point−release, an AlmaLinux ELevate migration, or any other major OS upgrade — the upgrade aborts with a blocker error similar to the following:

CONFIG_TEXT: E Blocker found: Cannot upgrade until needed system packages are installed (no missing packages reported).

Earlier or version−specific variants of the same blocker include:

CONFIG_TEXT: The install encountered a fatal error: Cannot upgrade to "cPanel Version from updatenow.sync file" until needed system packages are installed.

Despite the message claiming that system packages must be installed, no actual missing package is listed. The upgrade exits without making changes, and subsequent runs of upcp reproduce the same blocker. WHM → Upgrade to Latest Version fails in the same way.

Cause

cPanel's upgrade process performs a preflight check that compares the running OS / package state against the metadata cPanel has cached locally about “needed system packages” for the target version. When the OS has changed underneath cPanel — typically after an OS upgrade, a distribution migration (ELevate), or a kernel/userland mismatch — that cached metadata becomes stale and the check fails open: it knows the state is invalid but cannot enumerate any specific package to install, hence the “no missing packages reported” wording.

Common underlying triggers observed on tickets:

• Stale or corrupted cPanel update staging files in /usr/local/cpanel/tmp/ after a partial/interrupted upgrade.
• Missing or misconfigured distribution repository file (e.g. /etc/yum.repos.d/almalinux.repo absent after ELevate, or /etc/apt/sources.list.d/ entries pointing at a different Ubuntu release than the one actually running).
• OS version recorded by cPanel no longer matching /etc/os-release, so the package solver cannot reconcile the two.

This is not Ubuntu−specific — the same blocker is reproduced on AlmaLinux, Rocky, and CloudLinux servers whenever there is a delta between what cPanel expects and what the OS reports.

Resolution

Re−sync cPanel's update tree against the current OS state, then re−run the upgrade. The following has resolved the blocker on every reported ticket:

1. Log in to the server via SSH or WHM's Terminal as the root user

2. Force a full sync of the cPanel update sources so the package metadata is rebuilt against the current OS:

   # /scripts/updatenow.static --sync

3. Re−run the cPanel upgrade:

   # /scripts/upcp --force

4. If the blocker persists, verify the OS package repositories are present and correct for the running distribution before retrying step 1:

   RHEL−family (AlmaLinux / Rocky / CloudLinux)

   Confirm /etc/yum.repos.d/almalinux.repo (or the equivalent vendor repo) exists and is enabled. Restore it from the vendor's *-release package if missing.

   Ubuntu

   Confirm /etc/apt/sources.list and files under /etc/apt/sources.list.d/ reference the actual running release (lsb_release -rs) and run apt-get update successfully.

    

5. Confirm that /etc/os-release matches the OS cPanel believes is installed (visible in WHM → Server Information). A mismatch here means the previous OS upgrade did not complete cleanly and must be resolved before upcp can succeed.

After updatenow.static --sync rebuilds the local view of required packages, the “no missing packages reported” blocker clears, and upcp proceeds normally.