Manage Old Kernels and Clean /boot

A full /boot partition is one of the most common reasons a routine system update fails. Linux kernels accumulate quickly — every point release drops a new set of files into /boot and into /lib/modules, and most distributions keep several by default. This guide shows you how to identify old kernels, remove them safely without breaking your bootloader, automate the cleanup, and keep /boot healthy going forward.

Check Current Disk Usage

Start by seeing how full /boot actually is and which kernels are installed.

df -h /boot

Output will vary, but anything above 80% warrants attention. Next, find out which kernel you are currently running:

uname -r

Never remove the running kernel. Note this version — it is off-limits for the rest of the guide.

List Installed Kernels

Debian and Ubuntu

dpkg --list | grep -E 'linux-image|linux-headers|linux-modules'

Look for lines beginning with ii (installed). Each kernel version typically has a matching linux-image, linux-headers, and one or more linux-modules package.

Fedora, RHEL, Rocky, AlmaLinux

rpm -q kernel

dnf list installed kernel\*

Arch Linux

Arch does not version-suffix kernels in the same way. You manage kernel files directly; see the Arch-specific section below.

pacman -Q linux linux-lts linux-zen 2>/dev/null

Remove Old Kernels Safely

Debian and Ubuntu — autoremove (recommended first step)

apt autoremove is aware of which kernels are safe to drop. It removes old kernel packages that are no longer marked as manually installed and are not the current or most recent kernel.

sudo apt autoremove --purge

The --purge flag also removes configuration files, which matters for headers packages. Review the list before confirming. If /boot is so full that apt itself fails, see the Emergency section below.

Manually removing a specific old kernel on Debian/Ubuntu

Replace 5.15.0-91 with the version you want to remove — never the output of uname -r.

sudo apt purge linux-image-5.15.0-91-generic \
             linux-headers-5.15.0-91 \
             linux-headers-5.15.0-91-generic \
             linux-modules-5.15.0-91-generic \
             linux-modules-extra-5.15.0-91-generic

After purging, update the bootloader so GRUB no longer shows removed entries:

sudo update-grub

Fedora, RHEL 8+, Rocky, AlmaLinux

DNF keeps the two most recent kernels by default, controlled by installonly_limit in /etc/dnf/dnf.conf. You can run cleanup manually:

sudo dnf remove --oldinstallonly --setopt installonly_limit=2

Or target a specific kernel package explicitly:

sudo dnf remove kernel-5.14.0-362.8.1.el9_3.x86_64

DNF updates the GRUB2 configuration automatically on RPM-based systems via the kernel install scripts.

Arch Linux

Arch ships a single linux package that overwrites itself on upgrade, so old kernels do not accumulate the way they do on Debian or Fedora — unless you explicitly install multiple kernel flavours (linux-lts, linux-zen, etc.). Orphaned module directories can linger in /usr/lib/modules; clean them with:

sudo pacman -Rns linux-lts   # only if you no longer want that kernel

# Remove orphaned module directories not matching any installed kernel
for d in /usr/lib/modules/*/; do
  ver=$(basename "$d")
  pacman -Q linux 2>/dev/null | grep -q "$ver" || echo "Orphan: $d"
done

Arch uses grub-mkconfig or a hooks-based approach depending on your setup:

sudo grub-mkconfig -o /boot/grub/grub.cfg

Automate Kernel Retention Limits

Debian and Ubuntu

Install needrestart or configure unattended-upgrades, but for kernel count the most direct lever is ensuring apt autoremove runs after upgrades. Many Ubuntu installs already do this. You can also cap retention manually by adding a post-invoke hook:

sudo nano /etc/apt/apt.conf.d/99-kernel-limit

APT::Periodic::AutocleanInterval "7";
Unattended-Upgrade::Remove-Unused-Kernel-Packages "true";
Unattended-Upgrade::Remove-New-Unused-Dependencies "true";

Fedora / RHEL family

Edit /etc/dnf/dnf.conf and set:

installonly_limit=2

The default is 3. A value of 2 keeps the running kernel plus one previous — a reasonable safety margin. Do not set it to 1; you lose your fallback.

Emergency: /boot Is 100% Full

If /boot is completely full, package manager commands will fail mid-operation, which can corrupt package state. The safest approach is to manually delete one old initramfs or kernel image just enough to give the package manager room to breathe.

# List files in /boot sorted by size
ls -lhS /boot

# Identify an old initramfs — NOT the one matching uname -r
# Example only — verify your version strings first
sudo rm /boot/initrd.img-5.15.0-88-generic

With a few megabytes freed, run the normal apt autoremove --purge or dnf remove --oldinstallonly immediately. Do not leave /boot in a partially manual state longer than necessary.

Verify the Cleanup

# Confirm free space recovered
df -h /boot

# Confirm GRUB menu reflects current state
grep menuentry /boot/grub/grub.cfg | head -20

# Reboot into the current kernel and confirm it boots correctly
sudo systemctl reboot

After rebooting, run uname -r again to confirm the expected kernel loaded. Check journalctl -b -p err for any boot-time errors.

Troubleshooting

• GRUB shows removed kernels: Run sudo update-grub (Debian/Ubuntu) or sudo grub2-mkconfig -o /boot/grub2/grub.cfg (RHEL family) and reboot.
• apt says "unable to write" during autoremove: /boot is still full. Use the emergency method above to free a small amount of space manually first.
• Removed kernel was the only one listed in GRUB: Boot from a live USB, mount your partitions, and reinstall the kernel package from a chroot. This is why you always keep at least two kernels.
• Missing /lib/modules after purge: If you accidentally removed the running kernel's modules, reinstall it: sudo apt install --reinstall linux-image-$(uname -r) from a live environment if necessary.
• dpkg errors about /boot during kernel upgrade: Almost always caused by a full /boot. Free space first, then re-run sudo dpkg --configure -a followed by sudo apt -f install.