On Thu, Feb 25, 2021 at 6:21 AM Stefan Haberland <s...@linux.ibm.com> wrote: > > Am 25.02.21 um 08:30 schrieb Christian Borntraeger: > > > > 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? > > > > 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 > > 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
