Shim unable to locate grubx64 in PXE boot mode when grubx64 is stored in a different file path.

[Alberto-David-Perez-Guevara]

Shim unable to locate grubx64 in PXE boot mode when grubx64 is stored in a different file path. SETUP:

I have a system attempting to use shim (tried rel 15.5 & 15.4 with same results) to do PXE boot of Linux OS distro from a PXE server. both bootx64.efi (shim) & grubx64.efi are in the same directory. The chosen directory for this experiment is for example: MaintenanceOS\ESXi_LinuxISO\bootx64.efi MaintenanceOS\ESXi_LinuxISO\grubx64.efi

RESULT:

system is able able to connect using to PXE server and fetch the Shim i.e. bootx64.efi file. However system then Hangs and displays the following information in the console:

start_image() returned TFTP Error ASSERT [DxeCore] d:\a_work\1\s\development\biossource\MdeModulePkg\Core\Dxe\Mem\Pool.c(624): CR has Bad Signature

INFO & Logs:

from our network trace we see the following TFTP packets for fetching the shim and grub efi files as follows:

for shim: Trivial File Transfer Protocol Opcode: Read Request (1) Source File: _\MaintenanceOS\ESXi_LinuxISO_bootx64.efi

for grub: Trivial File Transfer Protocol Opcode: Read Request (1) Source File:grubx64.efi

DEBUG:

It seems the main issue is that Shim is unable to correctly deduce the file path, on this particular boot option Shim behaves as follows,

efi_main(entry point)-> shim_init-> parse_load options-> set_second_stage-> generate_path_from_image_path -> start_image->parseDhcp4.

adding Debug prints we can see the error more closely

`DEBUG parse_load_options -> bootpath: PciRoot(9)/Pci(0x0,0x0)/Pci(0x0,0x0)/Mac(XXYYZZ)/IPv4(0.0.0.0,0,DHCP)/\MaintenanceOS\ESXi_LinuxISO\bootx64.efi

DEBUG set_second_stage -> second_stage: \grubx64.efi

DEBUG generate_path_from_image_path -> ImagePath: \grubx64.efi | PathName: (null)

DEBUG start_image -> PathName: PciRoot(9)\Pci(0x0,0x0)\Pci(0x0,0x0)\Mac(XXYYZZ,1)\IPv4(0.0.0.0,0,DHCP)\MaintenanceOS\ESXi_LinuxISO\grubx64.efi

DEBUG parseDhcp4 -> ProxyOfferReceived: 1 | BootpBootFile:

DEBUG parseDhcp4 -> PxeReplyReceived: 1

BootpBootFile1: .....................

BootpBootFile2:

DEBUG parseDhcp4 len:0 BootpBootFile:..................... fullpath: .....i......8

DEBUG start_image -> parseNetbootinfo: Success

DEBUG FetchNetbootimage status:TFTP Error full_path: .....i......8

DEBUG start_image -> FetchNetbootimage: TFTP Error

Unable to fetch TFTP image: TFTP Error

start_image() returned TFTP Error`

it seems that on PXE Boot, the file path that gets resolve by parsing the handle is entirely discarded PathName: PciRoot(9)\Pci(0x0,0x0)\Pci(0x0,0x0)\Mac(XXYYZZ,1)\IPv4(0.0.0.0,0,DHCP)\MaintenanceOS\ESXi_LinuxISO\grubx64.efi and instead shim attempts to parse the file path from the last DHCP packet receive.

In this case the packets from the PXE server do not contain this information, and the code simply discards this fail path resolves to its default value "grubx64.efi".

SOLUTIONS:

• Would it be a correct patch that in the case of a missing file path on DHCP packet to attempt to fetch the grubx64 file from the file path resolved from the file handle instead?
• Would this behavior be in line with current shim architecture?

PATCH INFO

I created a debug patch to dump info, the original branch is

commit f2c598bb2218da966872ba3e0c6e7e830dca6ef0 (HEAD, tag: 15.5, origin/shim-15.5) Author: Robbie Harwood rharwood@redhat.com Date: Tue Feb 15 13:06:21 2022 -0500

Update to version 15.5

Mark this officially as shim 15.5

Signed-off-by: Robbie Harwood <rharwood@redhat.com>

attached is my debug patch to extract this information Shim_debug_patch.zip

[Alberto-David-Perez-Guevara]

Hi Guys! any update on this, would it be ok to use image handle file path instead of DHCP filepath ? for this scenario?

[p3ck]

I'm hitting this issue as well. We (DCI team) test multiple RHEL distros from the same tftp server and need the ability to boot the different versions of grubx64.efi that come with each distro for verification.

Thanks