On Thu, 25 Feb 2021, 07:51 Christian Borntraeger, <borntrae...@de.ibm.com> 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 >
