[Bug 1808151] [NEW] Inadequate /boot space requirement estimation

[Mikkel Kirkgaard Nielsen]

Public bug reported:

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) ...

** Affects: ubuntu-release-upgrader (Ubuntu)
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to ubuntu-release-upgrader in
Ubuntu.
https://bugs.launchpad.net/bugs/1808151

Title:
  Inadequate /boot space requirement estimation

Status in ubuntu-release-upgrader package in Ubuntu:
  New

Bug description:
  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) ...

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1808151/+subscriptions