/boot disk partition size

[Michael Mikowski]

> We considered adapting the kernel autoremoval code in apt to consider free
space, but decided against it, as it removes safety/redundancy. If users
install more kernels than their boot partition supports, upgrades
*should* fail, rather than providing less safety by removing kernels.

> I'm strongly opposed to anyone shipping different implementations of
kernel autoremoval code, we really ought to clean all that up and
move everyone to the new code inside libapt-pkg.

Hi Julian:

I agree that it makes sense to upstream any improvements. I hope you can
appreciate we had to take immediate action due to a packagekit bug where
kernel cleanup stopped working.  It was either that or face a tsunami of of
broken systems and 2-hour support calls for over-full /boot partitions.
Thanks to the hard work of Matthias Klumpp, it looks now like the package
kit bug has been resolved, but the total time from initial report to
distribution will be perhaps 18 months. The kennel cleaner tool was created
and distributed in 2 days, and it works. We also increased /boot size in
new installation to provide a margin of safety.

When the /boot partition over fills, it doesn't always break cleanly. While
packaging improvements may have helped recently, in our own testing and in
the field we saw apt left in an inconsistent state and even the inability
to boot. Repair in that situation requires a rescue disk, and knowledge of
chroot, LUKS, lvm, apt, grub, and other advanced Linux topics. And hours of
time on the phone walking an often-casual user through all those steps. Ugh.

Even when kernel auto remove is working correctly, our assessment was it
wasn't sufficient. It doesn't consider remaining disk space, and it
actively protects up to 4 kernel version. The default boot size only has
room for 3.

I would appreciate an opportunity to participate in the specifications for
an improved kennel cleaning algorithm. I certainly have hands-on experience
both developing effective specs and deep knowledge and experience with this
issue. This is perhaps a good start:
https://github.com/Bleuzen/ubuntu-kernel-autoremove/issues/1#issuecomment-1028425717

Sincerely, Mike

Packagekit bug: https://github.com/PackageKit/PackageKit/issues/450
Kernel clean cli: https://github.com/Bleuzen/ubuntu-kernel-autoremove



On Tue, Feb 22, 2022, 01:20 Julian Andres Klode <julian.klode at canonical.com>
wrote:

> On Mon, Feb 21, 2022 at 02:44:14PM -0800, Michael Mikowski wrote:
> > Hi Brian:
> >
> > First, let me state the title of the bug I filed was unfortunate and I’ve
> > changed it accordingly. The body of the request shows that it is a
> proposal
> > to increase the /boot partition size, but the title sounded demanding.
> > Also, the file sizes were ambiguous. I have updated them both.
> >
> > https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1960089
> >
> > > A consequence of Ubuntu being open and customizable is that users can
> do
> > many things that are not ones that we endorse.
> >
> > Agreed, but I believe Ubuntu should support multiple kernels for a few
> > reasons:
> >
> > 1. We agree that the outcome of an overfull /boot partition can be
> > catastrophic for less-than-expert users. It seems, therefore, that the
> > system should help avoid this situation commiserate with its potential
> cost.
> >
> > 2. There are no obvious mechanisms to guide novice users with kernel
> > management. Unless I’m missing something (always a possibility) there is
> no
> > system that actively monitors the /boot partition *size* and warns users
> of
> > filling disk (impending doom?). We did this (see
> > https://kfocus.org/wf/tools#kclean) but we don’t know if or when this
> will
> > be upstreamed.
>
> We considered adapting the kernel autoremoval code in apt to consider free
> space, but decided against it, as it removes safety/redundancy. If users
> install more kernels than their boot partition supports, upgrades
> *should* fail, rather than providing less safety by removing kernels.
>
> I'm strongly opposed to anyone shipping different implementations of
> kernel autoremoval code, we really ought to clean all that up and
> move everyone to the new code inside libapt-pkg.
>
> --
> debian developer - deb.li/jak | jak-linux.org - free software dev
> ubuntu core developer                              i speak de, ena
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20220222/44498f96/attachment.html>