Size of /boot partition is too small

Bug #1465050 reported by Rod Smith on 2015-06-14
122
This bug affects 23 people
Affects Status Importance Assigned to Milestone
ubiquity (Ubuntu)
Undecided
Mathieu Trudel-Lapierre
Xenial
Undecided
Mathieu Trudel-Lapierre

Bug Description

When using a partitioning option that requires the use of a /boot partition (such as LVM), Ubiquity (in Ubuntu 15.04) creates a rather small /boot partition -- 244MiB in my test:

GPT fdisk (gdisk) version 0.8.10

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sda: 95509824 sectors, 45.5 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 6620D692-A7C3-4054-BD03-C37233564AEA
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 95509790
Partitions will be aligned on 2048-sector boundaries
Total free space is 3325 sectors (1.6 MiB)

Number Start (sector) End (sector) Size Code Name
   1 2048 1050623 512.0 MiB EF00
   2 1050624 1550335 244.0 MiB 8300
   3 1550336 95508479 44.8 GiB 8E00

Although this is adequate for the initial installation, it leaves very little space for expansion. On my test installation, it was 40% full (90MiB used) immediately after installation, with two kernels installed (one of which also had a ".efi.signed" variant installed).

The small size of the /boot partition has been causing problems "in the wild," as illustrated by some askubuntu.com questions:

http://askubuntu.com/questions/142926/cant-upgrade-due-to-low-disk-space-on-boot
http://askubuntu.com/questions/89710/how-do-i-free-up-more-space-in-boot
http://askubuntu.com/questions/298487/not-enough-free-disk-space-when-upgrading

I recommend increasing the default size of a separate /boot partition to approximately 500MiB; that's normally been adequate for me.

Other possible fixes (which I'd implement in addition to a /boot partition size increase, not instead of it) include removing the non-signed kernel when a signed one is installed and automatically removing older kernels when an upgrade is installed. These would require changes to package management rather than Ubiquity, of course.

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in ubiquity (Ubuntu):
status: New → Confirmed
Paul Gear (paulgear) wrote :

I've unmarked this as a duplicate of bug 1357093, because even if automatically installed kernels are auto-purged, 256 MB is still only enough space to install approximately 4 kernels. For those testing different kernels in order to track down bugs, this isn't large enough.

Nicolas Dietrich (nicodietrich) wrote :

It'd be great to fix that before the next iteration of LTS releases!

Brian Murray (brian-murray) wrote :

It's actually gotten to the point on Xenial where I couldn't install a third kernel.

Changed in ubiquity (Ubuntu Xenial):
assignee: nobody → Mathieu Trudel-Lapierre (mathieu-tl)
Thomi Richards (thomir) wrote :

@cyphermox: I don't mind preparing a patch for this, but after looking at the ubiquity codebase I'm at a loss to find where the partition sizes are encoded. Any hints?

Steve Langasek (vorlon) wrote :

> 256 MB is still only enough space to install approximately 4 kernels. For those testing
> different kernels in order to track down bugs, this isn't large enough.

I disagree. The common case only requires room for three kernels (we're supposed to always keep two kernels, so we need room for those two plus a third one being upgraded to before the old one is removed). I don't see any reason to make this partition larger to accommodate particular debugging scenarios -

Steve Langasek (vorlon) wrote :

> 256 MB is still only enough space to install approximately 4 kernels. For those testing
> different kernels in order to track down bugs, this isn't large enough.

I disagree. The common case only requires room for three kernels (we're supposed to always keep two kernels, so we need room for those two plus a third one being upgraded to before the old one is removed). I don't see any reason to make this partition larger to accommodate particular debugging scenarios - you only ever boot one kernel at a time, you don't need to have all possible kernels involved in debugging unpacked on the system at the same time.

However, if the partition is now too small to accommodate even 3 kernels in xenial, that's a major problem that needs addressing ASAP.

Stuart Bishop (stub) wrote :

Per Bug #1553442, the default partition size was too small on a fresh Xenial install with no kernel debugging being done. The updates failed after a week, probably as an update pulled in two kernels and there was not enough disk space to remove the oldest. It certainly seems far too tight to support over the lifespan of an LTS release.

Steve Langasek (vorlon) wrote :

The lifespan of the release is not part of the equation. You only need room for three kernels to support updates. If kernels aren't being auto removed correctly (which hasn't been mentioned here), there is no partition size large enough to accommodate unbounded growth.

If the kernel images / initrds themselves have gotten bigger, or if the partition sizing doesn't account for the signed kernel image, we should make sure the partition is sized appropriately for current kernels.

Steve Langasek (vorlon) wrote :

And that duplicate bug report shows four kernels installed. That means old kernels have not been removed. We do not currently have anything in update-manager to correctly auto remove packages after update. This is a serious (and known) bug. But increasing the size of /boot is no solution for it.

Paul Gear (paulgear) wrote :

@vorlon, perhaps it was not clear enough from previous comments on this bug, but some of us *want* to be able to install more than 4 kernels for testing purposes, and asking for a larger (or better yet, customisable) /boot is a perfectly reasonable thing to do, especially given the sizes we're talking about relative to the size of modern hard disks.

This bug was previously tagged as a duplicate of the lack of kernel autoremove, and but they're not the same thing, and should not be conflated.

On Sat, Mar 12, 2016 at 03:47:40AM -0000, Paul Gear wrote:
> @vorlon, perhaps it was not clear enough from previous comments on this
> bug, but some of us *want* to be able to install more than 4 kernels for
> testing purposes, and asking for a larger (or better yet, customisable)
> /boot is a perfectly reasonable thing to do, especially given the sizes
> we're talking about relative to the size of modern hard disks.

Customizing the size of your /boot partition is already possible in
ubiquity. This bug report is saying that the *default* size of the /boot
partition is too small.

I haven't verified whether it is or isn't too small for the default use case
in xenial, though Brian's comment #5 indicates that it is too small. But
that has nothing to do with supporting the install of "more than 4 kernels
for testing purposes".

> This bug was previously tagged as a duplicate of the lack of kernel
> autoremove, and but they're not the same thing, and should not be
> conflated.

Ok, so maybe you want to mark bug #1553442 as a duplicate of the *other*
bug, since Stuart's symptom is definitely a result of the lack of
autoremoval.

Paul Gear (paulgear) wrote :

> Customizing the size of your /boot partition is already possible in
> ubiquity. This bug report is saying that the *default* size of the /boot
> partition is too small.

Has that changed since the release of utopic? Because when I installed this laptop it was certainly not possible to do so and still use LUKS encryption, without jumping over some fairly significant hurdles.

From memory, the workaround steps to get a larger /boot were:
- create preferred partition setup using a server install ISO
- boot using the desktop ISO
- manually enable the encrypted LVM VG
- run the installer and tell it to use the existing partition setup
- boot from the server CD again, run recovery, and reconfigure the initrd to include encryption support

There may have been an easier way to do this, but all the ways I tried based on the server ISO ended up with non-working graphics, and the desktop ISO resulted in a unbootable system due to missing encryption support.

Rod Smith (rodsmith) wrote :

It's possible to customize the size of the /boot partition on a Desktop system by using the (poorly-named, IMHO) "Something Else" partitioning option; however, this also requires explicitly setting up all other partitions. This can be a rather high hurdle for inexperienced users. Of course, such users aren't likely to understand the subtleties of partition sizing requirements in the first place, which comes back to the default sizing of the partition.

Although fixing bug #1357093 will go a long ways toward avoiding this problem, I believe that a reluctance to increase the default size of /boot is misplaced. I *STRONGLY* disagree with Steve's comment that "the lifespan of the release is not part of the equation" -- because resizing partitions is a non-trivial task, the possibility of changing needs over the lifespan of an installation is *EXTREMELY* relevant. A sudden increase in the size of kernels or a need to install some new big files (maybe something related to GRUB) in /boot could render a formerly adequately-sized partition inadequate. There are also questions of supporting reasonable uses that aren't typical, such as extra debugging kernels or even locally-compiled kernels. Thus, we're looking at a question of adequate safety margins. To some extent this is a judgement call, but it appears to me that the current size (244 MiB when I filed this bug report, at least on my test system) is now inadequate. Doubling that size would provide enough breathing room that anybody wanting a still larger size could reasonably be expected to perform manual partitioning. I have yet to hear a good argument AGAINST raising the default size of /boot -- even a small modern SSD is likely to be ~100 GB, so a ~500 MB /boot would be about 0.5% of total disk space. If there's a concern about installation to truly tiny media like USB flash drives, perhaps that should be a special case in which the size of /boot is reduced, but for the vast majority of installations, increasing the default size of /boot to ~500 MB has NO disadvantages and considerable advantages. (Also, if tiny USB flash drives are a concern, remember that this issue affects installations that use a separate /boot -- mainly LVM, RAID, and encrypted installations. It's doubtful that LVM or RAID would have much benefit on a USB flash drive, although encryption might be.)

Thomi Richards (thomir) wrote :

Hi,

I'm not interested in testing kernels, but have found that the default size of the /boot partition is not large enough for three kernels to be installed at the same time. This causes upgrades to fail, and requires manual intervention before they can proceed. This is clearly not what we want to inflict on our users.

Thomi Richards (thomir) wrote :

Any news on this? If the fix is simple to do, I don't mind doing the fingerwork, especially if someone can point me in the right direction.

Cheers,

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).

Changed in ubiquity (Ubuntu Xenial):
status: Confirmed → Fix Released
Thomi Richards (thomir) wrote :

Thanks Mathieu!

Remind me to buy you a drink if we're ever at the same sprint again.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers