[Bug 1960089] Re: Request 2.0 GiB Boot Partition for 22.04LTS FDE
Michael Mikowski
1960089 at bugs.launchpad.net
Thu Mar 24 20:09:44 UTC 2022
@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.
It seems to your suggestion of providing the user the opportunity to
specify the /boot partition size on install is an excellent choice, and
IMO is a great resolution to the issue. 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 LVM+LUKS (FDE).
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to ubiquity in Ubuntu.
https://bugs.launchpad.net/bugs/1960089
Title:
Request 2.0 GiB Boot Partition for 22.04LTS FDE
Status in partman-auto package in Ubuntu:
Confirmed
Status in ubiquity package in Ubuntu:
Confirmed
Status in partman-auto source package in Focal:
Confirmed
Status in ubiquity source package in Focal:
Confirmed
Status in partman-auto source package in Jammy:
Confirmed
Status in ubiquity source package in Jammy:
Confirmed
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)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/partman-auto/+bug/1960089/+subscriptions
More information about the foundations-bugs
mailing list