Re: RFC: bootloader/initramfs protocol v2
Hi Luca
On Sun, Nov 06, 2022 at 02:14:54PM +0000, Luca Boccassi wrote:
> On Tue, 2022-11-01 at 21:29 +0100, Bastian Blank wrote:
> > ## Goals
> >
> > - Setup complete boot entries from packaged and generated files
> > - Support dumb file systems for /boot by default, so boot loaders can
> > drop complex file system support.
> > - Re-create stuff in /boot from scratch
> > - Remove symlink handling from kernel package
> > - Single entry point for packages and admins, aka no tool specific
> > "update-initramfs" anymore
>
> Could you clarify what you mean by "single entry point" here? It's the
> only point I can't quite decode. A trigger?
You have one tool to call, not right now multiple (the kernel maintainer
scripts do some, "update-initramfs" scribles to it as well).
> I would like to suggestion this as an additional, explicit goal, rather
> than implicit:
> End result should be fully compatible with the BLS (for the readers:
> https://uapi-group.org/specifications/specs/boot_loader_specification/
> )
Yes. We will need extensions, some may be incompatible as well.
> > ## Open questions
> >
> > - How to select default entry if supported, just sort by version and
> > use
> > newest? This also works somewhat in BLS.
>
> Yes, we should follow BLS on this, so that end result is predictable,
> well-defined and doesn't vary wildly from other distros.
Okay.
> In fact, if Grub can do UKIs, do we even need Type 1 entries (separate
> textual config files) for anything at that point?
grub needs to be able to read and disect UKI for non-EFI without loader
code (aka for ppc, sparc, bios and xen). And we need a way to create
them without the really heavy binutils.
And for all the old bootloaders, we have no way to use UKI at all. So
if we want to ship UKI in packages, we also need to be able to disect
them in userspace.
Can you currently create UKI with multiple multi-boot capable initrd
attachments? For Xen.
> > ### Distribution file system (/usr)
> >
> > * /usr/lib/boot/$package(_$modifier)/
> > * ./data: raw data for item
> > * ./metadata: info about item in undetermined format
>
> What would 'metadata' be in this context?
A description what it is. We might have raw kernel blobs for some
architectures. We might have Xen kernels, which require a nested Linux.
And all the information that need to go into the type 1 file and comes
from the package, like version, name, architecture.
Regards,
Bastian
--
She won' go Warp 7, Cap'n! The batteries are dead!
Reply to: