/boot disk partition size

Mon Feb 21 22:44:14 UTC 2022

Hi Brian:

First, let me state the title of the bug I filed was unfortunate and I’ve
changed it accordingly. The body of the request shows that it is a proposal
to increase the /boot partition size, but the title sounded demanding.
Also, the file sizes were ambiguous. I have updated them both.

https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1960089

> A consequence of Ubuntu being open and customizable is that users can do
many things that are not ones that we endorse.

Agreed, but I believe Ubuntu should support multiple kernels for a few
reasons:

1. We agree that the outcome of an overfull /boot partition can be
catastrophic for less-than-expert users. It seems, therefore, that the
system should help avoid this situation commiserate with its potential cost.

2. There are no obvious mechanisms to guide novice users with kernel
management. Unless I’m missing something (always a possibility) there is no
system that actively monitors the /boot partition *size* and warns users of
filling disk (impending doom?). We did this (see
https://kfocus.org/wf/tools#kclean) but we don’t know if or when this will
be upstreamed.

3. Users install different kernel flavors for many legitimate workflows.
Three examples immediately come to mind: 3.1) People who do low-latency A/V
work frequently switch between the generic-hwe and lowlatency-hwe kernels;
3.2) The community often encourages users to explore different kernel
flavors to improve hardware support; and 3.3) Developers switch to stock
generic to test for deployment, then back to a later kernel, like hwe or
oem, for better hardware support.

> We are all in agreement that the /boot partition size needs increasing

Agreed, and the increase you have made to 1.5G is much better.

> For us to move forward in the discussion about increasing it to 2G it
would really help for you to answer my previous questions regarding the use
cases for having multiple kernels installed.

>> I’d really like more information on the use case where multiple kernel
flavors will be installed. You mention switching from HWE to OEM, given
that this is a switch wouldn’t the HWE kernel be removed and then you are
left with just one flavor of kernel?

Kernel packages rarely replace one another and so it is trivial to install
generic (stock), generic-hwe, lowlatency-hwe, oem-20.04d, and others
concurrently. This is a welcome feature as discussed in (3) above.

The calculations provided in
https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1960089 suggest
that Ubuntu should support up to three flavors at once. For example, a user
may have generic-hwe, lowlatency-hwe, and a third kernel flavor for
hardware support (oem-20.04d) or deployment testing (linux-generic).

If we agree that supporting 3 concurrent kernel flavors is good, then what
is a reasonable space requirement? During an upgrade, the /boot partition
is first filled up with new package files before any cleanup by autoremove
or unattended-upgrades can occur. Also, Ubuntu often updates multiple
kernel flavors on the same day. For example, generic-hwe and
lowlatency-hwe are almost always released concurrently. Thus, we can
reasonably assume there will be times when the /boot partition will need to
accommodate the files for 3 flavors and 2 versions each. The total,
therefore, is 2 x 3 = 6 kernels.

We have found the files in /boot take over 180MiB for each kernel for a
system with Nvidia hardware. Rounding up to 200MiB to accommodate for
future growth, we get 6 x 200MiB = 1.2GiB minimum. Add space for 4
additional kernel images as a safety factor and we get 2.0GiB.

One might ask if maintaining room for 4 extra kernels is a reasonable
safety factor, and that’s a fair question. Here are some edge cases to
consider that can keep additional kernel images around: a) The running
kernel package is never removed (see
/etc/apt/apt.conf.d/01autoremove-kernels) which could keep an extra kernel;
b) A metapackage has been constructed to transition to newer flavor (for
example, upgrading oem-20.04c to oem-20.04d); c) The system has not had a
cleaning event occur for a while and kernel packages have accumulated. My
feeling is this safety factor is warranted given how expensive recovery is
for most users.

I hope you find that useful, Brian, and thank you for your consideration.

Sincerely, Mike

On Mon, Feb 21, 2022 at 12:19 PM Brian Murray <brian at ubuntu.com> wrote:

> On Tue, Feb 15, 2022 at 10:47:59PM -0800, Michael Mikowski wrote:
> > Hi Everyone:
> >
> > Aaron: On an encrypted Ubuntu system, the EFI partition mounted on
> > /boot/efi is 512M too. But here we are talking about the /boot partition
> > which is distinct. It is typically 705M and formatted with ext4, although
> > subsequent released will likely be larger. The question here is by how
> much.
> >
> > We have offered this suggestion as means  to move a proven solution
> > component upstream for the benefit of everyone using 22.04. We
> implemented
> > an enlarged /boot partition and improved kernel management and cleaning
> > over a year ago because our customers needed it. See the support cost
> > calculations below about why we moved quickly when this became an issue.
> We
> > expected to see much more of if we didn't take action. The problem was
> made
> > more urgent by a packagekit bug.
> >
> > Using an additional 0.5% (1.295G costing < $0.25) of a 250G NVMe drive
> is a
> > very small price to pay to help avoid a catastrophic failure mode from
> > which most users cannot recover.
>
> When interviewing candidates for positions at Canonical I've had the
> opportunity to speak to Ubuntu users from around the world. Sometimes
> these are people who installed Ubuntu on whatever system they had lying
> around and they weren't in a position to buy a new PC or drive. So while
> the additional space in /boot might cost $0.25 for you, the cost for
> other people may be much greater. When developing Ubuntu we need to take
> into consideration the fact that our users are located in a variety of
> different countries and subsequently have access to different resources.
>
> > And users *do* install multiple kernels images for many legitimate and
> > exploratory reasons, and this *does* cause full disks on the default
> > partition size. If people are doing this, and the OS allows it (and it
> > should), then how can it not be a supported use case?
>
> A consequence of Ubuntu being open and customizable is that users can do
> many things that are not ones that we endorse.
>
> > Should we remove safety belts from cars because we arbitrarily decide
> that
> > braking hard is not a supported use case? Where are Ubuntu's supported
> use
> > cases, DFMEAs, and KPCs available for review?
> >
> > Compare the cost of $0.25 disk space versus the cost helping one novice
> > user recover an overfull /boot partition. This can easily exceed $200 in
> > direct support and lost productivity.  That's 800 *times* more expensive.
> > Worse, if the user can't find help expert-level assistance, they are
> highly
> > motivated to abandon Ubuntu altogether.
> >
> > If Ubuntu is for everyone, then we should be catering to the vast
> majority
> > to whom the $0.25 of disk space doesn't matter. These users also often
> lack
> > the deep skill set to recover from this failure mode. Conversely, the
> tiny
> > fraction who want to optimize /boot size are those best equipped to do
> so -
> > they are typically on a much smaller disk and are creating custom
> > installations for things like embedded or edge systems. The installer is
> no
> > impediment for these professionals.
> >
> > We could continue discussing minutia about why this may or may not be a
> > good idea, however, I believe the cost / benefit analysis above is highly
> > convincing. We are confident from experience that a 2G /boot partition
> is a
> > very good choice that works with best practice for all common and
> readable
> > use cases. A quick web search also shows this size is frequently
> > recommended by other experienced desktop Linux users.
>
> We are all in agreement that the /boot partition size needs / needed
> increasing. For us to move forward in the discussion about increasing it
> to 2G it would really help for you to answer my previous questions
> regarding the use cases for having multiple kernels installed. Those
> questions were in the following email:
>
> https://lists.ubuntu.com/archives/ubuntu-devel/2022-February/041856.html
>
> Cheers,
> --
> Brian Murray
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20220221/f085596e/attachment-0001.html>