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

On Thu, Feb 25, 2021 at 6:21 AM Stefan Haberland <[email protected]> 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