Bug 1811561 - grub2 doesn't handle relative paths correctly for UEFI HTTP Boot
Summary: grub2 doesn't handle relative paths correctly for UEFI HTTP Boot
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: grub2
Version: 8.3
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: 8.0
Assignee: Javier Martinez Canillas
QA Contact: Release Test Team
URL:
Whiteboard:
: 1653645 (view as bug list)
Depends On:
Blocks: 1796605 1812981 1825061
TreeView+ depends on / blocked
 
Reported: 2020-03-09 09:13 UTC by Lukas Zapletal
Modified: 2020-11-04 01:54 UTC (History)
4 users (show)

Fixed In Version: grub2-2.02-82.el8
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-11-04 01:53:54 UTC
Type: Bug
Target Upstream Version:


Attachments (Terms of Use)

Description Lukas Zapletal 2020-03-09 09:13:44 UTC
This bug was initially created as a copy of Bug #1616395

I am copying this bug because: 

Need to backport this into RHEL 8, Satellite 6 feature HTTP UEFI IPv6 provisining will be verified and tested workflow going forward. Thank you.

Description of problem:

Grub2 UEFI HTTP boot fails to resolve relative paths correctly.  


Steps to Reproduce:
1. Boot grub via UEFI HTTP
2. Configure grub.cfg to use a relative path, for example, given a menu entry like this:

menuentry 'Foreman Discovery Image' --id discovery {
  linuxefi boot/fdi-image/vmlinuz0 rootflags=loop root=live:/fdi.iso rootfstype=auto ro rd.live.image acpi=force rd.luks=0 rd.md=0 rd.dm=0 rd.lvm=0 rd.bootif=0 rd.neednet=0 nomodeset proxy.url=http://centos7-devel.astriaporta.example.com proxy.type=foreman BOOTIF=01-$mac
  initrdefi boot/fdi-image/initrd0.img
}

where boot/fdi-image/vmlinuz0 is relative to the location of the grubx64.efi image.


3. Try to boot

Actual results:
Grub immediately fails with:
 Fail to send a request! status=0xe

Expected results:
Host boots

Additional info:
- Using /pub/boot/fdi-image/vmlinuz0 works
- If looking at a tcpdump, grub is trying to do a DNS query for "192.168.73.1boot"

Comment 2 Petr Janda 2020-03-26 13:17:16 UTC
Lukas, can you share what version did you use for RHEL-8, please? 
I'm not able to reproduce it with latest RHEL-8.2  RHEL-8.2.0-20200310.0 (grub 2.02-81.el8) x86_64

Comment 3 Lukas Zapletal 2020-04-01 09:51:19 UTC
Javier (in CC) can provide the list of patches that have to be ported
there, he would say all of them even if the issues can't be reproduced due
the bugs being masked by other patches.

Comment 4 Javier Martinez Canillas 2020-04-08 12:17:47 UTC
(In reply to Petr Janda from comment #2)
> Lukas, can you share what version did you use for RHEL-8, please? 
> I'm not able to reproduce it with latest RHEL-8.2  RHEL-8.2.0-20200310.0
> (grub 2.02-81.el8) x86_64

I was able to reproduce the issue using that exact grub2 package version. The directory layout in my HTTP server is:

$ tree /var/www/html/netboot/
/var/www/html/netboot/
├── foo
│   └── bar.cfg
├── grub.cfg
├── grubx64.efi
└── shimx64.efi

And the filename in my dhcpd.conf is set to http://192.168.122.1/netboot/shimx64.efi.

On boot shim, grub2 and the grub.cfg in http://192.168.122.1/netboot/ are correctly fetched. I see the following in the HTTP server access log:

192.168.122.205 - - [08/Apr/2020:13:24:44 +0200] "HEAD /netboot/shimx64.efi HTTP/1.1" 200 - "-" "UefiHttpBoot/1.0"
192.168.122.205 - - [08/Apr/2020:13:24:44 +0200] "GET /netboot/shimx64.efi HTTP/1.1" 200 1317524 "-" "UefiHttpBoot/1.0"
192.168.122.205 - - [08/Apr/2020:13:24:44 +0200] "GET /netboot//grubx64.efi HTTP/1.1" 200 1877432 "-" "UefiHttpBoot/1.0"
192.168.122.205 - - [08/Apr/2020:13:24:44 +0200] "HEAD /netboot/grub.cfg HTTP/1.1" 200 - "-" "UefiHttpBoot/1.0"
192.168.122.205 - - [08/Apr/2020:13:24:44 +0200] "GET /netboot/grub.cfg HTTP/1.1" 200 518 "-" "UefiHttpBoot/1.0"
192.168.122.205 - - [08/Apr/2020:13:24:44 +0200] "HEAD /netboot/grub.cfg HTTP/1.1" 200 - "-" "UefiHttpBoot/1.0"
192.168.122.205 - - [08/Apr/2020:13:24:44 +0200] "GET /netboot/grub.cfg HTTP/1.1" 200 518 "-" "UefiHttpBoot/1.0"


Then I enter into the grub2 prompt and fetch the bar.cfg in http://192.168.122.1/netboot/foo/ using both an absolute and relative path:

grub> configfile /netboot/foo/bar.cfg

This works, the config file is fetched and I see the HTTP request and response in the access log:

192.168.122.108 - - [08/Apr/2020:13:26:50 +0200] "HEAD /netboot/foo/bar.cfg HTTP/1.1" 200 - "-" "UefiHttpBoot/1.0"
192.168.122.108 - - [08/Apr/2020:13:26:50 +0200] "GET /netboot/foo/bar.cfg HTTP/1.1" 200 500 "-" "UefiHttpBoot/1.0"

But using a relative path fails:

grub> configfile foo/bar.cfg

error: ../../grub-core/net/efi/http.c:234:Fail to send a request! status=0x12

And I don't see any logs in the access log. So the EFI firmware never makes the request. After that, any HTTP request fails even when using absolute paths (although this may be an issue only present in the OVMF EFI firmware):

grub> configfile /netboot/foo/bar.cfg

error: ../../grub-core/net/efi/http.c:234:Fail to send a request! status=0xf



After testing a RHEL8 build with the fix for Bug #1616395 it works correctly with both relative and absolute paths:

grub> configfile foo/bar.cfg

192.168.122.101 - - [08/Apr/2020:13:34:13 +0200] "HEAD /netboot/foo/bar.cfg HTTP/1.1" 200 - "-" "UefiHttpBoot/1.0"
192.168.122.101 - - [08/Apr/2020:13:34:13 +0200] "GET /netboot/foo/bar.cfg HTTP/1.1" 200 500 "-" "UefiHttpBoot/1.0"

grub> configfile /netboot/foo/bar.cfg

192.168.122.101 - - [08/Apr/2020:13:34:36 +0200] "HEAD /netboot/foo/bar.cfg HTTP/1.1" 200 - "-" "UefiHttpBoot/1.0"
192.168.122.101 - - [08/Apr/2020:13:34:36 +0200] "GET /netboot/foo/bar.cfg HTTP/1.1" 200 500 "-" "UefiHttpBoot/1.0"

Comment 5 Petr Janda 2020-04-14 11:50:58 UTC
providing qa_ack based on comment 4

Comment 9 Javier Martinez Canillas 2020-07-07 12:32:49 UTC
*** Bug 1653645 has been marked as a duplicate of this bug. ***

Comment 13 errata-xmlrpc 2020-11-04 01:53:54 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (grub2 bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:4513


Note You need to log in before you can comment on or make changes to this bug.