/boot fills up after many kernel upgrades

[Robert Hensing]

THIS ISSUE MAY PREVENT SECURITY UPDATES TO THE KERNEL.

Obsolete versions of the kernel remain installed on a system, causing a full /boot or wasting space on single-partition installations.
This has the effect that (some) software updates no longer work (at least those to the kernel):

update-initramfs: Generating /boot/initrd.img-3.2.0-29-generic

gzip: stdout: No space left on device
[...]
Errors were encountered while processing:
 initramfs-tools
E: Sub-process /usr/bin/dpkg returned an error code (1)

To resolve this, the user must figure out which packages to deinstall. A novice user will not know what to do.

[Jamie Strandboge (jdstrand)]

Thanks for taking the time to report this bug and helping to make Ubuntu better. We appreciate the difficulties you are facing, but this appears to be a "regular" (non-security) bug. I have unmarked it as a security issue since this bug does not show evidence of allowing attackers to cross privilege boundaries nor directly cause loss of data/privacy. Please feel free to report any other bugs you may find.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Shaun Crampton (fasaxc)]

Some thoughts on this bug:

When /boot does run out of space, it causes the next install of a kernel package to fail, leaving the package in a broken state as far as apt is concerned. That makes it impossible to remove the old kernel packages using apt: apt won't remove packages until you successfully run apt-get -f install to fix broken packages but apt-get -f install won't run until you remove the old packages.

That means that the only way to get things working again is to manually remove some old files from /boot, then run apt-get -f install and then apt-get remove to remove the old kernel packages. That's a real pain for a technical user like myself but it's impossible for a non-technical user.

This bug might not be a security vulnerability in its own right but it can certainly compound other security vulnerabilities. Being stuck with an unpatched kernel even though you have a cron job that does a sudo apt-get upgrade every night could be a big problem.

I suspect that more users will be affected by this bug but the lack of a clear error probably means that non-technical users just give up or ignore it.

[David White (cppege-david-9ei9ny)]

This is definitely a security risk, and also a usability problem. If we are updating kernels because of security fixes then surely a bug which prevents an update is perpetuating the security risk.

Also, this makes managing ubuntu servers and desktops a headache. Remember, Ubuntu is for humans and humans don't like headaches.

[Gordon (kmputerguy)]

When I installed 14.04 server it gave me the option to automatically install updates. I picked yes. I logged in a year later to find that my servers had installed three updates, then ran into this bug and stopped. In fact, kernel updates come out so often that half the time I try to install software apt is in a broken state because of this.

I could almost understand this kind of behaviour if having a cronjob do apt-get upgrade was a non-standard setup, but if it's an option in the installer? Unacceptable, and stupid.

A bug that completely breaks all security updates *should* be considered a security bug. If Microsoft made the same mistake we'd lose no time in mocking them for their insecure OS. Why should we hold ourselves to a different standard?

My suggestion for a fix would be to fix apt-get autoremove to skip the current running kernel. That way, autoremove can be triggered automatically right after update without worrying about screwing up the currently running kernel.

[spike speigel (frail-knight)]

bug # 1515513 is a contributing factor. DKMS has been patched upstream for that particular bug. Not sure when Ubuntu will update or incorporate the patch into their packaged version of dkms.

Are there any other files left behind after kernel updates that might cause these kinds of update problems? Are there different circumstances in which a file may or may not be deleted?

It affects every install that uses dkms and updates kernels in the long run.

This doesn't put any Linux distribution in a favorable light.

This bug eventually leaves the system in an insecure, unstable state.

And this has been happening since at least 2012 (that's when I first noticed updates failing due to lack of space in /boot). As others have stated, it is impossible to resolve manually for those who are not technical and just want to use the desktop. My father has actually had this happen on the Ubuntu install I set up for him.

I agree. I think it should be handled as a security issue with a higher priority.