Re: RFC: bootloader/initramfs protocol v2
Hi Bastian!
On Wed, Nov 23, 2022 at 08:53:10AM +0100, Bastian Blank wrote:
> On Mon, Nov 07, 2022 at 11:40:46AM +0100, Jörg Behrmann wrote:
> > On Tue, Nov 01, 2022 at 09:29:07PM +0100, Bastian Blank wrote:
> > > ## Prior works
> > >
> > > [..]
> > > - systemd install-kernel: only BLS as target, which nothing used by
> > > default in Debian can read
> > > [..]
> >
> > To maybe clarify this a bit: While kernel-install does target BLS primarily, it
> > has support for differing layouts via the KERNEL_INSTALL_LAYOUT environment
> > variable (set via layout= in {/usr/lib,/etc}/kernel/install.conf).
>
> Okay. However no multi-selection.
>
I'm not sure I fully understand what you mean, but I think what you mean is,
that you would like to be be able to generate stuff in /boot for multiple
different values of KERNEL_INSTALL_LAYOUT, e.g. boot loader spec and something
else.
While the variable itself is single-valued, kernel-install can of course be run
multiple times for different values of KERNEL_INSTALL_LAYOUT or with different
configs wholesale (kernel-install reads environment variables from
/etc/kernel/install.conf, but this can be configured via the environment
variable KERNEL_INSTALL_CONF_ROOT).
I'd be grateful if you could flesh out the scenario for multi-selection a bit,
because the systems I think of will usually have a single way they are booted
and while being able to switch between different setups is important for
development work, I'm not sure whether this case common in production
deployments.
> > kernel-install scripts are also just that, executables with two CLI entry points
> > (add and remove) and a set of fixed environment variables that they
> > receive. Currently all of this is written in POSIX shell (compatible with
> > dash) - they can be made to do everything.
>
> Add and remove are not enough for what I would like to have.
>
Fair enough. I'd be grateful, though, for a bit more information on what your
plan is, because, looking at the goals section of your initial mail, I think
that these could be achieved within this framework.
> And I'm
> really not in the mood to try that in POSIX shell.
>
Fair enough, I'm not a lover of POSIX shell myself. :) While kernel-install
itself is written in POSIX shell (for compatibility with dash, I think, because
it initially was bash and used bashisms and was ported later), the install
scripts can be whatever you want - even compiled binaries.
The API is described in the kernel-install manpage, although maybe a bit
haphazardly, and consists of arguments the scripts/binaries in
{/usr/lib,/etc}/install.d will be called with, environment variables they can
expect and exit codes that re understood.
> Is it even able to
> make sure stuff is actually written on the disk?
This question has multiple answers. I'm not sure whether anybody does this yet,
but you can add a script to run sync at the end and report an error if that was
unsuccessful. Also, kernel-install does provide a temporary staging directory,
so you can output everything there and have it copied to /boot at the end and
keep the interactions with dumb filesystems to a minimum.
> > kernel-install and BLS support a bit more than the machine ID here, The relevant
> > keyword to look for in the kernel-install manpage and BLS is "entry-token".
> > This was added for golden master setups, because the machine ID will probably
> > only generated on first boot, but the initrd would be generated beforehand.
>
> And I assume it got no way to migrate from an pre-defined entry-token to
> the machine ID later on, which would be kind of useful to convert a
> golden image into a real system where you can add unrelated systems
> later.
>
The entry-token is just the content of the /etc/kernel/entry-token file, so it
can be reset later and if no entry token exists it falls back to machine id,
IMAGE_ID and ID in the os-release file in that order.
best regards,
Jörg
Reply to: