Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #76948

Re: RFC: bootloader/initramfs protocol v2

Show key headers only | View raw

[Multipart message — attachments visible in raw view] - view raw

On Tue, 2022-11-01 at 21:29 +0100, Bastian Blank wrote:
> [Cc Ben as he gave feedback to the last iteration, Luca as he wanted
> something actionable]
> 
> Hi folks
> 
> As I abondened the last try and also learned some new things in the
> meantime, I'd like to discuss another try at re-organizing how Debian
> does boot loaders and initramfs.  This mail mostly tries to get the
> goals
> and requirements straight.
> 
> Please provide feedback.  Also for missing stuff.
> 
> Regards,
> Bastian

Thank you, this is great.

> ## 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?

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/
)

Given we are doing something new, it's very well worth to be fully
compatible with cross-distro standards so that we can leverage existing
toolchains.

> ## Requirements
> 
> - Read package files in /usr
> - Uses observed state, not changes provided by maintainer scripts
> - Dumb writes to /boot. No rename, no sym, hard links. Can use ref
>   links if possible.
> - Generate initramfs if needed, creates new entry if re-generated
> - Keep older stuff (like previous kernel, initramfs) for a short
> while
> - Possible to support multiple targets, like grub, zipl, flash-kernel
> - Multiple inputs, plain kernel, UKI, also in one version
> - Combinations of inputs, Xen+Linux
> - Completely outside of kernel package
> - Backward compatible support for stuff packaged in /boot
> - Use config for kernel command line
> 
> ## 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.

> - How to interface with boot loaders, just absorb all knowledge about
>   config and only run install tools if necessary (like with zipl as
>   block map based loader)?  grub might get support for BLS, at least
>   there exists a patch somewhere, that will make it easier, and we
> can
>   just iterate over config files defining one entry each.

Self-described and auto-discoverable images should be the primary mean.
For reference, the patch that adds support for the BLS to Grub is here:

https://github.com/osteffenrh/grub2/commit/d0c402c96159423242cf7b612773126ccc11a83b

UKIs will be proposed for Fedora, this should land as part of that work
and do a lot of the heavy lifting for us:

https://fedoraproject.org/wiki/Changes/Unified_Kernel_Support_Phase_1

In fact, if Grub can do UKIs, do we even need Type 1 entries (separate
textual config files) for anything at that point?

> ## Prior works
> 
> - Current Debian: change based, overwrites by dpkg in /boot,
> versioned
>   by ABI
> - systemd install-kernel: only BLS as target, which nothing used by
>   default in Debian can read
> More?

For reference, Debian images can be built using dracut + sd-boot +
kernel-install, images built with mkosi work like that:

https://github.com/systemd/mkosi

> ## File system layout
> 
> Some initial ideas about how stuff could look.
> 
> ### Boot file system (/boot)
> 
> This file system might be shared, so everything is somewhat
> referenced
> to the machine id.  This should be somewhat compatible with BLS (type
> 1).

This just dropped talking about lots of these concepts:

https://0pointer.net/blog/linux-boot-partitions.html

> * /boot/$machineid/
>   * ./grub/: config snippets, so we can do "no overwrite"
> 
> ### 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?

-- 
Kind regards,
Luca Boccassi

Back to linux.debian.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

RFC: bootloader/initramfs protocol v2 Bastian Blank <waldi@debian.org> - 2022-11-01 21:50 +0100
  Re: RFC: bootloader/initramfs protocol v2 Luca Boccassi <bluca@debian.org> - 2022-11-06 15:20 +0100
    Re: RFC: bootloader/initramfs protocol v2 Bastian Blank <waldi@debian.org> - 2022-11-23 10:00 +0100
  Re: RFC: bootloader/initramfs protocol v2 Jörg Behrmann <behrmann@physik.fu-berlin.de> - 2022-11-07 12:10 +0100
    Re: RFC: bootloader/initramfs protocol v2 Bastian Blank <waldi@debian.org> - 2022-11-23 09:10 +0100
      Re: RFC: bootloader/initramfs protocol v2 Jörg Behrmann <behrmann@physik.fu-berlin.de> - 2022-11-23 10:50 +0100

csiph-web