Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1750106 - UEFI HTTP boot does not grab config file
Summary: UEFI HTTP boot does not grab config file
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: grub2
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Peter Jones
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: IoT
TreeView+ depends on / blocked
 
Reported: 2019-09-08 11:46 UTC by Patrick Uiterwijk
Modified: 2019-09-27 12:11 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-09-27 09:27:28 UTC
Type: Bug
Embargoed:

Attachments (Terms of Use)

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.
Note You need to log in before you can comment on or make changes to this bug.