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?

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

Newer zipls also provide a way to specify BLS entries
https://systemd.io/BOOT_LOADER_SPECIFICATION/
would that help you?

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

Am 25.02.21 um 08:30 schrieb Christian Borntraeger:

Hi,

we currently also have an item in the work that works comparable to
grubs environment block.
Depending on the specific problem that this conf.d directory should
solve, this could also be of help.

Am 25.02.21 um 08:30 schrieb Christian Borntraeger:

Hi,

we currently also have an item in the work that works comparable to
grubs environment block.
Depending on the specific problem that this conf.d directory should
solve, this could also be of help.

Hi Christian,

  I'm not sure sharing a writeable variable store with firmware (my
understanding of the env block) would get us there - we really just
need to be able to manipulate the default set of kernel command line
arguments. fyi, here's a link to the discussion that prompted this
bug:
https://salsa.debian.org/debian/kdump-tools/-/merge_requests/5#note_229647

  -dann

Hi Christian,

  I'm not sure sharing a writeable variable store with firmware (my
understanding of the env block) would get us there - we really just
need to be able to manipulate the default set of kernel command line
arguments. fyi, here's a link to the discussion that prompted this
bug:
https://salsa.debian.org/debian/kdump-tools/-/merge_requests/5#note_229647

  -dann

On Thu, 25 Feb 2021, 07:51 Christian Borntraeger, <borntraeger@de.ibm.com> wrote:

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

As Stefan Haberland pointed out, we are currently working on environment support. This is probably good enough for
that use case. Not sure how far this has progressed, though.


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.