Today, I noticed that the directory /lib/modules still have all the directories from previously installed kernels, thus:

$ ls /lib/modules
5.4.0-29-generic  5.4.0-31-generic  5.4.0-33-generic  5.4.0-37-generic  5.4.0-39-generic
5.4.0-40-generic  5.4.0-42-generic  5.4.0-45-generic  5.4.0-47-generic  5.4.0-48-generic
...  etc.

In each of these directories, the following files are left (Intel/AMD system):

$ ls -l
-rw-r--r--  1 root 143K 2022-04-28 18:36 modules.alias
-rw-r--r--  1 root 154K 2022-04-28 18:36 modules.alias.bin
-rw-r--r--  1 root 8.0K 2022-04-08 10:44 modules.builtin
-rw-r--r--  1 root  25K 2022-04-28 18:36 modules.builtin.alias.bin
-rw-r--r--  1 root  11K 2022-04-28 18:36 modules.builtin.bin
-rw-r--r--  1 root  63K 2022-04-08 10:44 modules.builtin.modinfo
-rw-r--r--  1 root  85K 2022-04-28 18:36 modules.dep
-rw-r--r--  1 root 123K 2022-04-28 18:36 modules.dep.bin
-rw-r--r--  1 root  268 2022-04-28 18:36 modules.devname
-rw-r--r--  1 root 215K 2022-04-08 10:44 modules.order
-rw-r--r--  1 root  489 2022-04-28 18:36 modules.softdep
-rw-r--r--  1 root 279K 2022-04-28 18:36 modules.symbols
-rw-r--r--  1 root 326K 2022-04-28 18:36 modules.symbols.bin

And for a Raspberry Pi (notice the size differences):

-rw-r--r--  1 root 859K 2022-04-25 17:31 modules.alias
-rw-r--r--  1 root 893K 2022-04-25 17:31 modules.alias.bin
-rw-r--r--  1 root  11K 2022-04-04 13:33 modules.builtin
-rw-r--r--  1 root  27K 2022-04-25 17:31 modules.builtin.alias.bin
-rw-r--r--  1 root  14K 2022-04-25 17:31 modules.builtin.bin
-rw-r--r--  1 root  84K 2022-04-04 13:33 modules.builtin.modinfo
-rw-r--r--  1 root 399K 2022-04-25 17:31 modules.dep
-rw-r--r--  1 root 548K 2022-04-25 17:31 modules.dep.bin
-rw-r--r--  1 root  250 2022-04-25 17:31 modules.devname
-rw-r--r--  1 root 209K 2022-04-04 13:33 modules.order
-rw-r--r--  1 root  950 2022-04-25 17:31 modules.softdep
-rw-r--r--  1 root 354K 2022-04-25 17:31 modules.symbols
-rw-r--r--  1 root 425K 2022-04-25 17:31 modules.symbols.bin

For a system that's been running for 2 years with all kernel upgrades, this amounts to ~50 old directories. For a normal Intel/AMD system, it's around 100 Megabytes, and for a Raspberry Pi it's over 300 Megabytes in total - it will amount to something over time.

So I wonder why these old module directories and files for removed kernels aren't removed as part of the cleanup process?

I recently upgraded from Ubuntu 20.04 to 22.04 (which is why I'm doing some cleanup stuff anyway).

As things currently stand, I wonder if I should make my own cleanup script for these leftover directories. Still, I'm curious why it isn't done automatically.

  • 1
    I can't answer why they are kept as I'm not sure myself, so I'll keep this as a comment. If you to clean them up, you can use the following command (It uses the dry-run option, so you need to remove that if you are satisfied with that it will delete) apt purge $(dpkg -l | grep "^rc\s*linux" | awk '{print $2}') --dry-run
    – Dan
    May 4, 2022 at 16:02
  • 3
    It is called prudence. Better to not remove something automatically then to remove something that might break a system. Those few kbs on your system do not do any harm. Mind that since we nowadays do automatically remove old kernels... we could consider this a bug :)
    – Rinzwind
    May 4, 2022 at 16:58
  • 1
    There is an excellent old kernel removal management tool here. May 4, 2022 at 18:51
  • 1
    FYI: Check out you haven't marked them as manually installed; ie. had a problem which was fixed by apt install... causing the normally automatically installed kernels being flagged as manually installed thus not cleaned up as you tool control off the automatic procedures.
    – guiverc
    May 4, 2022 at 22:31

3 Answers 3


I don't know why

I don't think you will get a good answer to why Ubuntu does something the way it does something.


Up until some years ago Ubuntu didn't clean up any kernel and kernel header packages at all. Now Software Updates removes old and unused kernels. I think it runs something like:

sudo apt autoremove

Unfortunately it leaves those module files behind.

Moving forward

You don't have to write a script to get rid of them. The following command will do the job:

sudo apt --purge autoremove

Note, you have to run this command before Software Updates does its cleaning up.

Cleaning Up

As for the existing modules left behind, you will have to delete them manually, making sure you don't delete any module folders that are currently being used.

Use this command to find the list of installed kernels:

apt list --installed linux-image*

If Ubuntu has been removing old kernels then you should see two or three entries, including linux-image meta package linux-image-generic. Write down the kernel version numbers of the install kernels and make sure you don't delete the /lib/modules/ sub-folders for the installed kernels. Hope this helps

  • 1
    uname -r will tell which kernel release you're using right now; anything numbered differently will be eligible for removal dpkg --list | grep linux-image- | grep -v "$(uname -r)"will tell possible removal candidates, excluding the one currently in use. Note if there is a SINGLE hwe entry, you might consider to keep it, or the one matching your kernel if there are more than one.
    – Hannu
    May 4, 2022 at 17:19

Background Info

From the comments and @user68186's answer, I can now gather that the why implicitly follows the way apt works under the hood.

The module files in my question apparently falls under the category of config files, which means they are not removed with a normal apt autoremove, but only removed if you provide the --purge option.

However, especially for the Raspberry Pi (and possible other special architectures) those config files can at some point amount to gigabytes, if the system is running long enough with kernel updates.

So it's good to be aware of the sudo apt autoremove --purge option, which removes all previous kernel config files, including module configs.

Automated Kernel Management Tool

As indicated by @DougSmythies, there is an automated kernel management tool called linux-purge. I've tested this, and it seems to work well.

To install this utility, do the following (as root). This installs the script, the manpage and bash autocompletions.

$ wget https://git.launchpad.net/linux-purge/plain/update-linux-purge
$ chmod +x ./update-linux-purge && ./update-linux-purge

Now, you can use the utility with the command linux-purge, and its manual page is available with man linux-purge.

For instance, to purge all old kernels (that are not present inside /boot), run:

linux-purge -b

Ongoing Bug Report

Also, since the issue was reported on Ubuntu Discourse, a bug report has been opened to address this issue. Anyone interested can follow the progress there.

  • 1
    The command to run 'update-linux-purge' won't work as the file isn't in PATH, prefix './'
    – trash80
    Mar 17, 2023 at 15:45

for lazy bones like me. I created the file

cat /etc/apt/apt.conf.d/zz_purge 
APT::Get::Purge "true";
Binary::apt::Purge "true";

APT::Get::AutomaticRemove "true";
APT::Get::Purge-Unused "true";
Binary::apt::APT::Purge-Unused "true";
Binary::apt::APT::AutomaticRemove "true";

No matter if I use apt or apt-get and use autoremove my packages get purged. And when ever I install or remove a package; no longer needed packages get purged too.

  • Same here, I'd throw in 'APT::Install-Recommends "false";' to your list :) Mar 17, 2023 at 13:48

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .