All of lore.kernel.org
 help / color / mirror / Atom feed
From: Robbie Harwood <rharwood@redhat.com>
To: "Renaud Métrich" <rmetrich@redhat.com>, grub-devel@gnu.org
Cc: "Renaud Métrich" <rmetrich@redhat.com>
Subject: Re: [PATCH v4 2/2] efi: new 'eficonnect' command
Date: Thu, 01 Sep 2022 12:52:02 -0400	[thread overview]
Message-ID: <jlgzgfjujf1.fsf@redhat.com> (raw)
In-Reply-To: <20220901072854.152640-2-rmetrich@redhat.com>

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

Renaud Métrich <rmetrich@redhat.com> writes:

> When efi.quickboot is enabled on VMWare (which is the default for
> hardware release 16 and later), it may happen that not all EFI devices
> are connected. Due to this, browsing the devices in make_devices() just
> fails to find devices, in particular disks or partitions for a given
> disk.
> This typically happens when network booting, then trying to chainload to
> local disk (this is used in deployment tools such as Red Hat Satellite),
> which is done through using the following grub.cfg snippet:
> -------- 8< ---------------- 8< ---------------- 8< --------
> unset prefix
> search --file --set=prefix /EFI/redhat/grubx64.efi
> if [ -n "$prefix" ]; then
>   chainloader ($prefix)/EFI/redhat/grubx64/efi
> ...
> -------- 8< ---------------- 8< ---------------- 8< --------
>
> With efi.quickboot, none of the devices are connected, causing "search"
> to fail. Sometimes devices are connected but not the partition of the
> disk matching $prefix, causing partition to not be found by
> "chainloader".
>
> This patch introduces a new "eficonnect pciroot|scsi|all" command whic
> recursively connects all EFI devices starting from a given controller
> type:
> - if 'pciroot' is specified, recursion is performed for all PCI root
>   handles
> - if 'scsi' is specified, recursion is performed for all SCSI I/O
>   handles (recommended usage to avoid connecting unwanted handles which
>   may impact Grub performances)
> - if 'all' is specified, recursion is performed on all handles (not
>   recommended since it may heavily impact Grub performances)
>
> Typical grub.cfg snippet would then be:
> -------- 8< ---------------- 8< ---------------- 8< --------
> eficonnect scsi
> unset prefix
> search --file --set=prefix /EFI/redhat/grubx64.efi
> if [ -n "$prefix" ]; then
>   chainloader ($prefix)/EFI/redhat/grubx64/efi
> ...
> -------- 8< ---------------- 8< ---------------- 8< --------
>
> The code is easily extensible to handle other arguments in the future if
> needed.

(The first patch doesn't apply to upstream - I assume it was sent by
accident?)

I wanted to call out here that we're already shipping this command in
RHEL under the name in previous versions (i.e., connectefi).  Renaud,
you probably know better than I do how much difficulty would be involved
in changing that for customers, so I'll defer to you on whether that's
okay.

Be well,
--Robbie

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

  reply	other threads:[~2022-09-01 16:52 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-01  7:28 [PATCH v4 1/2] lsefi: fixed memory leaks Renaud Métrich
2022-09-01  7:28 ` [PATCH v4 2/2] efi: new 'eficonnect' command Renaud Métrich
2022-09-01 16:52   ` Robbie Harwood [this message]
2022-09-05  0:21 ` [PATCH v4 1/2] lsefi: fixed memory leaks Glenn Washburn

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=jlgzgfjujf1.fsf@redhat.com \
    --to=rharwood@redhat.com \
    --cc=grub-devel@gnu.org \
    --cc=rmetrich@redhat.com \
    /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.