Re: [PATCH v2 1/1] Add support for grub-emu to kexec Linux menu entries

[Daniel Kiper]

On Tue, Aug 16, 2022 at 12:07:06PM -0400, Robbie Harwood wrote:
> Raymund Will <rw@suse.de> writes:
>
> > Hi,
> >
> > please let me try to add a bit of context and explain three IMHO
> > crucial points of the proposed patch.
> >
> > First, it is meant to work without any changes to config-files
> > on 'linux'-systems, simply by calling `grub-emu --kexec`.
> > And, called this way, it actually uses `systemctl kexec` exclusively
> > to instruct `systemd` to perform the "kexec"-reboot in a sane and
> > safe manner.
> >
> > Second, it only supports a very limited set of commands in `grub.cfg`,
> > as `grub-emu` can not implement the full functionality of a firmware-
> > loaded `grub` binary (like raw-device access) and it hinges massively
> > on proper `kexec`-support from the machine/firmware, so unfortunately
> > it won't be universally useful,
> >
> > Third, for use in a "pre-boot environment" (i.e. initrd/chroot), which
> > has full control over it's state, but no (fully) working `systemd`,
> > a call to `grub-emu --kexec --kexec` changes the behavior to allow a
> > fall-forward to `kexec -e`.  As a safe-guard for the adventurously
> > minded `systemctl kexec` is still tried first!
> >
> > This third point describes the use-case the original patch-set was
> > developed for and the second doesn't hurt (much) on the systems it
> > is deployed/used in the field.  But the first was found to be really
> > useful, especially on machines, which can reliably `kexec`, but are
> > dead slow through cold-boot (think "huge memory", "tons of devices")
> > and/or have "exotic" console setups ("3215" anybody?).  Note that,
> > as the boot configuration (namely `grub.cfg`) wasn't changed, regular
> > boot can't be affected by this short-cut (particularly, when `kexec`
> > might have failed).
> >
> > Granted, the duplication of `--kexec` to signify "force it", might
> > as well be spelled out as `--force-kexec` (or something similar).
> > (But that change will provoke inconsistencies during an indefinite
> > migration phase, where pre-boot images don't match binaries in the
> > root filesystem, notably, when rollback snapshots come into play.)
>
> Passing --kexec twice (or --force-kexec) doesn't appear to change
> anything in the versions of this patch I can easily find.  We could add

Yeah, I think Raymund is talking about a bit different version of the
patch. Raymund, could you provide us the one which has that features,
and potentially others, implemented?

> the behavior you're describing though - Daniel, would that help with
> your concerns about it?

I would prefer --force-kexec but if double --kexec is used in existing
environments I am OK with the latter. However, please document this
behavior in the GRUB's docs.

> > Config-overrides in `grub.cfg` in turn would be a nice addition, but
> > are relatively expensive to implement, as they'd probably need to be
> > parsed and split into an array for `grub_util_exec()`, right?
>
> Yes.  It's inevitably best-effort, especially if we can't depend on a
> working shell.

I would prefer to have "config-overrides" but if it requires tons of
work I am OK with existing implementation, +/- minor tweaks/fixes,
assuming its assumptions and limitations are properly documented.

> > But, please, still leave sane defaults in the binary, for out-of-
> > the-box, no-config-changes-necessary usage, pretty please!

As I said earlier, I am (mostly) OK with current defaults.

> > Would it be possible to re-evaluate the proposed patch with this
> > in mind?

Yep!

Daniel