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

Reply via email to