Comment 5 for bug 2033430

I sought insight from Red Hat's grub maintainers, and they suggested building a EFI grub payload which injects a config to obtain some debugging.

That, itself didn't quite work so well, but I did add some commands to gather some additional data:

Specifically:

set=debug=efinet,dhcp
net_ls_routes
net_ls_addr
net_dhcp
net_ls_addr
net_ls_routes
normal

which got me:

"""
Fetching Netboot Image
efinet0:local 10.0.0.0/8 efinet0

efinet0 52:54:00:fd:56:02 10.1.0.58

efinet0:dhcp 52:54:00:fd:56:02 10.1.0.58

efinet0 52:54:00:fd:56:02 10.1.0.58

efinet0:dhcp:default 0.0.0.0/0 gw 10.1.0.1

efinet0:dhcp:local 10.1.0.0/26 efinet0:dhcp

efinet0:local 10.0.0.0/8 efinet0

GNU GRUB version 2.06

   Minimal BASH-like line editing is supported. For the first word, TAB

   lists possible command completions. Anywhere else TAB lists possible

   device or file completions.

grub>"""

The interesting aspect is even after re-dhcping, we observe the same behavior, the image goes on trying to arp on 10.0.0.0/8 even though the dhcp payload indicates a smaller network.

Additionally, I pulled the fedora 38 binaries for shim/grub and loaded them and encountered the same behavior in terms of grub is now just sitting trying to arp for the tftp server's address as if it is locally attached instead of through the default gateway/router.

Looking at the grub include/grub/net.h file, the only options from the response payload which are used with dnsmasq, but which are not present with OVN is GRUB_NET_BOOTP_HOSTNAME (option 12) and GRUB_NET_BOOTP_DOMAIN (option 15), yet they are not really used either. The other major difference in used options appears to be the GRUB_NET_BOOTP_DNS option, which does get a bogus (127.0.0.1) response from OVN.

This makes no sense.