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
| 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
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" 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. (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. |