QEMU UEFI VMs fail to request the /grub/grub.cfg over HTTP when booting with UEFI HTTP

This bug blocks the progress of completion of bug: https://bugs.launchpad.net/maas/+bug/1820983

Seems that SUSE supports this in their grub because its well documented on their site:

https://en.opensuse.org/UEFI_HTTPBoot_Server_Setup

As a first step I'd look into whether grub is able to correctly get an IP from DHCP. I wonder if the client class string confuses it.

Could you please take packet captures of the boot attempt? We could then have a look at the whole thing and compare with grub code to see what happens?

Attached is the packet capture.

After additional testing with hardware (instead of in VMs), it looks like things are working fine on Lenovo hardware.

I managed to get access to a Lenovo SR670 server. I deployed it from an existing MAAS, along with a second server (some random node we'll call http-server) to be an HTTP server, since I couldn't update the existing MAAS server to the right commits.

So; http-server was a deployed node from MAAS, on which I simply installed 'apache2'. On that server, I removed index.html from /var/www/html and instead put in bootx64.efi, grubx64.efi, a grub directory with a custom grub.cfg file, and a directory structure copied from MAAS to have a kernel and initrd available. No further actions are required on http-server.

The existing MAAS server was slightly modified to point to the HTTP server: edited /var/lib/maas/dhcpd.conf to add the following snippet (same as in description with the URI updated for http-server):

"""
} elsif option arch = 00:0f {
    # uefi_amd64_http
    filename "http://http-server:80/bootx64.efi";
    option vendor-class-identifier "HTTPClient";
} elsif option arch = 00:10 {
    # uefi_amd64_http
    filename "http://http-server:80/bootx64.efi";
    option vendor-class-identifier "HTTPClient";
"""

Next; the Lenovo SR670 was configured to boot from the network using UEFI HTTP Boot (see https://lenovopress.com/lp0736.pdf); and restarted with a One-time Boot Option; where HTTP Boot was selected.

On the BMC for the Lenovo SR670; one can watch the system boot, request files from HTTP, and potentially show a grub menu or otherwise follow the instructions for booting listed in grub.cfg on http-server.

Watching on http-server, one can see in the apache access.log for requests from the Lenovo SR670:

10.193.36.45 - - [18/Apr/2019:16:10:36 +0000] "HEAD /bootx64.efi HTTP/1.1" 200 211 "-" "UefiHttpBoot/1.0"
10.193.36.45 - - [18/Apr/2019:16:10:36 +0000] "GET /bootx64.efi HTTP/1.1" 200 1335027 "-" "UefiHttpBoot/1.0"
10.193.36.45 - - [18/Apr/2019:16:10:37 +0000] "GET //grubx64.efi HTTP/1.1" 200 1164875 "-" "UefiHttpBoot/1.0"
10.193.36.45 - - [18/Apr/2019:16:10:37 +0000] "GET /grub/x86_64-efi/command.lst HTTP/1.1" 404 464 "-" "GRUB 2.02-2ubuntu8.13"
10.193.36.45 - - [18/Apr/2019:16:10:37 +0000] "GET /grub/x86_64-efi/fs.lst HTTP/1.1" 404 459 "-" "GRUB 2.02-2ubuntu8.13"
10.193.36.45 - - [18/Apr/2019:16:10:37 +0000] "GET /grub/x86_64-efi/crypto.lst HTTP/1.1" 404 463 "-" "GRUB 2.02-2ubuntu8.13"
10.193.36.45 - - [18/Apr/2019:16:10:37 +0000] "GET /grub/x86_64-efi/terminal.lst HTTP/1.1" 404 465 "-" "GRUB 2.02-2ubuntu8.13"
10.193.36.45 - - [18/Apr/2019:16:10:37 +0000] "GET /grub/grub.cfg HTTP/1.1" 200 338 "-" "GRUB 2.02-2ubuntu8.13"
10.193.36.45 - - [18/Apr/2019:16:10:37 +0000] "GET /grub/grub.cfg-default-amd64 HTTP/1.1" 200 278 "-" "GRUB 2.02-2ubuntu8.13"

This makes me conclude that grub2 does what it is supposed to, and thus any issues might be due to limitations in the EDK2 implementation of HTTP Boot -- possibly some registers or EFI variables are not being updated appropriately. Reassigning to edk2.