How to Safely Remove Old Kernels on a cPanel CloudLinux Server
Safely remove old Linux kernels from a cPanel/WHM server running CloudLinux, free space in /boot, and keep a working fallback kernel.
8 min read
A kernel update on CloudLinux installs the new kernel next to the existing ones. It does not replace the kernel you are running. That is deliberate: if the new kernel fails to boot, GRUB can still start the previous one.
The cost is that kernels pile up. Each one takes well over 100 MB in /boot once its initramfs is counted, and on a server with a small /boot partition it does not take many before updates fail with “At least 42MB more space needed on the /boot filesystem”. From then on the server gets no new kernels at all.
You are only after the obsolete ones. The running kernel and at least one fallback stay, and everything goes through the package manager.
Before You Start
- A cPanel/WHM server on CloudLinux OS 8 or 9. CloudLinux 7 gets a short legacy note below.
- Root access over SSH or through WHM → Terminal. The work happens at the operating system level; WHM has no kernel cleanup feature.
- A current backup or snapshot, and for a production server, console access from your provider.
- Removing old kernels does not itself need a reboot. One is only needed if a newer kernel is installed but the server still runs the old one, covered further down.
Step 1: Check Your CloudLinux Version
The major version decides which cleanup command applies.
cat /etc/redhat-release
The same line is in /etc/cloudlinux-release. It starts with CloudLinux release 8. or CloudLinux release 9., and both use the DNF procedure in this guide.
Step 2: Check the Running Kernel
uname -r
This is the kernel the server booted with, and it stays in use until the next reboot. It must not be removed. DNF protects it, but note the version anyway so you can spot it in the package list and confirm it survived.
Keep two things separate: the running kernel is what uname -r reports, while the latest installed kernel is the newest package on disk. On a server that has updated without rebooting they differ, and both must stay.
Step 3: Check /boot Space
df -h /boot
If /boot is its own filesystem, this shows how full it is. On cPanel servers it is often 1 GB, and older installs sometimes have half that, which three kernels and their rescue images will fill. If the output shows / instead, /boot is just a directory on the main disk. Cleanup still frees space, but it is unlikely to be why updates fail.
To see how much the kernel files take up:
du -sh /boot
Step 4: See Which Kernels Are Installed
rpm -qa 'kernel*' | sort -V
On CloudLinux 8 and 9 each kernel is split across kernel, kernel-core, and kernel-modules, sometimes with kernel-modules-extra or kernel-devel. Count distinct version strings, not lines.
CloudLinux 9 uses the AlmaLinux kernel, so versions look like 5.14.0-...el9. CloudLinux 8 versions may contain lve, but not every valid CloudLinux kernel does, so do not use that as a test of what to keep. The LVE module itself is the separate kmod-lve package.
If the list shows kernel-lts or kmod-lve-lts, the server is on CloudLinux’s optional LTS kernel arrangement, which replaces the standard package set. Stop and confirm with the CloudLinux kernel documentation or CloudLinux support before removing anything. The command below is for the standard kernel family.
Step 5: Remove Old Kernels on CloudLinux 8/9
This is the command cPanel and CloudLinux both document for CloudLinux 8 and 9:
dnf remove --oldinstallonly --setopt installonly_limit=2 kernel
--oldinstallonlytargets only install-only packages, the ones DNF keeps in several versions rather than upgrading in place. Kernels are the main example.--setopt installonly_limit=2keeps the two newest versions for this run, whatever the config file says.kernelkeeps the transaction to the kernel family. The matchingkernel-coreandkernel-modulespackages follow through dependencies; you do not remove them by hand.
DNF never removes the running kernel, even when it is older than the two newest versions.
There is deliberately no -y. DNF prints the transaction and waits. Read it: every version listed should be older than the running kernel, and every package should be in the kernel* family. If the running kernel, kmod-lve, or anything unrelated appears, answer N and see When Not to Proceed.
Do not delete kernel files from /boot by hand. The vmlinuz-*, initramfs-*, System.map-*, and config-* files belong to installed packages, and GRUB’s boot entries point at them. Removing them with rm leaves RPM believing a kernel exists when it does not, and can leave boot entries that no longer work. Routine cleanup goes through DNF, which removes the files and updates the boot configuration together.
CloudLinux’s knowledge base writes the same operation as yum remove --oldinstallonly. On CloudLinux 8 and 9, yum is DNF, so use the form above.
Legacy CloudLinux 7
CloudLinux 7 left standard support in 2024. On a server still running it, the platform is the bigger problem, and the right next step is our guide on when to upgrade or migrate an older server. For reference, cPanel still documents the older tool, from the yum-utils package, for CloudLinux 6 and 7:
package-cleanup --oldkernels --count=2
Do not use it on CloudLinux 8 or 9.
Step 6: Verify the Cleanup
uname -r
rpm -qa 'kernel*' | sort -V
df -h /boot
grubby --default-kernel
A healthy result:
- The
uname -rversion is still in the package list. - The newest kernel is still there, plus at least one other as fallback.
/boothas more free space than before.grubby --default-kernelreturns a path matching an installed version, normally the newest. If it does not, do not reboot until you know why.
No reboot is needed. The server carries on with the kernel it booted with.
If You Are Still Running an Older Kernel
A common case on a hosting server: updates installed a newer kernel, nobody rebooted, and uname -r still reports the old version. After cleanup you have at least two kernels, the running one and the newer one, and DNF will not remove either.
Do not remove the running kernel because a newer package exists. Plan a reboot instead. Pick a quiet time, have console access open, and take a snapshot first. After it comes back, confirm the new version is running and the LVE module loaded:
uname -r
lsmod | grep -i lve
Once the new kernel is stable, the previous one is your fallback, and any further cleanup can wait for the next update cycle.
If the server is behind on updates, run dnf update and review the transaction before confirming. Do not chain a reboot onto it. Kernel changes on a production server belong in a scheduled window, not a one-liner.
Set Kernel Retention
DNF can keep the count down on its own through installonly_limit in /etc/dnf/dnf.conf. Check the current value first:
grep -E '^installonly_limit=' /etc/dnf/dnf.conf
No output means the default of 3 applies. To change it, open the file with nano /etc/dnf/dnf.conf and set the line under [main]:
installonly_limit=2
| Value | When it makes sense |
|---|---|
2 | Sensible minimum: the running kernel plus one fallback. |
3 | Fine when /boot has room; one extra fallback. |
1 | Never. DNF rejects it, and it would leave no fallback if a kernel failed to boot. |
From then on each kernel update removes the oldest surplus version in the same transaction. It does not touch kernels already installed, which is why the one-off cleanup above is still needed.
KernelCare and Old Kernels
KernelCare applies kernel security patches in memory without a reboot, which is why many cPanel servers run for months on the same booted kernel. To see what it has applied:
kcarectl --uname
kcarectl --patch-info
The first shows the effective patched version, the second lists applied patches. Neither changes anything about kernel packages. Old kernels still accumulate on a KernelCare server, the same cleanup applies, and removing the booted kernel is no safer. What KernelCare buys you is fewer reboots for security fixes. It does nothing about the kernels sitting in /boot.
When Not to Proceed
Stop and get help if any of these apply:
- You cannot tell which kernel is running, or
uname -rmatches no installed package. - DNF’s transaction includes the running kernel,
kmod-lve, or packages outsidekernel*. - DNF or RPM fails before showing a transaction, for example with database or lock errors, which a completely full disk can cause.
- The server has
kernel-lts,kmod-lve-lts, or a kernel arrangement you did not set up. grubby --default-kernelerrors, or/bootalready looks inconsistent with the package list.- The server is production-critical and you have no console access.
- DNF reports a dependency conflict involving
kmod-lve. Do not improvise a fix; that module is what enforces CloudLinux’s per-user limits. Follow CloudLinux’s current kernel guidance or open a ticket with them.
This guide is routine maintenance. A /boot already out of step with the package database, or a server that will not boot, is a recovery job with a different procedure.
On a GoZen managed VPS, kernel updates and cleanup are part of the maintenance we handle. Otherwise, if you hit a stop condition, open a ticket with the output of Steps 1 to 4 and we can advise.
Related Articles
- How to Manage Disk Space on a VPS - the broader guide to finding and clearing what fills the disk
- Managing VPS Snapshots - take a rollback point before any kernel work
- When Is It Time to Upgrade or Migrate an Older Server? - if the server is still on CloudLinux 7
- GoZen Managed VPS: What’s Included - where the line sits between what we maintain and what you do
- How to Get Support - open a ticket if cleanup hits a stop condition
Last updated 01 Sep 2026, 00:00 +0200.