Fails when PXE booting

[ppatpat]

Trying to PXE boot rhel-8.3-x86_64-dvd.iso

PXE server = Serva 4.4.0 PXE environment = proxyDHCP

Test 1 NBP=\NWA_PXE\rhel-8.3-x86_64-dvd\EFI\BOOT\BOOTX64.EFI Log:

[02/25 13:23:32.530] TFTP Inf: Read file <\NWA_PXE\rhel-8.3-x86_64-dvd\EFI\BOOT\BOOTX64.EFI>. Mode octet
[02/25 13:23:32.582] TFTP Err: Peer returns ERROR <User aborted the transfer> -> aborting transfer
[02/25 13:23:32.582] TFTP Inf: Read file <\NWA_PXE\rhel-8.3-x86_64-dvd\EFI\BOOT\BOOTX64.EFI>. Mode octet
[02/25 13:23:33.760] TFTP Inf: <\NWA_PXE\rhel-8.3-x86_64-dvd\EFI\BOOT\BOOTX64.EFI>: sent blks=848 blkSz=1468, Total 1244488 bytes in 1s, err recovery=0 
[02/25 13:23:33.789] TFTP Inf: Read file <grubx64.efi>. Mode octet
[02/25 13:23:33.789] TFTP Err: File <grubx64.efi> : error 2 in CreateFile; The system cannot find the file specified.

While BOOTX64.EFI (shim) is correctly TFTP transferred when run it fails to properly TFTP request grubx64.efi; it asks for while it should've requested <\NWA_PXE\rhel-8.3-x86_64-dvd\EFI\BOOT\grubx64.efi> instead.

Test 2 NBP=\NWA_PXE\rhel-8.3-x86_64-dvd\EFI\BOOT\BOOTX64.EFI Just for testing now we copy grubx64.efi to \grubx64.efi (TFTP root); this cannot be done in production as different assets would all try to get grub2 from the same root location. Log:

[02/25 13:29:28.604] TFTP Inf: Read file <\NWA_PXE\rhel-8.3-x86_64-dvd\EFI\BOOT\BOOTX64.EFI>. Mode octet
[02/25 13:29:28.656] TFTP Err: Peer returns ERROR <User aborted the transfer> -> aborting transfer
[02/25 13:29:28.656] TFTP Inf: Read file <\NWA_PXE\rhel-8.3-x86_64-dvd\EFI\BOOT\BOOTX64.EFI>. Mode octet
[02/25 13:29:30.265] TFTP Inf: <\NWA_PXE\rhel-8.3-x86_64-dvd\EFI\BOOT\BOOTX64.EFI>: sent blks=848 blkSz=1468, Total 1244488 bytes in 2s, err recovery=0 
[02/25 13:29:30.292] TFTP Inf: Read file <grubx64.efi>. Mode octet
[02/25 13:29:37.107] TFTP Inf: <grubx64.efi>: sent blks=3698 blkSz=512, Total 1893320 bytes in 7s, err recovery=0 

Now grubx64.efi is found, TFTP transferred, and chainloaded and the client displays: Fetching Network Image but there's not any TFTP request and after a long delay grubx64.efi gives up providing a grub prompt then we run >set

grubx64.efi is taking the default router/server as "next-server"; while this is true in a pure DHCP server environment it is FALSE in a proxyDHCP environment; this variable must correctly take its value from the one included in the proxyDHCP offer. Because of this issue The TFTP server located at 192.168.77.1 never receive any TFTP request and the whole booting process aborts. We can also see the PXE path is considered /EFI/BOOT In this case grub was booted from the root \ and shim was booted from \NWA_PXE\rhel-8.3-x86_64-dvd\EFI\BOOT\ then it seems grub2 is hard-coded to retrieve its configuration from \EFI\BOOT without considering the relative path. This is not correct Grub2 and Shim should parse their invocation path and act accordingly when retrieving configuration files or chainloading to other EFI components.

Summarizing: Shim: It seems it does not properly handles relative path on TFTP requests Grub2: idem Shim and also does not properly handle proxyDHCP environments.

best, Patrick

[stevenshiau]

Yes. However, it seems this issue has never been fixed. Some same/similar issue reports about shim in the past: https://github.com/rhboot/shim/issues/111 https://github.com/rhboot/shim/issues/137 https://github.com/rhboot/shim/issues/165

As for grub, https://lists.gnu.org/archive/html/grub-devel/2016-04/msg00051.html https://savannah.gnu.org/bugs/index.php?55636

Steven

[ppatpat]

Thanks for adding the links related to this long time not solved issue

[Steinliiippp]

I have the same problem. Are there any updates on this topic or plans for the future?

Is this at least the fix for shim: https://github.com/rhboot/shim/commit/5f4fd5364109c80934b7837255ddde61f572fd69 It was mentioned in the release 15: https://github.com/rhboot/shim/releases/tag/15

[chaitanyalala]

Hello @Steinliiippp and others, is there any planned fix? Is https://github.com/rhboot/shim/commit/5f4fd5364109c80934b7837255ddde61f572fd69 a potential fix? I am hitting this in my setup as well.