Remove all old installed but unused kernels

Your /boot partition is screaming. You check the disk usage and find it’s somehow 95% full. Kernel updates. That’s always the culprit.

Every time Ubuntu or Debian installs a new kernel, it leaves the old one sitting there “just in case.” After a year, you’ve got 8 kernels installed and only one is actually running. It’s like a digital hoarder — “I might need this one day” — except you won’t. That day never comes.

Here’s the thing: old kernels don’t uninstall themselves. You have to kick them out manually. The good news? It’s not complicated. The bad news? There’s a trap that’ll leave you staring at a black screen if you’re not careful.

Why Do Old Kernels Pile Up?

Package managers on Debian/Ubuntu systems don’t automatically nuke old kernels because someone, somewhere, might need to boot into them. It’s a reasonable philosophy — kernel bugs happen, and occasionally you need to revert to a known-good version. But after six months? After a year? You’re never going back.

Each kernel installation dumps files into /boot: the kernel image (vmlinuz-*), the init ramdisk (initrd.img-*), the system map (System.map-*). On a typical system, that’s 50-100 MB per kernel. With 8 kernels, that’s 400-800 MB gone, and if your /boot is only 512 MB (older systems), you’ve got a problem. You can’t install updates. You can’t update GRUB. You’re stuck.

Know Your Running Kernel

First, don’t panic. Check which kernel you’re actually using:

$ uname -r
6.1.0-28-generic

That’s your current kernel. Everything else on the system is excess baggage.

To see all installed kernels:

$ dpkg -l | grep linux-image
ii  linux-image-6.1.0-10-generic   6.1.0-10.10~22.04.1   amd64
ii  linux-image-6.1.0-13-generic   6.1.0-13.13~22.04.1   amd64
ii  linux-image-6.1.0-18-generic   6.1.0-18.18~22.04.1   amd64
ii  linux-image-6.1.0-28-generic   6.1.0-28.28~22.04.1   amd64

See? Four kernels. Only one of them (6.1.0-28) is running. The other three are dead weight.

The Easy Way: apt autoremove

If you’re on Ubuntu 18.04+, the simplest move is:

$ sudo apt autoremove

That’s it. autoremove is smart enough to keep your current kernel and nuke the old ones. It figures out dependencies and cleans up the mess.

But here’s the wisdom: always test first:

$ sudo apt autoremove --dry-run

This shows you what would be deleted without actually doing it. Look at the list. If you see your current kernel getting marked for removal, stop. Something’s wrong. Don’t run the actual command.

If the dry-run looks good, go ahead:

$ sudo apt autoremove

Done. Your /boot should have breathing room again.

The Manual Way: dpkg Purge

If autoremove doesn’t work or you want surgical precision, you can purge kernels manually. This one-liner removes all kernels except your current one:

$ dpkg -l 'linux-*' | sed '/^ii/!d;/'"$(uname -r | sed "s/\(.*\)-\([^0-9]\+\)/\1/")"'/d;s/^[^ ]* [^ ]* \([^ ]*\).*/\1/;/[0-9]/!d' | xargs sudo apt-get -y purge

Yeah, it looks like regex spaghetti. What it does: lists all linux-* packages, filters out the running kernel, and purges the rest. Copy the whole thing and paste it in. Don’t try to understand it — just trust it.

The purge flag removes not just the package but its config files too, freeing up more space than a simple remove would.

The Proxmox Quirk

If you’re running Proxmox, the standard commands sometimes don’t work the same way because Proxmox uses its own kernel naming scheme. You might see kernels like proxmox-kernel-6.8.12-1-pve. On Proxmox:

$ sudo proxmox-boot-tool refresh

This rebuilds your boot loader and can clean up orphaned kernels from the EFI partition. Proxmox folks have it handled differently — the tool knows what to do.

How Many Kernels Should You Keep?

My rule: keep two. One running, one backup. If the current kernel has a showstopper bug, you boot into the previous one while you figure it out. If you keep three, you’re just hedging for a 1-in-100 edge case that’ll probably never happen.

On servers with automated backups and monitoring? Keep one. You’ll never reboot into an old kernel on prod anyway.

The Horror Story: Never Delete Your Running Kernel

Do not, under any circumstances, delete the kernel you’re currently running. I say this with the voice of experience. Someone always does it.

You run the purge command. It works. You reboot. Nothing happens. Just a black screen. System won’t boot.

Why? Because you accidentally nuked the kernel you’re using. Happened on a remote server in 2015, 2 AM, and I had to call a hosting provider to boot into a liveUSB just to fix it. That was a fun evening.

The fix: Use --dry-run first. Every time. No exceptions. And double-check that uname -r is never in that list of packages to be removed.

If you ever see your current kernel listed in the removal list, abort immediately and investigate.

Cleaning Up Proxmox (Special Case)

If your Proxmox node’s boot partition is full:

$ sudo pve-efiboot-tool refresh

This rebuilds the EFI boot entries and can reclaim space from old kernels that didn’t fully uninstall.

After Cleanup

Once you’ve removed the old kernels, regenerate your boot loader configuration:

$ sudo update-grub

On Proxmox, that’s already handled. Everywhere else, run it to be safe.

Check your /boot space:

$ df -h /boot
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       487M  145M  318M  32%

Much better. You’re not breaking a sweat anymore.

That’s it. Old kernels gone, /boot breathing again, and you still have a safety net if something goes sideways. Don’t hoard.