I've already increased the default size for /boot to ~512M (tends to actually end up being a little less, but it's already much more than the 240ish it was). There's a couple of reasons for it: when installing on EFI (because this tends not to affect non-EFI installs at all), one has to count every kernel as twice its non-EFI size (once for the unsigned kernel, once for the signed kernel), and we're very close to filling the partition with the number of kernels we need to support upgrades and everything.
For example, on my system: /dev/sda2 237M 131M 94M 59% /boot This is after having to do an upgrade that bit me with a low-space warning, and a subsequent update failure because of lack of space -- I manually removed all kernels but the last two manually, and completed the upgrade: [13:04:42] mtrudel@demeter:/boot $ du -hs * 2>/dev/null 1,2M abi-4.4.0-11-generic 1,2M abi-4.4.0-13-generic 186K config-4.4.0-11-generic 186K config-4.4.0-13-generic 512 efi 7,7M grub 37M initrd.img-4.4.0-11-generic 38M initrd.img-4.4.0-13-generic 9,7M initrd.img-4.4.0-7-generic 12K lost+found 180K memtest86+.bin 182K memtest86+.elf 182K memtest86+_multiboot.bin 3,7M System.map-4.4.0-11-generic 3,7M System.map-4.4.0-13-generic 6,8M vmlinuz-4.4.0-11-generic 6,8M vmlinuz-4.4.0-11-generic.efi.signed 6,8M vmlinuz-4.4.0-13-generic 6,8M vmlinuz-4.4.0-13-generic.efi.signed There are two gotchas to this: efi space must not be counted as it's on the ESP, which is separate from /boot, and it looks like part of the issue with removing old kernels may be the handling of initrds (there is an extra initrd for 4.4.0-7). As for small disks, partman-auto should already handle them through its priority value for /boot. We're slightly more than at 59% of the size of the partition, and with a third kernel we'd come up to about 169,5 M (71%), which is still a fair way from 237 M. Adding a fourth kernel would make it to 226 M (95%), which is where we end up in a situation that becomes uncomfortable. That said, initrds varied a fair amount between kernel versions on my own system, and I have no trouble believing they might vary even more between installs on different systems, and you need to account for at most three times the size of the average initrd while processing updates to it (ie. once for the old initrd, once for a backup, and once more for the new one being written, which will likely grow at least to the same size as the old one. On my system, this means a kernel update or update to some package requiring an initramfs update will require about 111M more to update old kernel initramfs, and obviously less when installing a new kernel). For a 240G SSD; installing Desktop now hands me a 473M /boot partition, which seems like a good improvement (35% usage with 3 kernels, with the initrd sizes I have listed above). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1465050 Title: Size of /boot partition is too small To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1465050/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
