Inadequate /boot space requirement estimation

[Mikkel Kirkgaard Nielsen]

Yesterday I experienced a "no space available" condition on /boot during do-release-upgrade of a server from trusty to xenial.

Excerpt from the apport log (it contains somewhat sensitive information so It'll need cleaning to be disclosed):

 Sætter linux-image-extra-4.4.0-140-generic (4.4.0-140.166) op ...
 run-parts: executing /etc/kernel/postinst.d/apt-auto-removal 4.4.0-140-generic /boot/vmlinuz-4.4.0-140-generic
 run-parts: executing /etc/kernel/postinst.d/dkms 4.4.0-140-generic /boot/vmlinuz-4.4.0-140-generic
 run-parts: executing /etc/kernel/postinst.d/initramfs-tools 4.4.0-140-generic /boot/vmlinuz-4.4.0-140-generic
 update-initramfs: Generating /boot/initrd.img-4.4.0-140-generic
 cat: skrivefejl: Ikke mere plads på enheden
 update-initramfs: failed for /boot/initrd.img-4.4.0-140-generic with 1.
 run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1
 dpkg: fejl under behandling af pakken linux-image-extra-4.4.0-140-generic (--configure):
  underproces installerede post-installation-script returnerede afslutningsstatus 1

Translations from Danish:
"Sætter <package> op ..." = "Setting up <package>"
"skrivefejl: Ikke mere plads på enheden" = "write error: No space available on device".

Before do-release-upgrade was satisfied to commence with the upgrade I had to free space on /boot manually. I did this by explicitly removing old kernels using dpkg -r, because apt-get autoremove wanted to upgrade to a new 3.13.0-163 kernel (system was running 126) before removing old ones, which it couldn't. Afterwards I assured that only files related to the current 126 and the previous 125 kernel was present in /boot, by removing all other image packages and manually removing some initrd (maybe others also) files relating to those still present in /boot.

Even though the release upgrade was now satisfied to continue it still failed during the initrd generation for the kernels because of too little space available on /boot.

Subsequent inspection of /boot showed the new vmlinuz-4.4.0-140 kernel was installed but the initrd was obviously missing. Still there were now files related to older 3.13.0-{105,107,128,129} kernels which had somehow been generated during the upgrade. I removed those files again (several ~8 MiB initrd files, a full initrd also for 3.13 is >30 MiB) and also the now installed 163 kernel which freed enough space to let "apt upgrade" configure the new kernel and generate an initrd.
I am a bit puzzled by the older kernels still having files generated in /boot. The system had linux-headers packages installed for some of those but I guess this shouldn't be enough to warrant space being used in /boot? At least after a normal upgrade cycle they are still not back (header packages still being installed) but this could in theory be handled different from the release-upgrade.

I can see from https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/1646222 that some changes were done to the estimation algorithm in 2016/2017 to lower its estimates. Just to confirm what version the system was running during release-upgrade the apt log show that last upgrade of python3-distupgrade was at 2017-06-29 to 1:0.220.9:

Log started: 2017-06-29 13:52:42
Gør klar til at udpakke .../python3-distupgrade_1%3a0.220.9_all.deb ...
Udpakker python3-distupgrade (1:0.220.9) over (1:0.220.8) ...