How to Fix cPanel Installation Error on Ubuntu 24.04 – Complete Troubleshooting Guide

So here’s the deal. It’s 1 AM, you’ve just provisioned a shiny new VPS, and you’re ready to deploy cPanel. The install crawls along for about an hour, and then bam – a wall of red text: The background process ‘SQL Databases and dependent apps’ failed with a fatal error: The subprocess reported error number 2 when it ended. At that hour, with a deadline breathing down your neck, the temptation to throw the laptop across the room is very real. Trust me, I’ve been there, and this is how to fix a cPanel installation error on Ubuntu 24.04 without losing your mind.

Let me frame this in plain terms before we get technical. Installing cPanel is a lot like baking a cake. You can be the best baker in the world, but if the flour you grabbed from the pantry is stale, the cake flops every single time. Here, the ‘flour’ is the APT repository your server pulls packages from. If that repository is broken, half-synced, or incomplete, nothing downstream is going to work, and the installer will die right in the middle of the SQL stage every single time.

The pain here isn’t just the scary error message. It’s the wasted hours, the half-configured system you’re left with, and the awkward phone call to your client or manager explaining that no, the server is still not ready. The most common triggers are: a local APT mirror that isn’t synced or is missing packages, leftover MySQL/MariaDB packages from a previous attempt fighting with the new install, a hostname that isn’t a proper FQDN yet, and simply not enough RAM or free disk. But the number one culprit – the one I see over and over in tickets – is the repository mirror.

Let’s peel back the layers a little. That ‘subprocess reported error number 2’ is only the surface story. The number 2 is an exit code from dpkg, the package manager that works underneath apt. dpkg isn’t failing because your server is broken; it’s failing because apt tried to pull MariaDB from a mirror that either doesn’t have the packages, has stale index files, or is returning 404s on fetch. Imagine walking into your favorite grocery store and finding half the shelves empty. You can’t cook a proper meal with half the ingredients, and dpkg certainly can’t configure a database server when its dependencies are missing.

What makes this case extra sneaky is that the error shows up late, not early. cPanel runs its installation through a set of background processes. The one called ‘SQL Databases and dependent apps’ handles MySQL/MariaDB, and the moment dpkg gives up, that process collapses and takes the whole installer down with it. The final blow is always the same: ‘The system failed to run the /usr/local/cpanel/scripts/cpanel_initial_install script’. This isn’t a cPanel bug – it’s an unhealthy environment. And the good news? You can fix it entirely from your side. That’s exactly what I’ll walk you through, step by step.

Symptoms and Error Messages You’ll See

Before we fix anything, let’s get familiar with the enemy. There are three layers of errors here, and they all connect:

1. Primary error: The background process ‘SQL Databases and dependent apps’ failed with a fatal error: The subprocess reported error number 2 when it ended
2. Final error: The system failed to run the /usr/local/cpanel/scripts/cpanel_initial_install script
3. The hidden error: The actual dpkg/apt failure that only shows up once you open the detailed install log

Error number three is the one that matters. Here’s a real sample of what you’ll find if you open the cPanel installation log:

[2026-07-15 03:12:41] Installation step 4 of 18: SQL Databases and dependent apps
[2026-07-15 03:12:41] Running: apt-get install -y mariadb-server mariadb-client
[2026-07-15 03:12:44] E: Unable to locate package mariadb-server
[2026-07-15 03:12:44] E: Package 'mariadb-server' has no installation candidate
[2026-07-15 03:12:45] W: Failed to fetch http://mirror.local.example/ubuntu/dists/noble-updates/main/binary-amd64/Packages.gz 404 Not Found
[2026-07-15 03:12:45] E: Sub-process /usr/bin/dpkg returned an error code (2)
[2026-07-15 03:12:45] E: Unable to correct problems, you have held broken packages.
[2026-07-15 03:12:46] dpkg: error processing package mariadb-server-10.11 (--configure):
[2026-07-15 03:12:46]  installed mariadb-server-10.11 package post-installation script subprocess returned error exit status 2
[2026-07-15 03:12:47] dpkg: dependency problems prevent configuration of mariadb-server:
[2026-07-15 03:12:47]  mariadb-server depends on mariadb-server-core-10.11; however:
[2026-07-15 03:12:47]   Package mariadb-server-core-10.11 is not installed.
[2026-07-15 03:12:48] FATAL: The background process 'SQL Databases and dependent apps' failed with a fatal error: The subprocess reported error number 2 when it ended
[2026-07-15 03:12:48] FATAL: The system failed to run the /usr/local/cpanel/scripts/cpanel_initial_install script

Let’s trace through this log line by line, because this is the heart of the whole problem:

• Lines 1-2 (the symptom): The cPanel installer reaches step 4 of 18 and starts running apt-get install for MariaDB packages. Totally normal – this stage should sail through.
• Lines 3-4 (the pattern starts to show): apt fails to locate the mariadb-server package. The phrases ‘Unable to locate package’ and ‘has no installation candidate’ are telltale signs that the repo index on this server doesn’t contain that package, or the mirror is incomplete.
• Line 5 (the second pattern, and the smoking gun): apt tries to fetch an index from http://mirror.local.example/ubuntu/... and gets a 404 Not Found. Your mirror doesn’t even have the index file for the noble-updates suite. That’s hard proof the mirror is out of sync or half-built.
• Lines 6-7: Because the fetch failed, dpkg and apt give up. ‘You have held broken packages’ means some packages are now left in a dangling, half-installed state.
• Lines 8-10: dpkg tries to configure the half-installed MariaDB package from the previous attempt, but it can’t because the dependency mariadb-server-core-10.11 is missing. There’s your real root cause: a broken dependency chain.
• Lines 11-12: The ‘SQL Databases’ background process gives up, and the installer dies with the final error we saw at the start.

So the pattern is clear: symptom (installer fails at the SQL stage) -> pattern (apt can’t fetch indexes from the local mirror) -> root cause (the local APT mirror is out of sync or incomplete, breaking the MariaDB dependency chain). If your log shows lines like ‘404 Not Found’ or ‘Unable to locate package’, congratulations – you’ve found your culprit.

Root Cause: Why Does the Whole Install Fail?

So you’re not just blindly following commands, let’s talk about the actual root cause. cPanel has strict requirements: a clean system, no other web stack, and a reliable repository. When you use a third-party APT mirror (say, the one your hosting provider configured by default), several things can go wrong:

• The mirror isn’t fully synced. Local mirrors pull from the main Ubuntu repos on a schedule. If the sync hasn’t finished, some archives and index files will be missing. The result: apt finds some packages and not others, and 404s pop up randomly.
• Package versions are inconsistent. A stale index makes apt see package versions that no longer exist in the archive. When dpkg tries to configure, the dependency it references is already gone, and you get exit code 2.
• Packages are pruned from the mirror. Some providers trim old package archives to save bandwidth. But cPanel may need a package that got pruned, and apt has no way to get it.

On top of that, two supporting factors make things worse: a hostname that isn’t a proper FQDN can make cPanel refuse to proceed early, and low RAM/disk can get your apt/dpkg processes killed mid-install by the OOM killer. It’s a combination of factors, but the fix is clear and we’ll work through it one step at a time.

Step-by-Step Fix: cPanel Installation Error on Ubuntu 24.04

Alright, this is the part that matters. Follow the order – don’t skip anything. I’ve arranged it from deepest diagnosis to final execution, because skipping a step is exactly how you get the same error twice.

Step 1: Read the Detailed Log and Find the Real Error

First things first – we need to know exactly what went wrong. Don’t guess, don’t assume. Open the cPanel install logs and hunt for the real dpkg error:

ls -la /var/cpanel/updatelogs/
ls -la /var/log/cpanel-install-*.log

On most systems, the latest log lives in /var/cpanel/updatelogs/ with a name like install.2026-07-15_03.12. Initial-install logs can also show up under /var/log/ with a cpanel-install- prefix. Find the newest one:

ls -lat /var/cpanel/updatelogs/ | head -20
ls -lat /var/log/ | grep cpanel-install

Then tail it and grep for anything that looks like an error:

tail -n 200 /var/cpanel/updatelogs/install.2026-07-15_03.12
grep -iE "error|fatal|fail|404|dpkg" /var/cpanel/updatelogs/install.2026-07-15_03.12

What to look for: lines starting with E: or containing FATAL, plus any 404 Not Found from an apt fetch. If you see a 404 or an ‘Unable to locate package’ pointing at a mirror URL, your diagnosis is 90% done: it’s a repository problem. Move to step 2.

Step 2: Clean Up Leftover MySQL/MariaDB Packages

mysqldump --all-databases > /root/backup-mysql-$(date +%Y%m%d).sql
cp -a /var/lib/mysql /root/backup-mysql-dir-$(date +%Y%m%d)

Now let’s see what’s actually installed. On a fresh box this list may be empty, but on a retry it’s usually full of leftovers:

dpkg -l | grep -Ei "mysql|mariadb"

Purge every database package from the old attempt:

apt purge -y 'mysql-*' 'mariadb-*' 'php-mysql*'
apt autoremove -y
apt autoclean

Then remove the leftover config and data directories. Remember, we backed those up a minute ago, so this is safe:

rm -rf /etc/mysql
rm -rf /var/lib/mysql
rm -rf /var/log/mysql

Finally, make sure no packages are left dangling. You want dpkg to start from a clean slate:

dpkg --configure -a
apt --fix-broken install -y

Step 3: Switch APT to the Official Ubuntu Repositories

This is the key step. A local mirror – especially a third-party one – is the number one culprit in this whole saga. Replace everything with the official Ubuntu repositories: archive.ubuntu.com for main packages and security.ubuntu.com for security updates. Without this step, you’ll be staring at the same error again.

On Ubuntu 24.04, repositories live in /etc/apt/sources.list.d/ubuntu.sources using the deb822 format. Back up the existing file first:

cp /etc/apt/sources.list.d/ubuntu.sources /etc/apt/sources.list.d/ubuntu.sources.bak
ls /etc/apt/sources.list.d/

Now fill ubuntu.sources with the official config below. Comment out or delete any line pointing at a mirror (put a # in front of the old ‘Types: deb’ block to disable it):

Types: deb
URIs: http://archive.ubuntu.com/ubuntu/
Suites: noble noble-updates noble-backports
Components: main restricted universe multiverse
Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg

Types: deb
URIs: http://security.ubuntu.com/ubuntu/
Suites: noble-security
Components: main restricted universe multiverse
Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg

One important note: if your VPS runs on ARM (aarch64), replace the URIs with http://ports.ubuntu.com/ubuntu-ports/. And if you’re still on the classic sources.list format, update those lines to the official URLs too and make sure no mirror lines are left behind.

Now verify what’s active:

apt update
apt-cache policy | head -40

Scan the apt-cache policy output and confirm every package Candidate points at archive.ubuntu.com, not your old mirror. If you still see mirror traces, go back and edit the file again.

Why official repos and not just any mirror? Because the official Ubuntu repos are guaranteed complete, version-consistent, and updated on a strict schedule. A poorly maintained local mirror is a source of uncertainty you don’t need. For a cPanel install that pulls in hundreds of dependency packages, a stable package source is half the battle.

Step 4: Sync the System with the Official Repos

Now we make sure the system is clean and fully in sync with the official repositories:

apt update
apt upgrade -y
apt full-upgrade -y

Watch the output. No 404s, no held packages, no red error text. If a package is ‘held back’, check for pinned packages:

apt-mark showhold

Empty output means nothing is pinned. The system is ready for a fresh install. This step also clears out leftover config cruft that could trip up the cPanel installer later.

Step 5: Make Sure the Hostname Is a Proper FQDN

cPanel requires the server hostname to be a Fully Qualified Domain Name (FQDN), like server-01.client-a.com. Check the current one:

hostnamectl
hostname -f
hostname -d

If the hostname is short (like vps12345) or has no domain suffix, set it:

hostnamectl set-hostname server-01.client-a.com

Don’t use the same domain as your primary cPanel account domain – the hostname must be unique and separate from account domains. Verify again:

hostname -f
hostname -d

Both should return the full FQDN. If hostname -d comes back empty, check /etc/hosts and add a mapping for the hostname to the server’s IP.

Step 6: Make Sure the Server Has Enough Resources

cPanel installs are resource-hungry. If RAM or disk runs out mid-install, the OOM killer will take down apt/dpkg and you’ll be staring at the same error again. Check first:

free -m
df -h
nproc

• RAM: 2GB absolute minimum, 4GB+ strongly recommended. If you’re short, you can add temporary swap with fallocate -l 4G /swapfile && chmod 600 /swapfile && mkswap /swapfile && swapon /swapfile. Just remember: swap is not a substitute for RAM.
• Free disk: at least 20GB for a cPanel install. Check with df -h / and make sure the / partition is the big one, not /home or something else.
• CPU: at least 2 cores for anything production-related.

If resources are tight, upgrade the VPS plan before installing. A half-finished install killed by OOM is far more painful than waiting half an hour for a bigger plan.

Step 7: Run the cPanel Installer Again

Everything is clean, so let’s pull the trigger. cPanel installs take 45-90 minutes, so run it inside a screen session. If your SSH connection drops, the install keeps going:

apt install -y screen
screen -S cpanel-install

Inside the screen session, download and run the official cPanel installer:

cd /root
curl -o latest -L https://securedownloads.cpanel.net/latest
sh latest

Let it run. To detach from the screen session without stopping the install, press Ctrl+A then D. To come back, run screen -r cpanel-install. When it finishes, log into WHM at https://YOUR-IP:2087 with the root account.

Tips to Keep Mirror Problems Away on Future Installs

Once is enough, right? Here are the habits I’ve adopted so this specific case never bites twice:

• Reset to official repos right after provisioning. Plenty of VPS providers silently configure a local mirror when the server is first created. As soon as your server is live, check /etc/apt/sources.list.d/ and strip out any third-party mirror before installing anything.
• If you must use a mirror, pick a responsible one. A mirror from a big provider that syncs on a schedule (and publishes status) is tolerable. For cPanel installs, though, official repos are always the safest bet.
• Verify after every apt update. Make it a habit to confirm apt-get update exits without 404s. If a 404 shows up, fix it before moving on, not later.
• Always install cPanel on a fresh VPS. Never install cPanel on a box that already runs Apache, nginx, php-fpm, or a manual MySQL. Those stacks are almost guaranteed to clash with what cPanel needs, and you’ll burn hours hunting mysterious install errors. If that’s already the case, do a clean OS reinstall – sometimes a reset is cheaper than an afternoon of debugging. If you’re curious about rebuilds and moves, check out our complete zero-downtime VPS KVM migration guide.
• Keep your own records. Save the successful install log somewhere as a reference. It’ll save you big time when you need to reinstall one day.

Quick Troubleshooting Table

For those who want the answer in one glance, here’s the cheat sheet:

FAQ: cPanel Installation Error on Ubuntu 24.04

Related Articles

Want to go deeper? Check out more guides on Syslog Solutions:

• How to Fix High Load on a cPanel Server
• VPS KVM Migration: Complete Zero-Downtime Guide 2026
• 10 Ways to Secure Your Linux SSH Server
• Server Monitoring with Prometheus and Grafana

Wrap-Up

The ‘The background process SQL Databases and dependent apps failed’ error on a cPanel install over Ubuntu 24.04 looks terrifying the first time you hit it, but the root cause is almost always something simple: an unhealthy server environment. Read the logs, purge leftover database packages, switch to the official Ubuntu repositories, set an FQDN hostname, check your resources, and rerun the installer inside screen. Do that in order and your cPanel install will sail through to the finish line.

Hit a similar case with a different twist? Drop it in the comments – you never know who it’ll help. And if you’re still stuck after the steps above, go back to the log, compare it against the pattern I described, and work from there. Bookmark this page for the next time you provision a server. Good luck, and may your installs always be boring!