Looking at /boot, this is seen:
me@machine:/boot$ df -h /boot
Filesystem Size Used Avail Use% Mounted on
/dev/sda5 703M 383M 269M 59% /boot
If this size is 703M, used = 383M, and available is 269M, where is the 703-(383+269) = 51 M left? The 'Use%' seems to be based on the 383/(383+269) value.
It seems the only way to update the kernel is to delete the older version manually (i.e., sudo apt purge linux-image-5.15.0-83-generic) as it seems my system can only have the current kernel plus the last previous one. Once this is done, and update can run normally, and the kernel can update.
My guess is that if there was enough room, the system could be updated without this manual step. The -83 and -86 kernel initrd.img files seem to be about 178M, and the vmlinuz files are about 11M, so on casual inspection, this is less than the 269M available (unless some room is needed to update things).
A quick search turns up this answer, on why this disk size discrepancy happens:
df -h - Used space + Avail Free space is less than the Total size of /home
By using 'sudo tune2fs -m 0 /dev/sda5', this would make this 5% buffer 0.
A 'sudo tune2fs -l /dev/sda5' turns up 9356 reserved blocks, with a block size of 4096, that's ~38M.
Is using the '-m 0' still a valid option? The original answer is 10 years old, and didn't know if there were any caveats.
That 51M missing on 703M appears like 7.2%, not 5%, but the block counts returned from tune2fs -l (Block count=187136, reserved block count=9356) do yield 5% (9356/187136). Block size is 4096.
When updating a kernel, how much room do you need anyway?
n.b. One solution is to change compression to xz in initramfs.conf, as seen here: problem updating
