1

There are several good answers here regarding how to fix problems caused by a full /boot partition. What I'd like to know is if there is any best practices for proactively managing this issue before it becomes a problem.

I routinely go many weeks and sometimes several months between reboots. The need to apply patches frequently is rarely an issue with Linux like it is with MS. If I didn't mind rebooting every few days I'd just run Windows.

I am running a small farm of Ubuntu 16.04 LTS machines. I added the following to one of them as a test:

sudo crontab -e

1 9 * * 2 apt -y autoremove --purge >> /dev/null

This runs a purge once a week which should be more than frequent enough. This does work although I did a manual purge before creating the cron job so there may be issues when there is actually something in there to purge. Like, will this command run to successful completion unattended in all situations? Any unforeseen unintended consequences of using this approach? Is there a better OOB management scheme? For supportability reasons I would prefer to avoid using custom scripts.

Many thanks in advance.

https://help.ubuntu.com/community/RemoveOldKernels specifically says that the following does NOT purge old kernels:

File: /etc/apt/apt.conf.d/50unattended-upgrades

Set: Unattended-Upgrade::Remove-Unused-Dependencies "true";

jones0610
  • 2,157
  • 1
    https://help.ubuntu.com/community/RemoveOldKernels – jarno Aug 15 '17 at 19:12
  • 1
    You can add the option -y to your apt command line (it worked when I checked although I did not find it in the manual man apt). – sudodus Aug 15 '17 at 19:40
  • @jarno If the wiki included a method to purge as well as generally clean up, that would be an ideal solution. IMHO, the default for these flags should be "true" not "false" especially considering how many people get on here complaining about problems caused by a full /boot condition. A directive structured in this manner would be an elegant best practices solution. – jones0610 Aug 15 '17 at 20:23
  • 2
    The best practice is not to have a separate /boot. ))) – Pilot6 Aug 15 '17 at 21:53
  • @Pilot6 A conversation to have with the Ubuntu Developers then. A tiny /boot partition is what you get when you build Ubuntu taking the defaults – jones0610 Aug 15 '17 at 22:00
  • If you don't use LVM or encryption, you don't have a separate /boot. – Pilot6 Aug 15 '17 at 22:09
  • Like many admins, I've fully encrypted my file systems for a very long time. – jones0610 Aug 15 '17 at 22:12
  • I agree with @Pilot6 100%. A separate boot is crazy. But the answer to the question would be a cron warning whenever /boot is less than 100 MB free. I'm a little biased towards cron as I just set it up to email me system status. Instead of cron startup application could be used. At the same time I would consider issuing a warning whenever / is > 80% full but that's a personal preference and not scientific. I would also use rm-kernels because I wrote it :) – WinEunuuchs2Unix Aug 16 '17 at 01:48
  • I don't disagree. And especially such a small /boot partition since it is clearly filling up fast and causing a lot of pain to new Ubuntu users. However, this is the way the installation is configured OOB, which is the way I built my machines. Since this is how the Developers, in their infinite wisdom, decided to set the defaults, I'm looking for a best practices management scheme that ideally does not require custom coding. Deviating from the standard, well hardened release defeats the logic of going with the LTS version of Ubuntu. – jones0610 Aug 16 '17 at 03:22
  • Even if it does not purge, it helps preventing /boot getting full. You could file a bug report to request purging. – jarno Aug 16 '17 at 21:44
  • Your script will fail, if the package package database is locked when it runs. E.g. if you are installing something else at the same time. – jarno Aug 16 '17 at 21:46
  • So the answer is that there is NO way to automatically, proactively prevent /boot from becoming full other than to reboot periodically (ala the Microsoft model) or remember to manually run autoremove on dozens of machines BEFORE it becomes a problem?!?!?! This is not especially sustainable or robust behavior. – jones0610 Aug 16 '17 at 22:27
  • 1
    Rebooting is needed for taking new kernel in use, not for removing old kernels. Unattended-upgrade can do rebooting automatically, if wanted. IIRC there is no difference in which kernel files are left in /boot when comparing purge to remove. But as for complete purging using cron, my linux-purge script could do it waiting package lock to release before purging. After I release the script, you will be able to file bug reports against it in Launchpad. https://www.bountysource.com/issues/38300038-feature-request-the-command-should-work-like-this – jarno Aug 17 '17 at 03:39

1 Answers1

2

You could use an adaptation of this one-liner I found somewhere on this site:

sudo dpkg --list | grep linux-image | awk '{ print $2 }' | sort -V | sed -n '/'uname -r'/q;p' | xargs sudo apt-get -y purge

It will remove and purge all kernels except the one you're currently using.

Jo-Erlend Schinstad
  • 29,531
  • Will this run unattended as a cron job? I'd want to keep the most recent kernel so that the machine will reboot to the latest kernel update. Does this command purge ALL kernels except the one currently running? – jones0610 Aug 15 '17 at 19:41
  • IIRC It's pretty much universally recommended to keep the current kernel version PLUS the one older than it. I think there is a one-liner script for that on this site too. – WinEunuuchs2Unix Aug 16 '17 at 02:22
  • It could purge new kernel packages and even stop updates. – jarno Aug 16 '17 at 21:50