/boot disk partition size
Julian Andres Klode
julian.klode at canonical.com
Tue Feb 22 09:20:11 UTC 2022
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, en
More information about the ubuntu-devel
mailing list