cPanel upcp upgrade died mid-transaction: re-run with --force or restore the pre-upgrade snapshot?

Answer

If the latest updatelog shows the run stopped during the OS package transaction (e.g., "Starting yum transaction" or "Running package update") but there is no sign of rpmdb corruption, fix the yum/dnf issue first and then resume with /scripts/upcp --force. If the log or rpmdb indicates a lock or transaction‑check error, the safer path is to restore a snapshot taken before the upcp started.

Likely explanation

cPanel’s upcp script delegates OS package updates to yum/dnf. When that layer fails, upcp aborts while leaving its own internal state mostly intact. The updatelog records the exact stage reached; a failure before the final "upcp finished" message usually points to a yum/dnf problem rather than to cPanel‑specific corruption. Conversely, an rpmdb lock or explicit transaction‑check error signals that the package database itself is inconsistent, which a simple force‑re‑run cannot resolve.

Confirmed facts

1. cPanel does not support downgrading; there is no built‑in undo for a failed upcp.
2. /scripts/upcp --force is designed to resume a partial update after any stale lock is cleared and the underlying yum/dnf problem is fixed.
3. Restoring a snapshot is only valid if it predates the upgrade attempt; a mid‑upgrade snapshot can reintroduce half‑installed RPMs and cause dependency conflicts.

Steps to decide and recover

1. Identify the most recent log: ls -t /var/cpanel/updatelogs/ | head -1 and view its tail.
2. Look for the final completion string. If you see upcp finished the upgrade succeeded; otherwise note the last stage reported (e.g., "Starting yum transaction").
3. Check for rpmdb lock files: ls /var/cpanel/updatelogs/upcp.lock /var/lib/rpm/.rpm.lock 2>/dev/null. Any output means a lock exists.
4. Verify rpmdb consistency: rpm -Va | grep -E '^..5' or dnf repoquery --unsatisfied. No output indicates a clean database.
5. If the log stopped during a yum/dnf stage AND there are no lock files AND the rpmdb checks are clean:
   1. Resolve the yum/dnf issue (e.g., clear incomplete transactions with yum-complete-transaction or dnf history rollback, remove any stale /var/run/yum.pid).
   2. Ensure no upcp process is running: ps -fC upcp should return nothing.
   3. Run the forced update: /scripts/upcp --force.
6. If you find a lock file, see "Transaction check error" or similar in the log, or the rpmdb shows unsatisfied/broken packages:
   1. Do not run --force.
   2. Restore a snapshot taken before the upcp start (verify snapshot timestamp predates the log’s start time).
   3. After restore, confirm services are healthy and optionally run /scripts/upcp again to apply updates cleanly.
7. Post‑recovery validation (beyond version check):
   1. Run /scripts/check_cpanel_rpms – it should report "All cPanel RPMs are installed".
   2. Check core services: systemctl status cpanel httpd mysqld (or mariadb).
   3. Scan /var/log/cpanellog for recent errors.
   4. Optionally verify the update tier with /scripts/upcp --tier.

Missing diagnostic detail that could change the recommendation: Do you see any rpmdb lock file (/var/lib/rpm/.rpm.lock) or explicit transaction‑check errors in the latest updatelog?