There seems a lot of confusion in this bug report about which pieces of the system work together to cause this problem, and which pieces should be responsible for fixing it.
Marking kernels as eligible for autoremoval is done by apt. The apt package provides /etc/kernel/postinst.d/apt-auto-removal, which sets the rules for marking kernel packages eligible for autoremoval. If you discover a system that keeps more than three kernels (and isn't already broken), run 'apt autoremove' manually. If the system still has more than three kernels, then see if you can figure out why and then file a bug against Apt. But apt only marks. Apt doesn't actually pull the trigger and run an autoremove. Compounding the problem is another issue with apt: Apt in 16.04 and earlier queues autoremoval instead of running it first (or last...or scheduled). This is what makes broken systems harder to fix. Out-of- space hits before autoremove. Unattended-Upgrades prior to 16.04, if the option is enabled, merely runs 'apt autoremove' via aptdaemon. U-U does not check nor care what packages need to be removed. U-U does not check nor care if the system is LVM/Encrypted or has a small separate /boot partition. None of that is part of U-U's job. U-U developers in 16.04 addressed this problem (even though it's arguably not U-U's problem) by checking if packages are already marked eligible-for-autoremove at the beginning of the run. If so, it autoremoves them before doing anything else. Again, U-U doesn't care about which packages happen to be marked, or wheter the system has a small /boot partition. In 16.04, the problem is undeniably fixed. The additional functionality of U-U has prevented stale kernels from accumulating on all my test systems. However, developers have understandably shown little interest in backporting that particular fix. And there are other options to integrate the fix better into apt itself instead of U-U. For example, aptdaemon does seem to have queue management tools - it should be possible to move an 'autoremove' to the head of queue (incidentally making fixes much easier). Or we can add another kernel hook file to /etc/kernel/postinst.d/ to trigger an autoremove upon kernel installs (instead of U-U's daily check). Or we can add a startup/cron.daily service that simply checks for existence of a small /boot partition and runs autoremove before (or after) the daily apt update. Or we can have aptdaemon catch out-of-space errors (instead of simply passing them), run autoremove, and then try the install again. Almost none of these possible solutions would be implemented in Unattended Upgrades. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to unattended-upgrades in Ubuntu. https://bugs.launchpad.net/bugs/1357093 Title: Kernels not autoremoving, causing out of space error on LVM or Encrypted installation or on any installation, when /boot partition gets full Status in unattended-upgrades package in Ubuntu: Fix Released Bug description: Currently if one chooses to use LVM or encrypted install, a /boot partition is created of 236Mb Once kernel updates start being released this partition soon fills until people are left unable to upgrade. While you and I might know that we need to watch partition space, many of the people we have installing think that a windows disk is a disk and not a partition, education is probably the key - but in the meantime support venues keep needing to deal with the fact the partition is too small and/or old kernels are not purged as new ones install. For workaround and sytem repair, see https://help.ubuntu.com/community/Lubuntu/Documentation/RemoveOldKernels To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1357093/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
