Bug 1878612
Summary: | The default gateway is not set in grub2 environment when using UEFI HTTP boot | ||||||
---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | Rares Donca <rdonca> | ||||
Component: | grub2 | Assignee: | Bootloader engineering team <bootloader-eng-team> | ||||
Status: | CLOSED WONTFIX | QA Contact: | Release Test Team <release-test-team-automation> | ||||
Severity: | high | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | 7.9 | CC: | fmartine | ||||
Target Milestone: | rc | ||||||
Target Release: | --- | ||||||
Hardware: | x86_64 | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | If docs needed, set a value | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2022-03-14 07:27:18 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: | |||||||
Attachments: |
|
Description
Rares Donca
2020-09-14 07:24:56 UTC
I've tested the same setup (HTTP server in a different network than the DHCP server) using QEMU and OVMF and it worked correctly for me. Compared the DHCP Discover, Offer, Request and ACK packets from your tcpdump capture and a capture of this configuration that worked, I only one difference in the DHCP fields (besides IP address, mask, boot file name, etc that are expected). This is the Client Network Interface Identifier Option (Code 94). With OVMF this is set to 3.1 and with the firmware where this issue happens is set to 3.0. According to RFC 4578 [0], this field encode the UNDI revision. So the firmware has 3.00 32/64-bit UNDI specification. (Alpha) EFI boot services driver only. No EFI runtime support. While OVMF has: 3.10 32/64-bit UNDI specification. (Beta) First generation EFI runtime driver support. I wonder if a UNDI revision of 3.00 doesn't set the default gateway? Since GRUB does not set the routing table and it just gets this information from the EFI firmware. It calls EFI_IP4_CONFIG_PROTOCOL.GetData() to get this information. I'll attach a GRUB test build that add some debug prints to the net_ls_routes command. Could you please test it and let me know what's the output? [0]: https://tools.ietf.org/html/rfc4578#section-2.2 Created attachment 1714837 [details]
grubx64.efi
Thank you for your investigations Javier. I've tried the grub which you attached and the output of the net_ls_routes command is below. grub> grub>net_ls_routes route table entry 0 card efinet1 interface efinet1 subnet 10.126.18.0 mask 255.255.255.0 gateway 0.0.0.0 efinet1:local 10.126.18.0/24 efinet1 grub> Thanks for testing. I think this is an EFI firmware issue and not something that could be fixed in GRUB. As explained in the UEFI Spec [0], the EFI_IP4_CONFIG2_PROTOCOL.GetData() function is used to query the IPv4 network configuration. Part of this data is an EFI_IP4_ROUTE_TABLE array that contains the route table of the IPv4 network stack that runs on the network interface. The EF firmware you are testing only returns a single entry for interface efinet1, that has the subnet 10.126.18.0 with netmask /24 and gateway set to 0.0.0.0. But the firmware should have another routing table entry that has 0.0.0.0/0 and a gateway set, to use it as the default route. This entry is missing in the routing table returned by the EFI firmware in your tests. For reference this is what the same GRUB test build prints when running on an Qemu+ovmf VM: grub> net_ls_routes route table entry 0 card efinet0 interface efinet0 subnet 192.168.122.0 mask 255.255.255.0 gateway 0.0.0.0 route table entry 1 card efinet0 interface efinet0 subnet 0.0.0.0 mask 0.0.0.0 gateway 192.168.122.1 efinet0:local 192.168.122.0/24 efinet0 efinet0:default 0.0.0.0/0 gw 192.168.122.1 Since GRUB relies on the EFI firmware correctly setting up the network configuration using DHCP and just does HTTP requests using the EFI_HTTP_PROTOCOL, I don't think there's much that we can do to make this work. [0]: https://uefi.org/sites/default/files/resources/UEFI%20Spec%202.8B%20May%202020.pdf Thanks for the details. I understand that this might be a firmware bug and we will get in contact with the manufacturer. I did a reset of the config and also took out the vlan tag which you might recall that it was used. I can see now the same behavior which I mentioned also in the beginning of our email discussion: the default route is set, but on the wrong interface. grub>net_ls_routes route table entry 0 card efinet1 interface efinet1 subnet 10.126.18.0 mask 255.255.255.0 gateway 0.0.0.0 efinet1:local 10.126.18.0/24 efinet1 route table entry 0 card efinet0 interface (null) subnet 10.126.18.0 mask 255.255.255.0 gateway 0.0.0.0 route table entry 1 card efinet0 interface (null) subnet 0.0.0.0 mask 0.0.0.0 gateway 10.126.18.10 efinet0:default 0.0.0.0/0 gw 10.126.18.10 grub>net_ls_cards efinet1 00:a0:10:01:d5:a1 efinet0 00:a0:10:01:cf:85 grub>net_ls_addr efinet1 00:a1:10:01:d5:a1 10.126.18.28 grub> One of the errors that we see on the debug grub you provided is "net/efi/net.c:1236: interface lookup failed, using default efinet1". This will explain the "null" value for the interface on the net_ls_routes. After evaluating this issue, there are no plans to address it further or fix it in an upcoming release. Therefore, it is being closed. If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened. |