Bug 1904099 - Hardware type 00 no longer accepted via BOOTIF option in 8.3
Summary: Hardware type 00 no longer accepted via BOOTIF option in 8.3
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: NetworkManager
Version: 8.3
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: rc
: 8.0
Assignee: Beniamino Galvani
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On:
Blocks: 1903247
TreeView+ depends on / blocked
 
Reported: 2020-12-03 14:38 UTC by Lukas Zapletal
Modified: 2021-05-18 13:33 UTC (History)
17 users (show)

Fixed In Version: NetworkManager-1.30.0-0.6.el8
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-05-18 13:32:37 UTC
Type: Bug
Target Upstream Version:


Attachments (Terms of Use)

Description Lukas Zapletal 2020-12-03 14:38:56 UTC
Hello,

several Satellite customers reported to us that PXE booting RHEL 8.3 is no longer possible. We have observed that Anaconda/dracut no longer configures network on multiple NICs. Example PXELinux configuration:

LABEL installer
MENU LABEL installer
KERNEL BOOT/RHEL_8_3_105_VMLINUZ
APPEND initrd=BOOT/RHEL_8_3_105_INITRD_IMG ks=http://satellite.example.com/unattended/provision?token=81bee514-b909-497a-8268-xxxxxxxxx network ksdevice=bootif ks.device=bootif BOOTIF=00-00-50-56-80-8e-1c kssendmac ks.sendmac inst.ks.sendmac
IPAPPEND 2

Installation stops as kickstart cannot be downloaded, the system halts and network is not available. The only workaround is to remove 00- from the BOOTIF option and remove IPAPPEND 2 statement which adds the same.

LABEL installer
MENU LABEL installer
KERNEL BOOT/RHEL_8_3_105_VMLINUZ
APPEND initrd=BOOT/RHEL_8_3_105_INITRD_IMG ks=http://satellite.example.com/unattended/provision?token=81bee514-b909-497a-8268-xxxxxxxxx network ksdevice=bootif ks.device=bootif BOOTIF=00-50-56-80-8e-1c kssendmac ks.sendmac inst.ks.sendmac

The relevant dracut code haven't changed for quite some time, so I wonder what caused this regression:

https://github.com/dracutdevs/dracut/blame/master/modules.d/40network/net-lib.sh#L223-L234

Thanks

Comment 1 Lukas Zapletal 2020-12-03 14:43:33 UTC
See the linked Satellite BZ for more info and relevant customer cases: https://bugzilla.redhat.com/show_bug.cgi?id=1903247

Comment 2 Joniel Pasqualetto 2020-12-03 14:50:58 UTC
I have slightly different observations.

Actually, when booting via PXE it works fine. The problem is when we use other method to load the kernel to start the installation.

When booting via pxe, the ipappend 2 does its job adding a proper BOOTIF parameter, using 01- as hardware type. And it works.

However, when we try to load the kernel without having network (using a boot disk, for example) and we pass the BOOTIF option using 00- as hardware type, then it's when it breaks.

Valid workarounds I found:

1. Do not specify a hardware type at all (BOOTIF=<mac>)
2. Specify 01 as  hardware type: (BOOTIF=01-<mac>)

This used to work (until RHEL 8.2) using 00- as hardware type (the default value used in Satellite templates).

Comment 3 Lukas Zapletal 2020-12-03 15:38:56 UTC
If PXE workflow is not affected, it's definitely not that bad (only bootdisk is affected). I am still syncing RHEL 8.3 I had to start over two times due to some bugs on my Satellite setup. I will confirm tomorrow. Thanks.

Comment 4 Sayan Das 2020-12-03 15:42:37 UTC
Hello Lukas, 

Yes, The PXE and iPXE workflow(Auto-attach bootdisk/host image) are unaffected. It's the only issue with "Full Host Image"


-- Sayan

Comment 5 Joniel Pasqualetto 2020-12-03 15:44:54 UTC
It also affects the discovery workflow.  When the kexec is sent to the discovered host, we hit the exact same situation as with the full host image.

Comment 10 Lukas Zapletal 2020-12-17 08:27:13 UTC
This actually appear to be misconfiguration in Satellite, we have been hardcoding hardware type 00 for many years while on Ethernet it should be 01. There are other types as well which are not widely popular, so good approach would be to make this a configurable option (a host param). But we would still like to know why this was changed now, in 8.3.

Comment 11 Lukas Zapletal 2020-12-17 08:40:21 UTC
We still have a problem tho, in RHEL 8 option ksdevice=MAC is marked as deprecated suggesting to use BOOTIF option:

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/performing_an_advanced_rhel_installation/kickstart-and-advanced-boot-options_installing-rhel-as-an-experienced-user#deprecated-boot-options_kickstart-and-advanced-boot-options

Problem is, BOOTIF requires hardware type to be present and starting in 8.3 dracut insist that this flag is set correctly, however in non-DHCP environment this creates new need to ask the user for this type of information. So we need to change all our workflows and ask users for hardware type now.

Suggestion for a change: Allow custom BOOTIF syntax without any prefix in the following form: BOOTIF=AA-BB-CC-DD-EE-FF and when recognized, interpret this as a mac address to match the previous behavior via ksdevice=MAC.

Comment 12 Lukas Zapletal 2020-12-17 08:48:34 UTC
I just learned that Joniel already confirms that BOOTIF=AA-BB-CC-DD-EE-FF is accepted, so we need to implement this in Satellite for non-PXE workflows. Therefore no changes required, if you can investigate why this happened that would be enough.

Comment 16 Beniamino Galvani 2020-12-23 13:52:50 UTC
Hi,

the analysis above is correct, the NM generator in initrd doesn't
understand a "00" hardware type for the BOOTIF option. It accepts only
a "01" type or no type:

  $ /usr/libexec/nm-initrd-generator --stdout -- BOOTIF=99-88-77-66-55-44
  *** Connection 'default_connection' ***
  [...]

  $ /usr/libexec/nm-initrd-generator --stdout -- BOOTIF=01-99-88-77-66-55-44
  *** Connection 'default_connection' ***
  [...]

  $ /usr/libexec/nm-initrd-generator --stdout -- BOOTIF=00-99-88-77-66-55-44
  802-3-ethernet.mac-address: '00-99-88-77-66-55-44' is not a valid MAC address

I opened a merge request to also support "00":

https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/713

Comment 17 Thomas Haller 2021-01-14 20:22:41 UTC
upstream merge request merged:
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/713

Comment 23 errata-xmlrpc 2021-05-18 13:32:37 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 (Moderate: NetworkManager and libnma security, 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/RHSA-2021:1574


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