Request 2.0 GiB Boot Partition for 22.04LTS FDE

Bug #1960089 reported by Michael Mikowski
This bug report is a duplicate of:  Bug #1959971: [FFE] increase /boot partition size. Edit Remove
28
This bug affects 6 people
Affects Status Importance Assigned to Milestone
partman-auto (Ubuntu)
Confirmed
High
Unassigned
Focal
Confirmed
High
Unassigned
Jammy
Confirmed
High
Unassigned
ubiquity (Ubuntu)
Confirmed
High
Unassigned
Focal
Confirmed
High
Unassigned
Jammy
Confirmed
High
Unassigned

Bug Description

Summary:

We propose to increase the LVM /boot partition to 2.0 GiB. This provides the space needed so advanced users can use best practice to manage up to 3 kernel flavors. The current /boot partition on 20.04 and 22.04 is limited to just 705MiB, which allows only 3 concurrent kernels before filling and sometimes locking the system (each image set takes 180MiB total; 4 x 180 = 720MiB > 705MiB).

Reasoning:

Best practice recommends users keep at least two version of each kernel flavor in the /boot directory. If a user has 3 kernel flavors installed (e.g. oem, generic-hwe, and lowlatency-hwe), then one needs to reserve room for 2 x 3 = 6 kernels.

The system needs the headroom of at least two additional kernels during any automated clean-up process due to package removal scheduling. I propose to also reserve room for 2 additional kernels as a safety measure. Thus the total recommend available space should accommodate 10 kernels.

Each kernel file set takes up 180MiB in the /boot partition when used with Nvidia driver modules. These files include initrd.img, system.map, and vmlinuz. With future kernel and module growth, this may surpass 200MiB soon. Therefore, we suggest planning for 200M for each kernel.

We therefore request a total LVM /boot partition size of 10 image x 200MiB = 2.0GiB.

Other Considerations:

When unattended-upgrades works correctly (which does not yet employ best practice), we have seen users with just a single kernel flavor over-fill their /boot partitions. This is because unattended-upgrades can retain up to 4 kernels, while the /boot partition is only large enough for 3. I am currently working with others to improve the unattended-upgrades algorithm to use best practice.

The installer could allow users to resize the /boot partition during installation. In this case, we highly recommend a 2.0GiB default for the reasons outlined above.

ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: ubiquity (not installed)
ProcVersionSignature: Ubuntu 5.14.0-1011.11-oem 5.14.17
Uname: Linux 5.14.0-1011-oem x86_64
NonfreeKernelModules: nvidia_modeset nvidia
ApportVersion: 2.20.11-0ubuntu27.21
Architecture: amd64
CasperMD5CheckResult: skip
CurrentDesktop: KDE
Date: Fri Feb 4 14:53:36 2022
InstallCmdLine: BOOT_IMAGE=/casper/vmlinuz file=/cdrom/preseed/kubuntu.seed only-ubiquity quiet splash oem-config/enable=true ---
InstallationDate: Installed on 2020-06-10 (604 days ago)
InstallationMedia: Kubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423)
SourcePackage: ubiquity
UpgradeStatus: No upgrade log present (probably fresh install)

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

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

Changed in ubiquity (Ubuntu):
status: New → Confirmed
Changed in ubiquity (Ubuntu):
importance: Undecided → Medium
Changed in ubiquity (Ubuntu Focal):
status: New → Confirmed
importance: Undecided → High
Changed in ubiquity (Ubuntu Jammy):
importance: Medium → High
Revision history for this message
Erich Eickmeyer (eeickmeyer) wrote :

This would be a rather trivial fix. In d-i/source/partman-auto/recipes-amd64-efi/atomic one only needs to change this stanza:

512 1024 768 ext4
 $defaultignore{ }
 $lvmignore{ }
 method{ format }
 format{ }
 use_filesystem{ }
 filesystem{ ext4 }
 mountpoint{ /boot } .

Simply doubling the size allocation would be easy, as storage is cheap these days:

1024 2048 1536

I'll submit a patch soon with this fix.

tags: added: rls-ff-incoming rls-jj-incoming
Changed in partman-auto (Ubuntu Focal):
status: New → Confirmed
Changed in partman-auto (Ubuntu Jammy):
status: New → Confirmed
importance: Undecided → High
Changed in partman-auto (Ubuntu Focal):
importance: Undecided → High
Revision history for this message
tellapu (tellapu) wrote (last edit ):

@eeickmeyer Thank you for working on this!
Even for more normal users the space may not be enough in the future as an LTS version is often used for a long time and the kernel size will probably rather increase than decrease.
It just happened to me on 20.04 LTS that the boot partition ran out of space (for the first time since 20.04).

tags: removed: rls-jj-incoming
summary: - Ubiquity Boot Partition for LVM needs to be 2.0 GB for 22.04LTS
+ Request 2.0 GB Boot Partition for 22.04LTS FDE
description: updated
summary: - Request 2.0 GB Boot Partition for 22.04LTS FDE
+ Request 2.0 GiB Boot Partition for 22.04LTS FDE
description: updated
Revision history for this message
Piotr Henryk Dabrowski (phd) wrote :

This issue causes updates to fail when lowlatency kernel is installed.

2 generic kernel versions + 2 lowlatency kernel versions already barely fit in the current /boot partition limit of 732MB.
During kernel updates apt tries to install another 2 images (before removing the previous old ones).
This ends in failed update.

Revision history for this message
Piotr Henryk Dabrowski (phd) wrote :

> We propose to increase the LVM /boot partition to 2.0 GiB.

Or just allow user to modify that size in the installer?
Especially that the required size really depends on user needs (lowlatency kernel, custom kernels).

Revision history for this message
Piotr Henryk Dabrowski (phd) wrote :

Meanwhile the separate /boot/efi partition is probably way too big: 513MB.
Out of which my installation uses... 6.23MB.

Maybe /boot and /boot/efi could be merged into a single /boot partition?
Although that means it would have to be formatted as FAT32. So no symlinks.

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

@phd The /boot/efi partition size of 512MiB is far larger than most people need, but it does cover almost all potential use cases included dual boot. If that partition gets corrupted or filled, it could prevent boot of any OS on that disk. For this reason, I believe the team went with the sensible choice and kept that size to prevent this catastrophic, and for many people, unrecoverable error.

There are certainly other reasons why /boot/efi is separate. As you mentioned, symlinks are lost, and I speculate that might necessitate full copies of initrd.img, for example, which would completely negate any space savings from combining the two. And of course, if you do that and load up too many kernels, the /boot/efi partition can get corrupted, which is even worse than an overfull boot partition.

I certainly support your proposal to have the user specify a /boot partition size during FDE install, preferable from a list. Customers who run development, AI, and content-creation workstations definitely need a larger boot allocation, whereas Raspberry Pi hobbyists are probably fine with the default, although I wonder how many of the latter actually need or use LVM or FDE (LVM+LUKS).

Revision history for this message
Piotr Henryk Dabrowski (phd) wrote :

BTW: Is there a way to safely resize /boot on an already installed system?

Revision history for this message
Steve Langasek (vorlon) wrote :

This had been marked 'rls-ff-incoming' meaning it was in the queue for the Canonical engineering teams to evaluate committing to fix in Focal. I am declining this on behalf of the Foundations Team, as we have yet to even commit to fixing this for the upcoming Jammy release. Discussion is ongoing.

tags: added: rls-ff-notfixing
removed: rls-ff-incoming
Revision history for this message
Francois Thirioux (fthx) wrote :

I've hit this bug recently while playing in Jammy with linux, linux-hwe and linux-oem-6.1.

And today, upgrading Jammy to Kinetic then Lunar. This time was critical as the upgrade cannot be started because of boot folder size.

I do use FDE and Nvidia drivers. I tried to remove *.old things, all unneeded kernels but no way, there was not enough space.
So I had to switch back from nvidia-dkms to nvidia modules, reducing the initrds size (~ -50%).

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

Francois, the Ubuntu team did substantially increase the boot disk in Jammy (and later, I expect) and it very much has made life much easier for those we know who do development and testing. However, it *does* require a reinstall to take advantage of the new formula. I saw around1.8-2.0 GB being reserved on a 500 GB disk with stock FDE. A formula calculates this size based on the disk provided, and I’m certain you can look that up.

You will want to confirm your /boot disk size is 1.8-2.0 GB; if it is not, you can resize the /boot partition or reinstall. If the /boot partition is the 1.8-2.0 GB size and you still run out of space, then you might use xz compression on your initrd files (see /etc/initramfs-tools/conf.d). If you need help, just give me a ping. If you reinstall and the boot size is not 1.8-2.0 GB, you could reopen this bug or open a new one.

Because we consistently see 1.8-2.0 GB /boot partitions on FDE installs, I suggest the Ubuntu team take credit and closed this bug (fixed in Jammy, won’t-fix in Focal; I can’t do that). While users frequently saw out-of-disk-space errors in Focal (20.04), we have seen none in Jammy (22.04).

Sorry for the long post. I hope that is helpful. Also, sorry for multiple the edits. I will proof read better next time before posting.

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

@brian-murray, Do you want to close this? It seems to me the fix is in and it is no longer an issue for most people on 22.04 FDE systems.

Revision history for this message
Nathan Stratton Treadway (nathanst) wrote :

(see also LP: #1959971 "[FFE] increase /boot partition size")

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

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.