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
signature.asc
Description: This is a digitally signed message part
