On Tue, Jun 10, 2025 at 11:54:25AM +0200, Renaud Métrich via Grub-devel wrote:
> When network booting is used, trying to chainload to the local disk
> (which is used in deployment tools such as Red Hat Satellite) may fail
> when searching for the boot loader, e.g. /EFI/redhat/shimx64.efi:
> the boo
Please see inline, thanks for reviewing.
Le 6/10/25 à 7:36 PM, sudhakar a écrit :
On 2025-06-10 15:24, Renaud Métrich via Grub-devel wrote:
When network booting is used, trying to chainload to the local disk
(which is used in deployment tools such as Red Hat Satellite) may fail
when searching f
On 2025-06-10 15:24, Renaud Métrich via Grub-devel wrote:
When network booting is used, trying to chainload to the local disk
(which is used in deployment tools such as Red Hat Satellite) may fail
when searching for the boot loader, e.g. /EFI/redhat/shimx64.efi:
the boot loader file is listed, bu
When network booting is used, trying to chainload to the local disk
(which is used in deployment tools such as Red Hat Satellite) may fail
when searching for the boot loader, e.g. /EFI/redhat/shimx64.efi:
the boot loader file is listed, but not readable, because UEFI DISK I/O
and/or SCSI DISK I/O d
Thank you for explaining. I would suggest adding some maximum number of
iterations to prevent an infinite loop if perhaps the EFI is misbehaving
inside the "loop:" section. Not sure the right limit, but there must be
some maximum allowed assuming worst case conditions or maximum allow based
on pr
Hi Daniel,
Sorry I missed your email, please see inline.
Le 3/21/25 à 3:51 PM, Daniel Kiper a écrit :
On Wed, Mar 19, 2025 at 01:47:57PM +0100, Renaud Métrich via Grub-devel wrote:
When network booting is used, trying to chainload to the local disk
(which is used in deployment tools such as Re
Hi Andrew,
Sorry I missed your email.
IMHO the "goto" is useful here to be able to loop again at same "s"
level: we actually want to redo the operation without going one step
further.
Let me explain with an example.
We want to connect PCIROOT, then PCI level, then SCSI I/O level.
There is
On Wed, Mar 19, 2025 at 01:47:57PM +0100, Renaud Métrich via Grub-devel wrote:
> When network booting is used, trying to chainload to the local disk
> (which is used in deployment tools such as Red Hat Satellite) may fail
> when searching for the boot loader, e.g. /EFI/redhat/shimx64.efi:
> the boo
Hello,
I just had one question about the use of the 'goto' and the 'loop'
label in the below code... see my question below the 'loop' label.
Let me know if I just misunderstand or am wrong.
Thank you!
Andrew
On Wed, Mar 19, 2025 at 7:53 AM Renaud Métrich via Grub-devel
wrote:
>
> When network b
When network booting is used, trying to chainload to the local disk
(which is used in deployment tools such as Red Hat Satellite) may fail
when searching for the boot loader, e.g. /EFI/redhat/shimx64.efi:
the boot loader file is listed, but not readable, because UEFI DISK I/O
and/or SCSI DISK I/O d
It could indeed be done automatically, but not always, because by
default it's not needed and also because connecting EFI devices can be
long apparently.
So I fear that as soon as a "search" would fail, triggering the
connection internally will slow down the boot, even though the search
was s
The need to connect looks like an internal implementation detail. Can
we treat it as such and connect when needed automatically rather than
having an extra configuration knob?
On Fri, Jun 28, 2024 at 2:14 PM Renaud Métrich wrote:
>
> When efi.quickboot is enabled on VMWare (which is the default f
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
Hi Glenn,
Thanks for reviewing this.
I reworked the feature based on your comments:
- used grub_list
- renamed into "eficonnect"
- added "all" option
See "[PATCH v4 1/2] lsefi: fixed memory leaks (unchanged)"
and "[PATCH v4 2/2] efi: new 'eficonnect' command"
Renaud.
Le 8/28/22 à 21:51, G
On Tue, 15 Feb 2022 14:05:22 +0100
Renaud Métrich wrote:
> 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,
On Tue, 15 Feb 2022 14:05:20 +0100
Renaud Métrich wrote:
> This set of patches fixes a memory leak in 'lsefi' command and
> introduces a new 'connectefi pciroot|scsi' command which recursively
> connects the corresponding EFI handles.
I think both of these patches would be great to get in before
Please ignore, deprecated by "efi: new 'connectefi' command" (v3).
Sorry for the mess.
Le 2/14/22 à 14:23, Renaud Métrich a écrit :
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
a
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
This set of patches fixes a memory leak in 'lsefi' command and
introduces a new 'connectefi pciroot|scsi' command which recursively
connects the corresponding EFI handles.
This is required on VMWare with efi.quickBoot enabled when chainloading
to grub on the harddisk from a network boot, otherwise
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
20 matches
Mail list logo
