[Bug 1960089] Re: Request 2.0 GiB Boot Partition for 22.04LTS FDE

Mon Feb 21 23:08:14 UTC 2022

** Description changed:

  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.0 GiB.
+ 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.0 GB default for the
+ 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)

-- 
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