[FFE] increase /boot partition size

Bug #1959971 reported by Brian Murray
16
This bug affects 3 people
Affects Status Importance Assigned to Milestone
partman-auto (Ubuntu)
Triaged
High
Unassigned
Focal
Fix Released
High
Brian Murray
Jammy
Triaged
High
Unassigned
subiquity (Ubuntu)
Fix Committed
Undecided
Unassigned
Focal
Fix Released
Undecided
Unassigned
Jammy
Fix Committed
Undecided
Unassigned
ubiquity (Ubuntu)
Fix Released
High
Brian Murray
Focal
Fix Released
Undecided
Unassigned
Jammy
Fix Released
High
Brian Murray

Bug Description

[FFE Discussion]
Now that changes to the initramfs compression level have been settled for jammy (https://launchpadlibrarian.net/590731434/initramfs-tools_0.140ubuntu12_0.140ubuntu13.diff.gz) we need to update the size of /boot so that the additional size of the initrd is taken into account. This should be done before the Beta as more people may be installing Ubuntu then and we don't want them to have undersized /boot partitions given the problems that this can cause.

Using the same install of Ubuntu with cryptsetup and nvidia modules my initrd is now 188 MB. Plugging that into our formula gets:

2* (3*11 + 4*188 +11) = 1592

While that's divisible by two, I think we should bump it a bit more to 1848.

[Impact]
All new installs of 20.04.

[Test case]
1) Install Ubuntu 20.04 with encryption (this'll create a separate /boot partition) on a system
2) Validate that the size of the /boot partition is greater than or equal to 768MB; should be somewhere between 768MB and 1536GB.

[Regression potential]This may adversely affect installs on tiny disks, by taking up more space for the /boot partition than was previously taken, at the cost of / or /home. As such, failures to install due to insufficient space on a partition, or failure to partition a disk that was previously working should be investigated as possible regressions.
This is a corner case in general since there is no requirement to allocate a separate partition for /boot in the default configuration, and if you are using a non-default configuration where /boot must be a separate partition, you probably also don't have a disk so small that an additional 256MB of disk usage is a problem.

---
The kernel in Jammy is a bit larger than the one in Focal and our previous /boot partition size calculation (LP: #1716999) likely didn't take into account adding modules like nvidia to the initramfs. Subsequently, we need to revisit the size calculations for Focal.

I'm utilizing cryptsetup and nvidia modules and have a 164M initrd when using lz4 (the default in Focal) compression. Using the same formula we previously did we end up with this:

2* (3*11 + 4*164 + 11) = 1400

So modifying the maximum size to 1536 seems reasonable, the current minimum is 512 which is actually a bit too small for an initrd with less modules e.g.:

2* (3*11 + 4*62 + 11) = 584

So the minimum should also be increased to 768.

description: updated
Changed in partman-auto (Ubuntu Focal):
status: New → In Progress
importance: Undecided → High
assignee: nobody → Brian Murray (brian-murray)
tags: added: fr-1978
description: updated
Changed in partman-auto (Ubuntu Jammy):
status: New → Triaged
importance: Undecided → High
Revision history for this message
Łukasz Zemczak (sil2100) wrote : Please test proposed package

Hello Brian, or anyone else affected,

Accepted partman-auto into focal-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/partman-auto/134ubuntu13.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-focal to verification-done-focal. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-focal. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Changed in partman-auto (Ubuntu Focal):
milestone: none → ubuntu-20.04.4
status: In Progress → Fix Committed
tags: added: verification-needed verification-needed-focal
Revision history for this message
Łukasz Zemczak (sil2100) wrote : Re: increase /boot partition size

I think we need to make sure to release-note it for 20.04.4 in case we decide to go with it. I accepted this into focal-proposed so that we can have dailies built with this change and some validation done.

I suppose we'll also need to get this new version pulled into ubiquity?

Revision history for this message
Michael Mikowski (kfocus) wrote (last edit ):

Hi Łukasz and Brian: I have been doing quite a bit of research in this area recently, and also am advocating to get kernel management and cleanup improved, especially for users who must have separate /boot partitions. This means professional users who are required to have full disk encryption according to company IT policies.

Using best practice to manage 3 kernel packages (e.g. oem, lowlatency-hwe, generic-hwe) results in the need to maintain 6 kernel file sets (latest and penultimate version for each kernel). Because of the way kernel cleaning is scheduled, additional space is also required for at least 2 additional images. You can see the entire reasoning and details at LP: #1960089.

Our conclusion is that 2.0 GB is the preferred target /boot partition size for professional systems. This is reinforced by my research which shows many pros recommend this same size when discussing partitioning (Just one example: https://adventures-in-tech.blogspot.com/2018/10/encrypted-ubuntu-installation-with.html)

Given disk space these days, this seems like a small price to pay to support best practice and (hopefully) a future unattended upgrades algorithm that honors them as well.

Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in ubiquity (Ubuntu Focal):
status: New → Confirmed
Changed in ubiquity (Ubuntu):
status: New → Confirmed
Revision history for this message
Brian Murray (brian-murray) wrote : Please test proposed package

Hello Brian, or anyone else affected,

Accepted ubiquity into focal-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/ubiquity/20.04.15.19 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-focal to verification-done-focal. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-focal. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Changed in ubiquity (Ubuntu Focal):
status: Confirmed → Fix Committed
Revision history for this message
Michael Mikowski (kfocus) wrote (last edit ): Re: increase /boot partition size

Design Failure Mode Effects Analysis

System: Boot

Potential Failure Mode: /boot partition overfills

Effects of Failure: To return the system to a usable state, the user must have advanced knowledge and an available system recovery disk. The procedure involves disk mounting, chroot, package management, and deep file system knowledge. This is outside the range of most target users.

Severity: 10 - system is completely unusable until recovery, and recovery is time consuming and tedious for advanced users, or impossible for less skilled users.

Causes of Failure:
1. Multiple kernel updates between reboots will overfill the standard 705M /boot partition with over 3 kernels.
2. User installing generic and lowlatency hwe kernels. They may also have transient kernels when switching to another kernel like oem.

Preventative Activities:
1. There does not appear to be any tool to guide kernel selection for users or ensure the latest and penultimate versions are reserved for the kernels.
2. There does not appear to be any testing which prevents installation of a kernel that would over-fill the disk.
3. unattended-upgrades tries to clean images that fill up the /boot disk, but it does not consider disk space, and even when it work (which is a whole other issue), the /boot disk is required to hold 4 images at times which is not feasible with the current 705M size.

Occurrence: 5 (even users with a singe Kernel flavor encounter this)

Detection Rating: 5 - Preventative Activities are unlikely to be effective at all times

Risk Priority Number: Severity * Occurrence * Detection = 250

Take Away Points:

* The DFMEA indicates this is a severe issue that should be considered critical.
* When an overfull /boot disk occurs, the effect is catastrophic to the the average user, and for many is simple unrecoverable. This can and does drive users to abandon the OS when this occurs.
* Existing controls to prevent occurrence are inadequate (automated upgrades still allows disk to over fill when using a single kernel flavor, and does not consider disk space) or completely missing (users are not guided on the issue of kernel management). The popularity of forum posts over the years about this issue illustrates this is a substantial problem.
* This issue goes beyond /boot partition size, but the increasing it to handle all possible transient states is required for a complete solution.
* Disk space is cheap these days. On consumer desktop solutions, 2.0GB is a small price to pay to avoid a catastrophic failure which is otherwise unrecoverable for many users.

Revision history for this message
Brian Murray (brian-murray) wrote :

I tested an installation of the daily image of Ubuntu 20.04 from 2022-02-11 (using lvm and encryption) and my boot partition has a size of 1.44G. This falls within the range we expected so I'm setting this to verification-done.

description: updated
tags: added: verification-done verification-done-focal
removed: verification-needed verification-needed-focal
Revision history for this message
Łukasz Zemczak (sil2100) wrote :

@kfocus Thank you for the detailed assessment! For 20.04 (at least for 20.04.4) we will only bump the partition sizes slightly, as mentioned in the current description (and in the current SRU). We need to thread carefully as it's a point-release of an already released series. As for 22.04, we are certainly open to discussion and your findings will be very helpful to make the best decision.

Let's see how it goes.

Revision history for this message
Michael Mikowski (kfocus) wrote (last edit ):

@sil2100 @brian-murray: Thank you for your work and consideration on this. We addressed this issue Kubuntu Focus OEM ISO (https://kfocus.org/try) by increasing the /boot partition size and providing an app that monitors and removes unused kernels (https://kfocus.org/wf/tools#kclean). We want to share our findings upstream for the benefit of everyone that uses client Ubuntu with FDE. In summary, an additional 1.2G of disk space is a very small price to pay to avoid the extreme expense of guiding non-expert users to recover from an over-full partition, or losing a user because they aren't capable of recovery by themselves.

Revision history for this message
Chris Halse Rogers (raof) wrote : Update Released

The verification of the Stable Release Update for partman-auto has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

Revision history for this message
Launchpad Janitor (janitor) wrote : Re: increase /boot partition size

This bug was fixed in the package partman-auto - 134ubuntu13.1

---------------
partman-auto (134ubuntu13.1) focal; urgency=medium

  * Bump minimum and maximum sizes for /boot partitions on default, x86, and
    EFI platforms to a minimum of 768Mb and maximum of 1536Mb. (LP: #1959971)

 -- Brian Murray <email address hidden> Thu, 03 Feb 2022 15:02:21 -0800

Changed in partman-auto (Ubuntu Focal):
status: Fix Committed → Fix Released
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package ubiquity - 20.04.15.19

---------------
ubiquity (20.04.15.19) focal; urgency=medium

  * Backport the ability to unhide passwords that are being typed-in during
    various stages of the installation (LP: #1960306).
  * Automatic update of included source packages: partman-auto
    134ubuntu13.1 (LP: #1959971).

 -- Łukasz 'sil2100' Zemczak <email address hidden> Tue, 08 Feb 2022 11:51:13 +0100

Changed in ubiquity (Ubuntu Focal):
status: Fix Committed → Fix Released
Changed in partman-auto (Ubuntu Jammy):
milestone: none → ubuntu-22.04-beta
Changed in ubiquity (Ubuntu Jammy):
status: Confirmed → Triaged
importance: Undecided → High
summary: - increase /boot partition size
+ [FFE] increase /boot partition size
description: updated
Changed in partman-auto (Ubuntu Jammy):
status: Triaged → New
Changed in ubiquity (Ubuntu Jammy):
status: Triaged → New
Revision history for this message
Dan Bungert (dbungert) wrote :
Changed in subiquity (Ubuntu Focal):
status: New → Fix Released
Changed in subiquity (Ubuntu Jammy):
status: New → Fix Committed
Revision history for this message
Łukasz Zemczak (sil2100) wrote :

I think this makes sense. We had a similar change done to focal already for 20.04.4 so jammy should be good in my eyes as well. Approved.

Changed in partman-auto (Ubuntu Jammy):
status: New → Triaged
Changed in ubiquity (Ubuntu Jammy):
status: New → Triaged
Changed in ubiquity (Ubuntu Jammy):
assignee: nobody → Brian Murray (brian-murray)
status: Triaged → In Progress
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package ubiquity - 22.04.8

---------------
ubiquity (22.04.8) jammy; urgency=medium

  * In partman-auto bump the minimum and maximum sizes for /boot partitions on
    default, x86, and EFI platforms to a minium of 1024Mb and a maximum of
    1848Mb. (LP: #1959971)
  * After copying log files to /var/log/installer set the permissions to 0o640
    and change the group owner to adm.
  * Resolve a crash in the KDE frontend when trying to install Kubuntu which
    was caused by changes to division. Thanks to LP user Cyril for the patch.
    (LP: #1963697)

 -- Brian Murray <email address hidden> Tue, 22 Mar 2022 10:35:07 -0700

Changed in ubiquity (Ubuntu Jammy):
status: In Progress → Fix Released
Revision history for this message
Dimitri John Ledkov (xnox) wrote :

ZFS installation using ubiquity still uses smaller 1GiB sized bpool (equivalent of /boot on zfs)

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

Other bug subscribers