Ask Ubuntu is a question and answer site for Ubuntu users and developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

For security purposes I've been a fan of unattended-upgrades, Using something like this:

Unattended-Upgrade::Allowed-Origins {
        "Ubuntu lucid-security";

Unattended-Upgrade::Package-Blacklist {

Unattended-Upgrade::Mail "";

Unattended-Upgrade::Automatic-Reboot "false";

However, I've just spent most of the day recovering from a situation. I think the root cause were:

  • The /boot partition had filled up with a series of about 20 kernels.
  • The most recent kernels on the boot menu may in fact never have been used

I've seen a post about a command to clean up old kernels, But would much prefer a built-in feature.

I'am happy with automated updates, But what do others recommend for:

  • clearing of the old kernels
  • arranging an automated reboot when required (at a configured time like 3am

And should this stuff not be part of unattended-upgrade?

share|improve this question

In reply to your very last question--I'm not sure why people recommend a separate partition for /boot but I've seen at least one other question here in the last couple of days from someone who's /boot partition had been filled with old kernels and it had caused a problem.

I'd suggest that you not automatically install kernels. It's not that they fail often, or that they fill up /boot, but because if you get an update that is incompatible with your hardware you won't know it until your system won't boot. If you are like me you may not remember, days or weeks later, e-mail or not, that the cause might be a new kernel. I'd exempt kernels, grub, and perhaps lightdm or gdm and xorg, at least.

For safety sake I think somethings should happen with human intervention.

There's a big dose of personal preference to all this, however, so YMMV indeed.

share|improve this answer
These servers have a 288MB /boot because that's what Lucid server install created - it's just easier to go with the defaults. Yes there are risks with auto-installing kernels, but then they're only coming down to fix know security holes so its seems reasonable. These are on VMWare, so hardware incompatibilities don't seem likely. – snori74 May 23 '12 at 6:03
Aha! I've just realized that it's because I choose LVM that the installer defaults to setting up a separate /boot. Although LVM can be quite a pain at times, the expand-the-disk-on-the-fly thing is very handy in a VMware environment for important servers. – snori74 May 23 '12 at 7:10

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.