Bug#983486: zipl: allow other packages to provide config snippets

On Thu, 25 Feb 2021, 07:51 Christian Borntraeger, <[email protected]>
wrote:

>
>
> On 24.02.21 23:40, dann frazier wrote:
> > Source: s390-tools
> > Version: 2.15.1-2
> >
> > I'm one of the maintainers of kdump-tools, which has a need to manipulate
> > the kernel command line parameters in boot loader configurations.
> > Currently zipl provides no way to do this without modifying
> > /etc/zipl.conf directly. It would be helpful if there was e.g. an
> > /etc/zipl.conf.d/ interface for dropping in additional configuration.
> >
> > As an example, GRUB provides an /etc/default/grub.d/ directory, which
> > allows us to drop in a file like this:
> >
> > $ cat /etc/default/grub.d/kdump-tools.cfg
> > GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT
> crashkernel=384M-:128M"
> >
> > One idea of how to implement this would be to do something similar to
> > GRUB and ship a tool (say, update-zlib) that generates a static
> > /etc/zlib.conf as directed by a set of shell variables (say
> > /etc/default/zlib). It could then process a directory of snippets (say
> > /etc/default/zlib.d/*) allowing other packages to tweak/override the
> > configuration defined by those variables.
> >
> > I realize that while that this design would have an upgrade problem
> > for existing users, but perhaps we could provide an opt-in-only
> > migration path.
> >
>
> Newer zipls also provide a way to specify BLS entries
> https://systemd.io/BOOT_LOADER_SPECIFICATION/
> would that help you?
>

grub.d snippets are typically used to extend kernel cmdline arguments for
all entries. Is there variable substitution available? As far as I
understand it BLS is purely declarative and there is no ability to say "and
append this value to all entries", "and append that value to all entries".
>From locations that have drop-ins from packaged software and/or user.

Also in Debian / Ubuntu we only generate two static entries in zipl.conf
for the current and last kernel. BSL might be useful for us to list all
installed / bootable kernels. But not sure how to reconcile that with
arguments in zipl.conf.


If something like a zipl.conf.d is still considered valueable, maybe
> open an issue for the
> upstream project https://github.com/ibm-s390-linux/s390-tools/issues
>