Why Old Kernels Linger in /lib/modules After apt autoremove (and How to Purge Them)

apt autoremove did not miss those kernels — it already removed the packages. What you are seeing in /lib/modules/ are not installed kernels but leftover "residual config" files that apt remove deliberately keeps on disk. To actually reclaim the space and clean the directories, you need to purge those packages with sudo apt purge '~c'.

Removed vs. Purged: Why the Directories Remain

Debian-family package management distinguishes between two levels of removal:

• remove — deletes the package's binaries and data files, but keeps its configuration files and any directories dpkg considers configuration.
• purge — deletes everything, including the configuration files.

The contents of /lib/modules/<version>/ — files such as modules.alias, modules.dep, and modules.symbols — are treated as configuration data by the kernel packages. So when automatic kernel cleanup runs apt remove on an old kernel, the linux-image and linux-modules packages vanish from the package list, but these module index files stay behind inside their version-numbered directories.

This is also why autoremove --purge will not help retroactively: those packages are already in the "removed but config remains" state, so there is nothing left for autoremove to act on. You have to purge the residual state directly.

Confirm What You Are Actually Looking At

First, check which kernels are genuinely installed by looking at the boot images, not the module directories:

ls -l /boot/vmlinuz-*

Only kernels with a matching vmlinuz file are installed and bootable. Then list the packages in the removed-with-config state. apt supports the ~c pattern for exactly this:

apt list '~c'

You will likely see a long list of linux-image-… and linux-modules-… entries marked [residual-config], one per old kernel. You can verify that one of the "orphaned" module directories is nearly empty — containing only those small index files — which confirms it is a leftover, not a usable kernel:

ls -l /lib/modules/6.17.0-22-generic/

Cleaning Everything in One Command

If your ~c list contains only kernel-related packages (common on a well-maintained system), a single command clears all residual configs:

sudo apt purge '~c'

dpkg purges the configuration state of each package, and because the kernel packaging scripts remove their module directory when it is emptied, the stale folders under /lib/modules/ disappear with it. If dpkg reports a directory was "not empty so not removed," check what remains inside before deleting it manually.

Being Selective Instead

Residual configs are not always junk — a package you removed may be reinstalled later, and its retained configuration can save you setup time. If your ~c list includes non-kernel packages you want to keep, purge only the kernel leftovers by name. Kernel packages come in families (image, modules, modules-extra, plus hardware-specific variants like modules-ipu6), and brace expansion makes this concise:

sudo apt purge linux-{image,modules,modules-extra}-6.17.0-{22,23,29}-generic

Warning: apt purge with a typo can remove packages you did not intend to touch. Always review the "The following packages will be REMOVED" list before confirming, and never wildcard kernel names blindly. Keep at least the kernel you are currently running (check with uname -r) and one older fallback installed.

Preventing the Buildup Going Forward

To stop this from recurring, make purging the default when automatic removal happens:

• Run sudo apt autoremove --purge as your routine cleanup command, so old kernels are purged rather than merely removed.
• Configure unattended-upgrades to remove unused dependencies with APT::Get::AutomaticRemove and purge behavior set appropriately in /etc/apt/apt.conf.d/50unattended-upgrades.
• Periodically audit with apt list '~c' — a growing list is a sign that cleanup has been running without purge.

Frequently Asked Questions

Are the directories in /lib/modules for removed kernels still bootable?

No. Without a corresponding vmlinuz-… and initrd.img-… in /boot, there is nothing to boot. The module index files left behind are inert data taking up tens of megabytes.

Why does apt keep configuration files on remove at all?

It preserves user settings so a reinstall restores previous configuration. For kernel packages this side effect is the module index files under /lib/modules, which serve no purpose once the kernel image is gone.

Is apt purge '~c' safe?

It only affects packages already removed, so it cannot uninstall working software. However, it discards their saved configuration permanently, so review the list first if you might reinstall and want those settings back.

Does autoremove --purge clean up leftovers from earlier removes?

No. It changes the behavior for future removals. Packages already in the removed-with-config state must be purged explicitly with apt purge '~c' or by name.

How can I tell which kernel I am running?

Use uname -r. Never purge the packages matching that version, and keep at least one other known-good kernel installed as a fallback before cleaning anything.