All of lore.kernel.org
 help / color / mirror / Atom feed
From: Robbie Harwood <rharwood@redhat.com>
To: Raymund Will <rw@suse.de>, Daniel Kiper <dkiper@net-space.pl>
Cc: grub-devel@gnu.org, John Jolly <jjolly@suse.com>,
	Javier Martinez Canillas <javierm@redhat.com>
Subject: Re: [PATCH v2 1/1] Add support for grub-emu to kexec Linux menu entries
Date: Tue, 16 Aug 2022 12:07:06 -0400	[thread overview]
Message-ID: <jlg8rnocgut.fsf@redhat.com> (raw)
In-Reply-To: <20220815131615.GA9135@suse.de>

[-- Attachment #1: Type: text/plain, Size: 2924 bytes --]

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
the behavior you're describing though - Daniel, would that help with
your concerns about it?

> 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.

> 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...

Any interest in doing that, or should I?

Be well,
--Robbie

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 861 bytes --]

  reply	other threads:[~2022-08-16 16:07 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-19 20:39 [PATCH v2 1/1] Add support for grub-emu to kexec Linux menu entries Robbie Harwood
2022-08-03 15:26 ` Daniel Kiper
2022-08-08 18:58   ` Robbie Harwood
2022-08-11 18:08     ` Daniel Kiper
2022-08-15 13:16       ` Raymund Will
2022-08-16 16:07         ` Robbie Harwood [this message]
2022-08-20 11:23           ` Daniel Kiper
2022-08-23 21:03             ` Robbie Harwood
2022-08-08 21:43 ` Vladimir 'phcoder' Serbinenko
2022-08-11 18:02   ` Robbie Harwood
2022-08-11 18:13   ` Daniel Kiper

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=jlg8rnocgut.fsf@redhat.com \
    --to=rharwood@redhat.com \
    --cc=dkiper@net-space.pl \
    --cc=grub-devel@gnu.org \
    --cc=javierm@redhat.com \
    --cc=jjolly@suse.com \
    --cc=rw@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.