[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2 1/1] Add support for grub-emu to kexec Linux menu entries
From: |
Raymund Will |
Subject: |
Re: [PATCH v2 1/1] Add support for grub-emu to kexec Linux menu entries |
Date: |
Mon, 15 Aug 2022 15:16:15 +0200 |
User-agent: |
Mutt/1.10.1 (2018-07-13) |
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.)
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?
But, please, still leave sane defaults in the binary, for out-of-
the-box, no-config-changes-necessary usage, pretty please!
Would it be possible to re-evaluate the proposed patch with this
in mind?
PS: in light of my statements above, the "description" of this
patch definitely needs re-wording...
Thanks,
--
Raymund WILL rw@SUSE.de
SUSE Software Solutions Germany GmbH, Frankenstr. 146, D-90461 Nuernberg
Geschaeftsfuehrer: Ivo Totev, et al (HRB 36809, AG Nuernberg)