Bug 1830161 - No network devices shows up when PXE booting via UEFI + IPv4
Summary: No network devices shows up when PXE booting via UEFI + IPv4
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Bare Metal Hardware Provisioning
Version: 4.4
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
: 4.5.0
Assignee: Julia Kreger
QA Contact: Amit Ugol
Depends On:
Blocks: 1830298
TreeView+ depends on / blocked
Reported: 2020-05-01 00:01 UTC by rlopez
Modified: 2020-07-13 17:34 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Cause: A iPXE UEFI loader binary was in for IPv4 network boot operations that was designed to utilize network drivers supplied with iPXE. Consequence: This results in a "No network found" error as a result on the console of the machine being deployed. Fix: UEFI firmware environments include a basic networking stack which can be utilized by the iPXE loader. As a result, the iPXE "snponly.efi" binary shall be used instead to perform the initalization of iPXE as the underlying UEFI network stack can be utilized. Result: Deployments of UEFI machines utilizing IPv4 and iPXE should now succeed.
Clone Of:
: 1830298 (view as bug list)
Last Closed: 2020-07-13 17:34:07 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Github openshift ironic-image pull 76 None closed Bug 1830161: Use snponly.efi instead of ipxe.efi for IPv4 2020-08-05 12:37:20 UTC
Red Hat Product Errata RHBA-2020:2409 None None None 2020-07-13 17:34:22 UTC

Description rlopez 2020-05-01 00:01:26 UTC
Description of problem:

When booting via UEFI, using IPv4 PXE protocol, error of no network devices shows up. Via https://github.com/openshift/ironic-image/blob/master/dnsmasq.conf.j2#L28 we see that ipxe.efi is set but it should be using snponly.efi https://github.com/metal3-io/ironic-image/blob/master/dnsmasq.conf.j2#L41

Steps to Reproduce:
1. Ensure UEFI+ IPv4 PXE protocol in UEFI settings
2. Attempt an IPI on BM install

Actual results:
Fails to PXE masters with No network devices

Expected results:
Properly PXE the master nodes. 


Comment 1 Julia Kreger 2020-05-01 00:13:14 UTC
UEFI stacks are supposed to supply network stacks to the firmware images loaded such as those for ipxe before the operating system loads. This means we should be using the snponly.efi binary for uefi with IPv4. With IPv6, the file is already correct.

Pull requests created for openshift and metal3.


Comment 4 Michael Burke 2020-07-01 22:45:29 UTC
Julia --

I am an OpenShift technical writer trying to write a release note for this fixed issue. However, I have little experience and understanding of this realm. Can I bother you to take a look at what I draft and let me know if I'm even close? We use the Cause-Consequence-Fix-Result format for reporting fixed issues. 

Thank you in advance for any help.


Because the UEFI boot process was using the `ipxe.efi` binary, if using IPv4 networks, the boot process reported that there are no networks are found. As a result, the Preboot eXecution Environment (PXE) boots the masters with no network devices. The  dnsmasq.conf file has been updated to use the `snponly.efi` binary. The PXE boots with the correct network drivers and the master have network connectivity.

Comment 5 Julia Kreger 2020-07-02 14:08:46 UTC
So, your note is a bit confusing, lets try:

Because the UEFI boot process was using the `ipxe.efi` binary when using IPv4 networks, the boot process reported that there were no network devices found. As a result, the Preboot eXecution Environment (PXE) boots the machines with "No network devices". The dnsmasq.conf file has been updated to use the `snponly.efi` binary for IPv4 networks. The machines booting with PXE utilize the UEFI network drivers and are able to deploy as they have network connectivity.

It glosses over technical details of the differences between iPXE generalized PXE, but it should still work.

Comment 6 errata-xmlrpc 2020-07-13 17:34:07 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, and where to find the updated
files, follow the link below.

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


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