Bug 1904099

See the linked Satellite BZ for more info and relevant customer cases: https://bugzilla.redhat.com/show_bug.cgi?id=1903247

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).

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.

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

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.

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.

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.

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.

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

upstream merge request merged:
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/713

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