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