Bug 1750106

Summary:	UEFI HTTP boot does not grab config file
Product:	[Fedora] Fedora	Reporter:	Patrick Uiterwijk <puiterwijk>
Component:	grub2	Assignee:	Peter Jones <pjones>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	fmartine, lkundrak, pbrobinson, pjones
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2019-09-27 09:27:28 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1269538

Description Patrick Uiterwijk 2019-09-08 11:46:03 UTC

Description of problem:
When using UEFI HTTP booting, grub does not try to request the grub.cfg, and just falls back to the grub shell.

Version-Release number of selected component (if applicable):
grub2-2.04-1.fc32

How reproducible:
Consistent

Steps to Reproduce:
1. Put grub on HTTP url
2. Configure device to HTTP boot from that URL

Actual results:
Grub loads, but then no further requests for config files are performed, and it drops into the grub shell.

Expected results:
Grub should attempt to laod grub.cfg from the same location as the EFI was loaded from (works on Grub2 2.02 from Fedora31).

Additional info:
I did a packet capture, and after grubx64.efi is retrieved over the network, there are no further packets sent over the network, leading me to believe no requests are actually sent.
When I run "configfile" in the shell without further arguments, it indicates it tried to request the file, but got EFI error 0x2 (EFI_INVALID_PARAMETER).

Comment 1 Javier Martinez Canillas 2019-09-13 09:52:28 UTC

Hello Patrick,

I've tried to reproduce this issue but it's working for me with the following packages:

edk2-ovmf-20190501stable-4.fc30.noarch
dhcp-server-4.3.6-37.fc30.x86_64
httpd-2.4.41-1.fc30.x86_64

And the EFI binaries from:

shim-x64-15-8.x86_64.rpm
grub2-efi-x64-cdboot-2.04-1.fc32.x86_64.rpm

Maybe I'm doing something wrong? This is how I tested:

$ mkdir -p /var/www/html/EFI/BOOT

$ wget -q https://kojipkgs.fedoraproject.org//packages/shim/15/8/x86_64/shim-x64-15-8.x86_64.rpm && \
  rpm2cpio shim-x64-15-8.x86_64.rpm | cpio -idm && \
  cp boot/efi/EFI/BOOT/BOOTX64.EFI /var/www/html/EFI/BOOT

$ wget -q https://kojipkgs.fedoraproject.org//packages/grub2/2.04/1.fc32/x86_64/grub2-efi-x64-cdboot-2.04-1.fc32.x86_64.rpm && \
  rpm2cpio grub2-efi-x64-cdboot-2.04-1.fc32.x86_64.rpm | cpio -idm && \
  cp boot/efi/EFI/fedora/gcdx64.efi /var/www/html/EFI/BOOT/grubx64.efi

$ cat << EOF > /var/www/html/EFI/BOOT/grub.cfg
menuentry 'OS entry' --class fedora --class gnu-linux --class gnu --class os {
        linuxefi /images/pxeboot/vmlinuz inst.stage2=http://mirror.uv.es/mirror/fedora/linux/releases/30/Server/x86_64/os/ quiet
        initrdefi /images/pxeboot/initrd.img
}
menuentry 'Another OS entry' --class fedora --class gnu-linux --class gnu --class os {
        linuxefi /images/pxeboot/vmlinuz inst.stage2=http://mirror.uv.es/mirror/fedora/linux/releases/30/Server/x86_64/os/ quiet
        initrdefi /images/pxeboot/initrd.img
}
EOF

$ cat << EOF >> /etc/dhcp/dhcpd.conf
host httpclient {
  hardware ethernet 52:54:00:2c:dc:9e;
  filename "http://XXX.XXX.XXX.XXX/EFI/BOOT/BOOTX64.EFI";
  option vendor-class-identifier "HTTPClient";
}
EOF

Then I start a VM with OVMF and choose the UEFI HTTPv4 Boot entry using the firmware setting Boot Manager. The firmware successfully fetches shim, which downloads grub2 which also downloads the grub.cfg and I see the boot menu with the two entries. The HTTP daemon access log also shows that the HTTP requests succeeded:

XXX.XXX.XXX.XXX - - [13/Sep/2019:11:17:27 +0200] "HEAD /EFI/BOOT/BOOTX64.EFI HTTP/1.1" 200 - "-" "UefiHttpBoot/1.0"
XXX.XXX.XXX.XXX - - [13/Sep/2019:11:17:27 +0200] "GET /EFI/BOOT/BOOTX64.EFI HTTP/1.1" 200 1210776 "-" "UefiHttpBoot/1.0"
XXX.XXX.XXX.XXX - - [13/Sep/2019:11:17:27 +0200] "GET /EFI/BOOT//grubx64.efi HTTP/1.1" 200 2496840 "-" "UefiHttpBoot/1.0"
XXX.XXX.XXX.XXX - - [13/Sep/2019:11:17:27 +0200] "HEAD /EFI/BOOT/grub.cfg HTTP/1.1" 200 - "-" "UefiHttpBoot/1.0"
XXX.XXX.XXX.XXX - - [13/Sep/2019:11:17:27 +0200] "GET /EFI/BOOT/grub.cfg HTTP/1.1" 200 518 "-" "UefiHttpBoot/1.0"
XXX.XXX.XXX.XXX - - [13/Sep/2019:11:17:27 +0200] "HEAD /EFI/BOOT/x86_64-efi/command.lst HTTP/1.1" 404 - "-" "UefiHttpBoot/1.0"
XXX.XXX.XXX.XXX - - [13/Sep/2019:11:17:27 +0200] "HEAD /EFI/BOOT/x86_64-efi/fs.lst HTTP/1.1" 404 - "-" "UefiHttpBoot/1.0"
XXX.XXX.XXX.XXX - - [13/Sep/2019:11:17:27 +0200] "HEAD /EFI/BOOT/x86_64-efi/crypto.lst HTTP/1.1" 404 - "-" "UefiHttpBoot/1.0"
XXX.XXX.XXX.XXX - - [13/Sep/2019:11:17:27 +0200] "HEAD /EFI/BOOT/x86_64-efi/terminal.lst HTTP/1.1" 404 - "-" "UefiHttpBoot/1.0"
XXX.XXX.XXX.XXX - - [13/Sep/2019:11:17:27 +0200] "HEAD /EFI/BOOT/grub.cfg HTTP/1.1" 200 - "-" "UefiHttpBoot/1.0"
XXX.XXX.XXX.XXX - - [13/Sep/2019:11:17:27 +0200] "GET /EFI/BOOT/grub.cfg HTTP/1.1" 200 518 "-" "UefiHttpBoot/1.0"

The configfile command also worked for me and the $prefix is correctly set:

grub> echo $prefix
(http,XXX.XXX.XXX.XXX)/EFI/BOOT
grub> configfile grub.cfg

XXX.XXX.XXX.XXX - - [13/Sep/2019:11:36:41 +0200] "HEAD /EFI/BOOT/grub.cfg HTTP/1.1" 200 - "-" "UefiHttpBoot/1.0"
XXX.XXX.XXX.XXX - - [13/Sep/2019:11:36:41 +0200] "GET /EFI/BOOT/grub.cfg HTTP/1.1" 200 518 "-" "UefiHttpBoot/1.0"

Comment 2 Patrick Uiterwijk 2019-09-27 09:27:28 UTC

Thanks for the attempt at reproducing, I found out that this was a bug in the firmware of my test device (when I select "https://something" as boot filename, it automatically strips the "s" part for the initial download, but then the firmware refuses to load anything further).
So this is indeed not a grub bug, and sorry for the time wasted.

Comment 3 Javier Martinez Canillas 2019-09-27 12:11:30 UTC

(In reply to Patrick Uiterwijk from comment #2)
> Thanks for the attempt at reproducing, I found out that this was a bug in
> the firmware of my test device (when I select "https://something" as boot
> filename, it automatically strips the "s" part for the initial download, but
> then the firmware refuses to load anything further).
> So this is indeed not a grub bug, and sorry for the time wasted.

No worries and thanks for figuring out that's a FW bug.