Re: Improvement ideas for kernel and the surrounding oekosystem
Hi Ben
On Tue, Feb 01, 2022 at 12:29:08AM +0100, Ben Hutchings wrote:
> On Thu, 2021-11-11 at 11:47 +0100, Bastian Blank wrote:
> > - A lot of bootloaders require special filesystems or other settings.
> > Now this more and more clashs with dpkg, as dpkg can't write data on
> > those filesystems (FAT for EFI is a common example).
> I'm not sure how common it is to make the EFI boot partition be /boot.
> I do know Raspberry Pi users expect /boot to be the FAT partition that
> its boot ROM uses, and it is a common complaint that our linux-image
> packages are not upgradable in such a configuration.
EFI is one example. Some deprecated boot loaders do the same, like the
one for hppa I think by requiring old ext2 variants.
However "other" people have decided to create discoverable partitions by
using pre-defined UUID. https://systemd.io/DISCOVERABLE_PARTITIONS/
There an EFI partition is either stuck at /efi or /boot (if empty).
> > So my rough ideas would be:
> > - Everything from kernel packages is installed somewhere in /usr/lib.
> One objection would be that this may (depending on the boot loader and
> storage configuration) require even more storage for the kernel, which
> may matter for some smaller systems.
Yeah, that might happen. Reflink copies or hardlinks can help, if /boot
is the same filesystem.
If we allow initramfs creators to write directly to the final resting
place, it'll somewhat reduce the space requirements, as the initramfs
tends to be the largest part. But it reduces the flexibility as lot.
> > - The bootloader stuff is responsible to put everything where they want
> > to have it. So those can tightly control what they need setup in what
> > way.
> I think we would need to have some kind of compatibility fallback
> behaviour for a while, but it does make sense to delegate this to the
> boot loader.
Yes, that we'll need. I assume this compatibility fallback would be the
first implementation of the new protocol anyway.
> > How it could like like:
> > - /usr/lib/kernel/linux_5.14.0-1-amd64
> > - kernel (linux can boot efi, bios and xen)
> > - (initramfs.$package)
> > - (kernel.efiunified)
> > - /usr/lib/kernel/xen_4.14
> > - kernel.pcbios
> > - kernel.efi
> > - /var/lib/kernel/linux_5.14.0-1-amd64
> > - initramfs.$package (you could have multiple initramfs generators
> > installed)
> > - data.$package
>
> This might be a bit too flexible.
What to you mean with "too flexible"?
> How do we avoid having huge numbers
> of boot menu entries?
What do you mean with that? The number of boot entries does not go up
to the status quo.
> How is the default option decided?
That's an unsolved problem, yes. We could prefer the one pulled in by
the meta package as default.
> It's going to take some time and effort to change all of those, so we
> would need good arguments for why all the other maintainers should
> bother with it, and we would need to plan for a gradual transition.
Yep.
Bastian
--
The sight of death frightens them [Earthers].
-- Kras the Klingon, "Friday's Child", stardate 3497.2
Reply to: