/boot disk partition size

Thu Feb 17 19:24:13 UTC 2022

Hi Everyone,

Just forwarding this since it's still getting moderated. I talked to
Mike and he didn't mean for it to sound snarky in any way in the 3rd
paragraph with the reference to car safety belts, and he wanted to
apologize.

I'd very much like to encourage participation in this thread,
especially from those on the Foundations Team that requested this
thread in the first place.

Thanks!
Erich
--
Erich Eickmeyer
Project Leader, Ubuntu Studio
Member, Ubuntu Community Council

On Wed, 2022-02-16 at 11:26 -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. 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? 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.
> 
> I hope you find this useful.
> 
> Sincerely, Mike
> 
> 
> On Tue, Feb 15, 2022, 19:59 athoneycutt
> <aaronhoneycutt at protonmail.com> wrote:
> > I second this as we are at the point where this size increase won't
> > affect most folks. Pop!_OS uses a 512MB /boot (/boot/efi) partition
> > which works well for dual boot setups as well. 
> > 
> > 
> > Sent from ProtonMail mobile
> > 
> > 
> > 
> > -------- Original Message --------
> > On Feb 14, 2022, 03:45, Michael Mikowski < mmikowski at kfocus.org>
> > wrote:
> > > 
> > > Hi Everyone: 
> > > Members of the ubuntu-meeting asked me to clarify the issue with
> > > /boot. You can see the bugs filed at
> > > https://launchpad.net/bugs/1959971 and
> > > https://launchpad.net/bugs/1960089.
> > > Personal Background:
> > > I currently lead the Kubuntu Focus engineering efforts, and have
> > > been a professional product engineer specializing in mission-
> > > critical HP/HA/HV systems for decades. You can see a overview of
> > > my experience at https://michaelmikowski.com. 
> > > 
> > > My Assessments:
> > > 
> > > 0. This is a low-cost, high-return proposal. People have pushed
> > > back against increasing the /boot partition, but I find most of
> > > the reasoning does not consider the true impact of a small /boot
> > > partition to the complete product. 
> > > 
> > > 1. The cost to provide the space needed is minimal for almost all
> > > FDE systems. So why not just do it? Of course, there is more work
> > > to be done for the rest of the product (guide users on kernel
> > > selection; improve the kernel cleaning logic), but this is an
> > > important component that is required in any complete solution. It
> > > would provide substantial relief to many users immediately. 
> > > 
> > > 2. An overfull /boot partition is catastrophic for many users.
> > > Many cannot recover their system because they don't have a rescue
> > > disk or knowledge of ext4, chroot, LUKS, lvm, cryptesetup,
> > > package management, and more. These people either reload the OS
> > > or give up. 
> > > 
> > > 3. This happens frequently, even when everything works as
> > > designed, and even when just using a single kernel flavor. While
> > > on IRC yesterday discussing this, 3 unsolicited individuals
> > > stepped in to comment about how this is needed. And those are
> > > advanced developers who know better. Search for 'ubuntu full
> > > /boot partition' and check out how frequently this continues to
> > > occur.  
> > > 
> > > 4. There are many use cases where multiple kernel flavors will
> > > occur, such as when the users switches from HWE to OEM to address
> > > hardware issues, or they install lowlatency for studio work. When
> > > this happens, the current size boot partition is highly likely to
> > > fill. This can corrupt the system and require a rescue disk for
> > > recovery. 
> > > 
> > > Check out the DFMEA which is used to assess the severity of a
> > > failure
> > > mode: 
> > > https://bugs.launchpad.net/ubuntu/+source/partman-auto/+bug/1959971/comments/7
> > > 
> > > Finally, I assure you the calculations for kernel boot-file-set
> > > sizes (180M with Nvidia GPU) are correct for 20.04, and will be
> > > correct for 22.04 unless the compression technique has been
> > > changed. It seems perfectly reasonable to expect this size to
> > > grow to 200M or more over the next 2 years. Also, the headroom +
> > > safety factor specified (10 kernel file-sets total) is reasonable
> > > when you consider that systems that reboot less frequently will
> > > accumulate kernels and that a single upgrade can install multiple
> > > additional kernel images. 
> > > 
> > > Sincerely, Mike 
> > > 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20220217/728d9048/attachment.html>