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
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1808151
Title:
Inadequate /boot space requirement estimation
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1808151/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
