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