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.

** Package changed: grub2 (Ubuntu) => edk2 (Ubuntu)

** Summary changed:

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

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1822007

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/edk2/+bug/1822007/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to