61

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?

BlueBomber
  • 757
  • 3
    possible duplicate of Why doesn't Ubuntu remove old kernels automatically? – Martin Schröder Jun 11 '15 at 08: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 https://bugs.launchpad.net/bugs/1357093 for a patch to unattended-upgrades that will begin removing old kernels automatically. – user535733 Dec 31 '15 at 18:10

3 Answers3

44

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.

Update:

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" ]
then
        # We have at least two kernels that we have reason to think the
        # user wants, so don't save the second-newest version.
        previous_version=
fi

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:

    APT
    {
      NeverAutoRemove
      {
            "^firmware-linux.*";
            "^linux-firmware$";
      };
  VersionedKernelPackages
  {
        # linux kernels
        "linux-image";
        "linux-headers";
        "linux-image-extra";
        "linux-signed-image";
        # kfreebsd kernels
        "kfreebsd-image";
        "kfreebsd-headers";
        # hurd kernels
        "gnumach-image";
        # (out-of-tree) modules
        ".*-modules";
        ".*-kernel";
        "linux-backports-modules-.*";
        # tools
        "linux-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

Wil
  • 805
Sergiy Kolodyazhnyy
  • 105,154
  • 20
  • 279
  • 497
  • 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 '14 at 00:28
  • Just updated the answer, check it out – Sergiy Kolodyazhnyy Dec 20 '14 at 00:43
  • 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) – Sergiy Kolodyazhnyy Dec 20 '14 at 00: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. – Peter Cordes Apr 11 '15 at 09:41
  • I'm wondering if maybe aptitude has its own don't-remove-kernels logic, because my autogenerated 01autoremove-kernels only lists the current and previous (-33 and -34), but -31 was still not getting autoremoved. – Peter Cordes Apr 11 '15 at 09:44
  • Oh, just realized maybe I need to restart aptitude after /etc/kernel/postinst.d/apt-auto-removal rewrites 01autoremove-kernels during the postinst of the newest kernel, installed by the currently-running aptitude. – Peter Cordes Apr 11 '15 at 09:44
  • Update: aptitude has its own never-remove-old-kernels logic, and I don't know where that's configured. Things are configured so apt-get autoremove will remove all but the current and previous kernel packages, though, and that does work. – Peter Cordes Jul 27 '15 at 19:40
  • I have the same issue but with linux-headers. Commenting out #"linux-headers"; in /etc/apt/apt.conf.d/01autoremove didn't work. Does anyone has any suggestions? e.i. apt-get autoremove works on kernels but not headers for some reason... – direwolf Sep 10 '15 at 07:04
  • 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 '15 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 '15 at 13:55
  • /etc/apt/apt.conf.d/01autoremove does not actually remove anything. It merely identifies packages as eligible for autoremoval. Somebody else (the user, unattended-upgrades, cron job, whatever) must still pull the trigger and run autoremove. – user535733 Dec 31 '15 at 18:13
  • I'm wondering when the /etc/kernel/postinst.d/ scripts run. My case was a failed kernel install because there wasn't enough disk space to build the ramdisk. I couldn't autoremove my older kernels (ended up removing them by hand), perhaps because the scripts didn't run after the failed install. – Brent Baccala Dec 20 '19 at 16:10
13

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.

jarno
  • 5,600
1

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.

null
  • 1,351