The Ubuntu problem reporter now redirects to this bug whenever there's not enough space on the /boot partition to install a new version of the kernel. This has gotten much more common on systems set up since 2014, because Ubuntu now creates a small, separate /boot partition by default. On systems partitioned with earlier versions of Ubuntu /boot is part of a much larger / partition, so you may never run into this.

I've included my workaround to this problem, which I'm now using every couple of weeks when one or another of my Ubuntu systems gets into this state.

But I also want to disagree with the resolution proposed by the title of this bug. Even if the "fix" proposed in the title of this bug were implemented, it wouldn't solve the problem or even make it easier for less-technical users to get their systems working again.

Ubuntu must manage the set of kernels installed on the system. It must set up a /boot partition capable of holding the number of kernels it expects to see on a normal system. If /boot becomes full it must be able to identify and remove some old kernels. Expecting the end user to manage this means Ubuntu is unsuitable for non-technical users, and I think that goes entirely against Ubuntu's founding principles. Moreover, I don't know why even a technically-minded user would be satisfied with the current state of affairs. There's no reason why the package manager should get into a broken state every few weeks that requires human intervention to fix. These old kernels serve no purpose for the great majority of users, technical or not.

For those who are running into this for the first time, here's the workaround I use to fix this problem. Be very careful doing this; deleting the wrong thing can easily render your system unbootable. I use aptitude for package management, so you'll need to install it before you can do this (sudo apt-get install aptitude). At a command prompt:

$ aptitude search linux-image | grep ^i

This will produce a list of installed kernel images, which look like this:

i   linux-image-3.19.0-28-generic   - Linux kernel image for version 3.19.0 on 686
i   linux-image-3.19.0-30-generic   - Linux kernel image for version 3.19.0 on 686

You can delete all of them, except the most recent one and the one that's actually running, which may or may not be the same. The most recent one will be the last numbered one on the list. You can find out what's actually running by running this command:

$ uname -a
Linux gh-narcissus 3.19.0-30-generic #33-Ubuntu SMP Mon Sep 21 20:58:04 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

To delete the unused kernels, do this:

$ sudo aptitude purge linux-image-3.19.0-28-generic

You'll can list more than one image on this command line. Aptitude will warn you that it's going to remove linux-image-extra- packages with the same version numbers as the linux-image packages your purging. That's ok, but make sure the list doesn't include linux-image-generic (which will happen if you accidentally put the latest kernel version on the list).

This will sometimes fail, if /boot is completely full. In that case, I remove some of the boot files for the unused kernel images manually, and then run the aptitude purge command again:

$ sudo rm /boot/initrd.img-3.19.0-28-generic

Usually removing one or two is enough that the package manager will be able to run.