the PXE client actually gets input from a variety of packets (DHCP server, DHCP proxy server, and boot server). All of these can contain various options. Section 2.4.1 specifies the precedence order between them.

The existing grub code was entirely ignores the options specified in the boot server response. This caused the examples below to fail. The patch I wrote fixed this.

Cheers! -Tyson

PS: The patch was based on the latest version of grub2 in debian experimental at the time I wrote it because the first thing I tried when it didn't work was getting the latest version. I had assumed this was relatively up-to-date.

Even when posted this patch was for an outdated version of GRUB and its updating isn't trivial. Also I also fail to see the rationale behind this patch. There is only one response on the network. Where does this other packet come from?

When PXE booting this can result in missed PXE options (as the boot server can supplement them) and grub not getting the IP address for the TFTP server that served the core image (as this information may not even be in the DHCP package).

I've put together a patch that adds parsing the boot server packet as well to make sure all the required information gets extracted. It gives precedence to DHCP PXE options (as required by the PXE spec) and boot server IP addresses/file names.

An example of a situation that doesn't work before this patch is running dnsmasq on a local 192.168.1.x network in proxy mode along side a regular DHCP server that doesn't provide booting services. The dnsmasq parameters are