Old kernels belong in the package manager, not in rm. On Rocky Linux, run uname -r, list installed kernel packages with rpm -qa | sort -V | grep '^kernel', then preview sudo dnf remove before accepting it. Remove only an older package, never the version you are running, and never delete kernel files by hand from /boot or /lib/modules. This clears space while keeping a rollback path.

Last updated: 2026-07-31

Table of contents

• Key takeaways
• Why removing old kernels and modules matters for your Linux system
• User intent and what you’ll accomplish in this how-to guide
• How do you remove old kernels on Rocky Linux?
• Cross-distro notes, pitfalls, and case-by-case considerations
• Red Hat family notes
• Ongoing maintenance for a lean, secure kernel setup
• FAQ

Key takeaways

• Run uname -r first. That version stays installed.
• Use rpm to find Rocky Linux and AlmaLinux kernel packages, then use dnf to remove an older one.
• Read the DNF transaction before accepting it. The package list tells you what will actually disappear.
• Never delete files directly from /boot or /lib/modules.
• Keep a known-good fallback kernel for recovery.
• Use apt and dpkg on Ubuntu and Debian. Rocky Linux commands do not belong there.
• An old kernel package and an unused kernel module are different cleanup problems.

Why removing old kernels and modules matters for your Linux system

Multiple past kernels take space in /boot and /lib/modules. They also make the GRUB menu longer, which makes the recovery entry harder to spot when the machine is already having a bad day.

Old packages can also complicate updates. A small /boot partition may fill during a kernel transaction, leaving DNF or the initramfs update half-finished. That is how a routine update becomes a boot problem.

Unused kernel modules are a separate issue. A module is loadable kernel code, while an old kernel is a complete installed kernel package with its own modules and initramfs. Removing an old kernel removes its matching package files. Blacklisting a module only tells the system not to load it.

The goal is straightforward: recover space, reduce boot clutter, and keep a working rollback path. The wrong goal is deleting every older version because the package list looks untidy.

User intent and what you’ll accomplish in this how-to guide

This cleanup answers several related searches:

• Rocky Linux remove old kernels
• AlmaLinux remove old kernels
• Rocky remove old kernels
• Ubuntu clean old kernels
• Remove old kernels on Ubuntu
• Debian remove unused kernels
• Automatically blacklist unused kernel modules with ModuleJail

You’ll learn how to:

• Check the running kernel before cleanup.
• List installed kernel packages and their versions.
• Preview a DNF removal before it changes anything.
• Remove old Rocky Linux and AlmaLinux kernels without deleting files by hand.
• Clean Ubuntu and Debian kernels with apt.
• Check GRUB entries, initramfs files, and disk space.
• See what ModuleJail does and where it does not belong.

How do you remove old kernels on Rocky Linux?

Use the package manager, not rm. Rocky Linux splits kernel files across packages such as kernel, kernel-core, kernel-modules, and sometimes kernel-modules-extra. DNF knows how those pieces relate. A file deletion does not.

1. Confirm the running kernel

Run this first:

uname -r

That output is the kernel currently running the machine. Write it down. Do not remove any package with the same version.

Now check the kernel DNF considers the default boot entry:

sudo grubby --default-kernel

The path should point to an installed kernel under /boot. uname -r tells you what is running now. grubby tells you what the bootloader plans to use next.

2. List installed Rocky Linux kernel packages

Run:

rpm -qa | sort -V | grep '^kernel'

This shows installed kernel packages in version order. You may see several package types for the same kernel release:

• kernel
• kernel-core
• kernel-modules
• kernel-modules-core
• kernel-modules-extra
• kernel-devel
• kernel-headers

The runtime packages are the ones tied to booting and loading that kernel. kernel-devel supports compiling external modules. kernel-headers serves development tools and may not match one old runtime kernel.

Do not treat every line as an independent cleanup target. Match the package version across the related entries, then compare it with the output from uname -r.

3. Preview the removal transaction

Suppose the old package version appears as <old-version>. Preview the transaction with the exact package name shown by rpm:

sudo dnf remove --assumeno kernel-core-<old-version>

DNF will show what it plans to remove without applying the change. Read the package list. If the transaction includes the running kernel, a required dependency, or a large unrelated group of packages, stop there.

For a split kernel package, the final removal may include several matching package names:

sudo dnf remove \
 kernel-<old-version> \
 kernel-core-<old-version> \
 kernel-modules-<old-version> \
 kernel-modules-core-<old-version> \
 kernel-modules-extra-<old-version>

Use only the package names that actually appeared in your rpm output. Do not copy every line blindly. Some Rocky Linux installations do not have every split package.

4. Remove the old kernel with DNF

After checking the preview, run the same command without --assumeno:

sudo dnf remove kernel-core-<old-version>

If DNF asks to remove the matching module packages, review the complete transaction and accept it only when the running kernel remains installed.

Removing the top-level kernel package may remove its matching support packages automatically. If it leaves an old kernel-modules or kernel-devel package behind, inspect it first:

rpm -qa | sort -V | grep '^kernel'

Then remove the exact stale package with DNF. Do not chase leftovers by deleting paths from /lib/modules.

5. Check the result

Confirm the installed kernels again:

rpm -qa | sort -V | grep '^kernel'

Then inspect the boot entries:

sudo grubby --info=ALL

Check the space recovered:

df -h /boot /

Rocky Linux normally updates the boot files as part of the package transaction. You should not run grub2-install just because you removed a kernel. That command changes bootloader installation. It is not a cleanup command.

If a removed kernel still appears in the boot menu, inspect grubby output and the package transaction before rebuilding anything. A stale menu entry and a broken bootloader are not the same problem.

Do you need to rebuild the initramfs?

Usually, no. Removing a packaged kernel removes its matching initramfs through the package scripts.

If a boot entry points to a missing or damaged initramfs, first identify an installed kernel:

rpm -qa | sort -V | grep '^kernel'

Then rebuild the initramfs for that installed version:

sudo dracut --force --kver <installed-version>

Do not run a broad initramfs rebuild as a ritual after every package removal. Check the file, the package ownership, and the boot entry first. The kernel package transaction normally did the required work.

What does DNF autoremove actually do?

Preview it before accepting:

sudo dnf autoremove --assumeno

If the proposed list is sensible, run:

sudo dnf autoremove

dnf autoremove removes packages DNF considers unused dependencies. It is not a precise old-kernel selector. Use exact package removal when you know which kernel must go, and use autoremove afterward for leftovers.

The mistake is accepting a large autoremove transaction because the word “unused” sounds safe. Read the output. DNF is following dependency metadata, not your intent.

Cross-distro notes, pitfalls, and case-by-case considerations

Different distributions package kernels differently. The command that is correct on Rocky Linux is wrong on Ubuntu, and the reverse is also true.

Ubuntu and Debian cleanup

First, confirm your current kernel with uname -r and list installed packages with:

dpkg --list | egrep -i --color 'linux-image|linux-headers'

The dpkg status flags matter:

• ii means the package is installed.
• rc means the package was removed but configuration files remain.
• iU means the package was unpacked but is not fully configured.

Do not purge an iU package as if it were normal cleanup. Repair the interrupted package state first.

For routine Ubuntu cleanup, run:

sudo apt autoremove --purge

Review the proposed removals before confirming. If an old image remains, target the exact package name:

sudo apt purge linux-image-<version>
sudo apt purge linux-headers-<version>

Ubuntu's documented package pattern also allows a specific image such as:

sudo apt-get purge linux-image-4.12.0-12-generic

Matching header packages must be purged separately when they are no longer needed.

On Debian stretch, the purge-old-kernels utility never removes the running kernel. By default, it retains at least the two newest kernels, and the --keep N option changes that retention count:

sudo purge-old-kernels

Do not assume that utility is present on every Ubuntu or Debian release. Check the installed command and package policy first.

GUI cleanup with Synaptic

If you prefer a graphical path on Ubuntu or Debian, install Synaptic:

sudo apt install synaptic -y

Open it with administrative privileges, search for linux-image and linux-headers, and mark older entries for Complete Removal.

Synaptic makes package selection easier to see, but it does not remove the need for the uname -r check. A GUI can still let you select the running kernel. The mouse does not know which kernel is keeping the machine alive.

For a deeper explanation of why apt autoremove sometimes leaves old kernels behind, see why Apt Autoremove leaves old kernels behind.

Common cleanup mistakes

Avoid these shortcuts:

• Keep the running kernel installed. Check it with uname -r before removing anything.
• Do not delete vmlinuz, initramfs, or module directories by hand.
• Do not use chmod, rm, or wildcard deletion to force space back.
• Read every DNF or APT transaction before confirming it.
• Keep a fallback kernel on a production machine.
• Treat an unused module and an old kernel package as separate problems.
• Check package ownership and boot entries before rebuilding GRUB.

If the package manager says a kernel is protected, that is useful information. Read the error instead of forcing the removal. Protected packages and install-only rules exist because booting from a missing kernel is not a clever optimization.

Red Hat family notes

Rocky Linux, AlmaLinux, RHEL, and CentOS use the RPM and DNF model for kernel packages. The package names and split-package layout can vary, but the safe process stays the same:

1. Check uname -r.
2. List packages with rpm.
3. Preview the DNF transaction.
4. Remove the old package.
5. Check grubby, /boot, and disk space.

The DNF retention setting lives in /etc/dnf/dnf.conf. Inspect it before changing anything:

grep -E '^[[:space:]]*installonly_limit' /etc/dnf/dnf.conf

That setting controls how many install-only packages DNF retains. Do not lower it just to make /boot look clean. A fallback kernel is cheap insurance compared with a rescue session.

AlmaLinux follows the same general approach for removing old kernels. Use uname -r, rpm -qa, and dnf remove, then inspect the transaction. Do not paste Ubuntu's apt purge command into AlmaLinux and expect a useful result.

Check DNF history before you need rollback

List recent DNF transactions:

sudo dnf history

Inspect one transaction in detail:

sudo dnf history info <transaction-id>

If a removal went wrong and the packages are still available, DNF may be able to reverse that transaction:

sudo dnf history undo <transaction-id>

Review the proposed undo transaction before accepting it. History is not a substitute for keeping a known-good kernel. If the package is no longer available from the configured repositories, the undo may not restore what you removed.

If a kernel update caused the trouble, boot the older entry from GRUB before trying package surgery. Then read the previous boot's kernel messages:

sudo journalctl -b -1 -k

A panic after cleanup does not prove that removal caused it. Check the kernel version, the initramfs path, and the DNF transaction. The message in the kernel ring buffer is more useful than a guess.

ModuleJail is not an old-kernel remover

ModuleJail appears in searches about automatically unused kernel modules because it addresses a different problem. ModuleJail is a single POSIX shell script that snapshots currently loaded modules and writes a modprobe.d blacklist for modules not currently in use, minus a built-in baseline and an optional sysadmin whitelist.

It is not a daemon or continuous monitor. It does not remove old kernels, delete module files, or reclaim the space used by a complete kernel package.

A blacklist can also break hardware that is not active during the snapshot. Test it on a lab system first, and keep a recovery path. For the difference between listing and unloading modules, see how to list loaded Linux kernel modules. For the sysadmin use case, see automatic kernel module blacklisting.

Ongoing maintenance for a lean, secure kernel setup

Check kernel packages after major updates and before /boot becomes full. On Rocky Linux, use:

uname -r
rpm -qa | sort -V | grep '^kernel'
df -h /boot /

On Ubuntu or Debian, use:

uname -r
dpkg --list | egrep -i --color 'linux-image|linux-headers'
df -h /boot /

Keep a known-good fallback, but do not let old builds accumulate without review. When a new kernel arrives, confirm that the machine boots it before removing an older one.

For scripted cleanup, make the script print the running version, list every candidate, and stop for confirmation. A script that blindly deletes the oldest package is not maintenance. It is a delayed outage.

If you need to update kernels safely across distributions, use the Linux kernel update guide. If the new kernel fails, follow the kernel rollback guide instead of deleting files until the symptoms change.

FAQ

Why does DNF want to remove several kernel packages at once?

Because Rocky Linux splits one kernel release across several RPM packages. The core image, modules, and optional modules can share the same version, so removing that release together is normal. The transaction is safe only if another complete kernel remains installed.

What if /boot is full before I can remove an old kernel?

Use package ownership before touching files. List the installed packages, identify the running kernel, and remove one complete old kernel through DNF or APT. If files remain, run rpm -qf or dpkg -S to find the owning package instead of guessing with rm.

Can I remove an old kernel-devel package and keep the running kernel?

Usually, yes. kernel-devel is for building external modules, not for booting the runtime kernel. Check the exact package version and read the transaction; if DNF proposes unrelated removals, stop and investigate.

Does ModuleJail delete unused kernel modules?

No. ModuleJail writes a modprobe.d blacklist from the modules that are not currently loaded, while keeping its baseline and any configured whitelist. The module packages and files stay installed, so it does not recover disk space.

What should I do if the machine panics after kernel cleanup?

Boot the previous kernel from GRUB if it is still installed. Once the system is up, compare uname -r with the boot entry and read journalctl -b -1 -k. If no fallback works, collect the console or kdump message before reinstalling anything.

Related: Linux Kernel Version History: From 0.01 to 7.X

Related: Rmdir vs Rm: Safe Linux Deletion Without Guesswork