You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This results in very poor performance transferring the file, especially over high-latency network connections (and compared to iPXE). It would be better to use the block size that was negotiated and used to transfer the shim EFI binary itself, which is often bigger (e.g. 1482 on a typical Ethernet segment).
The text was updated successfully, but these errors were encountered:
In this Wireshark capture, you can see the original firmware-driven request specifies a 1482 block size, but Shim specifies 512 when fetching Grub (and Grub is using a 1024 block size, which isn't quite optimal either).
According to the UEFI specification, there is nothing stopping you from passing NULL for the block size, then the firmware theoretically should use the largest block size it can.
However it is entirely possible that there is a reason for the hard-coded block size, perhaps that functionality doesnt work correctly on a large enough number of production firmwares to warrant this workaround.
Shim uses a hard-coded 512 byte block size for the TFTP (netboot) request to download the grub EFI file:
https://github.com/rhboot/shim/blob/main/netboot.c#L325
This results in very poor performance transferring the file, especially over high-latency network connections (and compared to iPXE). It would be better to use the block size that was negotiated and used to transfer the shim EFI binary itself, which is often bigger (e.g. 1482 on a typical Ethernet segment).
The text was updated successfully, but these errors were encountered: