> 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 <https://kfocus.org> 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.
Increasing the size of the /boot partition comes at the cost of
decreasing the size of the / partition though and I suspect there are
people just as passionate about the usable space they have available for
their operating system and files as your are about free space in /boot.
I'm not disputing the impact of a small /boot partition but there is a
balancing act for us to provide a default install that is best for the
majority of Ubuntu users.
> *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.
The reason we just don't do it is because it requires careful
consideration as I've indicated above. What number of users have you
encountered who have filled their /boot partition? What release of
Ubuntu had they installed and what was the size of their /boot
partition? (The size of the /boot partition created by the installer has
changed a number of times.)
> *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.
Agreed.
> *3. This happens frequently, even when everything works as designed*, and
> even when just using a single kernel flavor.
I've seen references to bugs about packagekit and unattended-upgrades
and their handling of the quantity of kernels and space management in
/boot. Those are bugs that should be resolved in those packages rather
than increasing the size of /boot (and taking away from /) to compensate
for those bugs.
> 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.
For reference the conversation where 2 unsolicited individuals commented
is here:
https://irclogs.ubuntu.com/2022/02/08/%23ubuntu-devel.html
Additionally, both of those developers have been able to install Ubuntu
in a way that meets their specific needs.
> *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.
I'd really like more information on the use case where multiple kernel
flavors will be installed. You mention switching from HWE to OEM, given
that this is a switch wouldn't the HWE kernel be removed and then you
are left with just one flavor of kernel?
I understand the studio use case to be having a "regular" kernel
flavor installed and a low latency flavor one installed so that one can
boot between one or the other depending on their work load. Is that a
correct understanding?
> 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.
Instead of assuring use your calculations are correct it would have
helped if you were to show your math. However, I think I've sorted it out.
My Jammy installation of Ubuntu (nvidia and cryptfs) has the following
in /boot:
165M initrd.img-5.15.0-18-generic
6M System.map-5.15.0-18-generic
11M vmlinuz-5.15.0-18-generic
Adding those together we have 182M. These are the sizes I used when I
updated partman-auto for http://launchpad.net/bugs/1959971 which is
close to what you are looking for but with only one kernel flavor
being accounted for. [This has only happened for Ubuntu 20.04 because
some additional changes may happen in Jammy.]
> It seems perfectly reasonable to expect this size to grow to 200M or
> more over the next 2 years.
I actually expect it to decrease in size once we've finalized our
discussion on changing the default compression method.
https://lists.ubuntu.com/archives/ubuntu-devel/2021-December/041726.html
Cheers,
--
Brian Murray
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
