My boot partition is on a SSD, so it doesn't have room for more than about 8 installed kernel versions, and eventually some kernel update will fail to install because my boot partition is full of old versions. There are many questions out there about how to remove old versions (even how to automate the process), but my question is simply this: Why doesn't apt-get autoremove detect and remove them automatically, and is there a way I can make it do so? I mean, apt-get is what installed them anyway, so it knows about them, so why does it choose to leave all old versions around?

  • 3
    possible duplicate of Why doesn't Ubuntu remove old kernels automatically? Jun 11, 2015 at 8:27
  • 1
    Autoremove does remove old kernels under most circumstances. Kernels accumulate because the system does not run autoremove automatically by default. That's a setting in unattended-upgrades, and can be changed. Autoremove cannot remove old kernels when previously-queued apt actions (like installing a new kernel) fail (due to insufficient space). See bugs.launchpad.net/bugs/1357093 for a patch to unattended-upgrades that will begin removing old kernels automatically.
    – user535733
    Dec 31, 2015 at 18:10

3 Answers 3


As to answer why , refer to the file /etc/apt/apt.conf.d/01autoremove-kernels

enter image description here

As you can see, apt is told to never autoremove the kernels , as told by another (script) file, /etc/kernel/postinst.d/apt-auto-removal. And here it is:

enter image description here

If you manually install 2 chosen kernels, ie the first and the current one, then apt-autoremove will only ever remove the older versions you didn't manually install, so you will always have those 2 options plus whatever the latest one is.


In the /etc/kernel/postinst.d/apt-auto-removal there is this part:

if [ "$latest_version" != "$installed_version" ] \
   || [ "$latest_version" != "$running_version" ] \
   || [ "$installed_version" != "$running_version" ]
        # We have at least two kernels that we have reason to think the
        # user wants, so don't save the second-newest version.

So if you compare the output of 01autoremove-kernels file and uname -r you'll realize that the currently running kernel and the most recent before it, are kept to be never removed by that script. There turns out is another file /etc/apt/apt.conf.d/01autoremove, where there is lines:

        # linux kernels
        # kfreebsd kernels
        # hurd kernels
        # (out-of-tree) modules
        # tools

So you could comment these out, and it will allow you to auto-remove the kernels with apt-autoremove, though remember - do this at your own risk

  • 2
    Very interesting! My /etc/apt/apt.conf.d/01autoremove-kernels has many lines, but only two versions among all of them: 3.13.0.{39,43}. But dpkg -l linux-* lists four versions, 3.13.0.{39,40,41,43}, so something other than /etc/apt/apt.conf.d/01autoremove-kernels is keeping those middle versions around, right?
    – BlueBomber
    Dec 20, 2014 at 0:28
  • 1
    TL:DR : 01autoremove is the file you want, 01autoremove-kernels is probably just a protection, so that apt doesn't remove currently installed kernel and most recent (just in case newest screws up) Dec 20, 2014 at 0:46
  • 1
    Unless I'm misreading 01autoremove, it's just protecting against auto-removal of the dependency packages, like linux-image-extra. Changing it shouldn't affect whether or not linux-image-3.16.0-31-generic gets autoremoved. None of the patterns in it match the package names that we want auto-removed. Apr 11, 2015 at 9:41
  • 1
    @PeterCordes Don't remove or comment lines in /etc/apt/apt.conf.d/01autoremove. That does not help you in autoremoving old versioned kernel packages, but may have unwanted effects. The file does not protect from autoremoving linux-image-extra but packages that match regular expressions in the NeverAutoRemove section.
    – jarno
    Dec 24, 2015 at 12:51
  • 2
    @BlueBomber, the reason why apt-get autoremovedoes not remove the kernels not listed in /etc/apt/apt.conf.d/01autoremove-kernelsis that those kernels are marked as manually installed; see my answer.
    – jarno
    Dec 26, 2015 at 13:55

For me it helped to install latest (X)ubuntu (15.10). In earlier releases kernel packages may be marked as manually installed, at least, if installed by using Software Updater, so that sudo apt-get autoremove --purge can't delete them. There are bug reports concerning the issue: Bug #1175637, Bug #1439769

In earlier release, you could try to mark kernel packages automatically installed by sudo apt-mark auto $(apt-mark showmanual | grep -E "^linux-([[:alpha:]]+-)+[[:digit:].]+-[^-]+(|-.+)$") and run sudo apt-get autoremove --purge thereafter to see, if it makes difference. The command should still not remove kernels packages shown in /etc/apt/apt.conf.d/01autoremove-kernels, but it is safest to run apt-get autoremove with --dry-run option first.

Alternatively, you could use linux-purge to purge old kernels even more selectively or even if they were manually installed.

  • Oh, the autoremove command tend to remove too many kernels, see Bug #1440608
    – jarno
    Dec 24, 2015 at 18:54
  • 2
    the apt-mark did the trick for me, wish I could upvote 10 times :P Feb 27, 2018 at 17:31

Try removing the old kernel packages first, but if the /boot/initrd.img files remain, then this worked for me:

To remove /boot/initrd.img-4.8.0-39-generic

sudo update-initramfs -d -k 4.10.0-37-generic

Remove one initrd.img file at a time.

You must log in to answer this question.

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