Path: csiph.com!1.us.feeder.erje.net!3.us.feeder.erje.net!2.eu.feeder.erje.net!feeder.erje.net!news.uzoreto.com!aioe.org!bofh.it!news.nic.it!robomod From: =?iso-8859-1?Q?J=F6rg?= Behrmann Newsgroups: linux.debian.kernel Subject: Re: RFC: bootloader/initramfs protocol v2 Date: Wed, 23 Nov 2022 10:50:01 +0100 Message-ID: References: X-Mailbox-Line: From debian-kernel-request@lists.debian.org Wed Nov 23 09:45:12 2022 Old-Return-Path: X-Amavis-Spam-Status: No, score=-4.298 tagged_above=-10000 required=5.3 tests=[BAYES_00=-2, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001] autolearn=no autolearn_force=no X-Policyd-Weight: using cached result; rate: -5.5 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Originating-IP: 160.45.66.12 X-Mailing-List: archive/latest/136202 List-ID: List-URL: List-Archive: https://lists.debian.org/msgid-search/Y33n/S/FZyNu7kIB@physik.fu-berlin.de Approved: robomod@news.nic.it Lines: 88 Organization: linux.* mail to news gateway Sender: robomod@news.nic.it X-Original-Date: Wed, 23 Nov 2022 10:29:33 +0100 X-Original-Message-ID: X-Original-References: Xref: csiph.com linux.debian.kernel:77173 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