Well. that's probably because what I thought had happened had not happened.
Ubuntu likes to designate a too-small dedicated /boot partition which it then fills with kernels. (Or at one point it started doing this, in any case).
So it can quite quickly get a system to the state where there is no room for new kernels, even though there's plenty of room for updates, causing needless effective wastage of space (and an inability to apply new updates) as the kernel updates artificially exhaust the space on the small dedicated /boot partition.
But it looks like that actually was not the problem in this case.
54G should be enough room for lots of kernel updates.
Code:
sportwagon@ubuntu:~$ df -h /boot /
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 134M 68M 57M 55% /boot
/dev/mapper/CAC_VG-CAC_LV 38G 11G 26G 30% /
sportwagon@ubuntu:~$
And now, after a kernel update has been applied...
Code:
sportwagon@ubuntu:~$ df -h /boot /
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 134M 97M 28M 79% /boot
/dev/mapper/CAC_VG-CAC_LV 38G 11G 25G 31% /
sportwagon@ubuntu:~$
Note that /boot says "79%" (with 3 alternate kernels).
One more (new/alternate kernel) would fill that partition up, breaking the update partway through. This has happened to me on this system.
Sigh...
Code:
sportwagon@ubuntu:~$ sudo apt-get autoremove
[sudo] password for sportwagon:
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be REMOVED:
linux-headers-3.13.0-77 linux-headers-3.13.0-77-generic
linux-image-3.13.0-77-generic linux-image-extra-3.13.0-77-generic
0 upgraded, 0 newly installed, 4 to remove and 0 not upgraded.
After this operation, 271 MB disk space will be freed.
Do you want to continue? [Y/n] y
(Reading database ... 116716 files and directories currently installed.)
Removing linux-headers-3.13.0-77-generic (3.13.0-77.121) ...
Removing linux-headers-3.13.0-77 (3.13.0-77.121) ...
Removing linux-image-extra-3.13.0-77-generic (3.13.0-77.121) ...
run-parts: executing /etc/kernel/postinst.d/apt-auto-removal 3.13.0-77-generic /boot/vmlinuz-3.13.0-77-generic
run-parts: executing /etc/kernel/postinst.d/initramfs-tools 3.13.0-77-generic /boot/vmlinuz-3.13.0-77-generic
update-initramfs: Generating /boot/initrd.img-3.13.0-77-generic
run-parts: executing /etc/kernel/postinst.d/update-notifier 3.13.0-77-generic /boot/vmlinuz-3.13.0-77-generic
run-parts: executing /etc/kernel/postinst.d/zz-update-grub 3.13.0-77-generic /boot/vmlinuz-3.13.0-77-generic
Generating grub configuration file ...
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-3.13.0-83-generic
Found initrd image: /boot/initrd.img-3.13.0-83-generic
Found linux image: /boot/vmlinuz-3.13.0-79-generic
Found initrd image: /boot/initrd.img-3.13.0-79-generic
Found linux image: /boot/vmlinuz-3.13.0-77-generic
Found initrd image: /boot/initrd.img-3.13.0-77-generic
Found memtest86+ image: /memtest86+.elf
Found memtest86+ image: /memtest86+.bin
done
Removing linux-image-3.13.0-77-generic (3.13.0-77.121) ...
Examining /etc/kernel/postrm.d .
run-parts: executing /etc/kernel/postrm.d/initramfs-tools 3.13.0-77-generic /boot/vmlinuz-3.13.0-77-generic
update-initramfs: Deleting /boot/initrd.img-3.13.0-77-generic
run-parts: executing /etc/kernel/postrm.d/zz-update-grub 3.13.0-77-generic /boot/vmlinuz-3.13.0-77-generic
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-3.13.0-83-generic
Found initrd image: /boot/initrd.img-3.13.0-83-generic
Found linux image: /boot/vmlinuz-3.13.0-79-generic
Found initrd image: /boot/initrd.img-3.13.0-79-generic
Found memtest86+ image: /memtest86+.elf
Found memtest86+ image: /memtest86+.bin
done
sportwagon@ubuntu:~$ df -h /boot /
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 134M 68M 57M 55% /boot
/dev/mapper/CAC_VG-CAC_LV 38G 11G 26G 30% /
sportwagon@ubuntu:~$
sportwagon@ubuntu:~$ sync
sportwagon@ubuntu:~$ sync
sportwagon@ubuntu:~$ sync
sportwagon@ubuntu:~$ sudo reboot
In summary, you are not exhibiting the problem I referred to.
Though my cloud server (above) still is.
It's not impossible that they changed the default filesystem layout between the two times you did your installation.
The reason for creating the condition is to arrange that your kernels can be on a bootable filesystem while most of your software and other files (root filesystem) is on a spiffy new filesystem from which you cannot boot. For most users the spiffiiness of the new filesystem does not justify the inconvenience in applying updates. (Though, in reality, you only very rarely need more than one backup version of kernel, so the encouraged "good housekeeping" is overall not a bad thing).