My understanding (and believe many users expect this ... not to mention how previous RHEL 8 releases worked).  I believe NetworkManager should mimic since users do NOT expect basic boot changes during a major release.

1.  BOOTIF=<MAC> specified & blank '<interface>' (ie ::) in ip= parameters on system with 1+ NICs
    RHEL 8.2 - Legacy network  - assigns static IP to the BOOTIF interface
    RHEL 8.3 - Network Manager - Assigns same IP to all interfaces and same UUID

2.  BOOTIF not used & '<interface>' (ie ::enp1s0f2) in ip= parameters on system with 1+ NICs
    RHEL 8.2 - Legacy network  - assigns static IP to the specified interface
    RHEL 8.3 - Network Manager - assigns static IP to the specified interface with name 'Wired Connection'

3.  BOOTIF not used & blank '<interface>' (ie ::) in ip= parameters on system with 1 NIC
    RHEL 8.2 - Legacy network  - assigns static IP to only interface
    RHEL 8.3 - Network Manager - assigns static IP to only interface with name 'Wired Connection'

4.  BOOTIF not used & blank '<interface>' (ie ::) in ip= parameters on system with 2+ NICs
    RHEL 8.2 - Legacy network  - boots but does not assign IP (doesn't know which interface)
    RHEL 8.3 - Network Manager - boots and assigns same static IP to all interface with name 'Wired Connection'

    NAME              UUID                                  TYPE      DEVICE   
    Wired Connection  1629d82c-670d-4f9a-a532-c405236ccda0  ethernet  enp1s0f0 
    Wired Connection  1629d82c-670d-4f9a-a532-c405236ccda0  ethernet  enp1s0f1 
    Wired Connection  1629d82c-670d-4f9a-a532-c405236ccda0  ethernet  enp1s0f2 
    Wired Connection  1629d82c-670d-4f9a-a532-c405236ccda0  ethernet  enp1s0f3 
    Wired Connection  1629d82c-670d-4f9a-a532-c405236ccda0  ethernet  enp1s0f4 
    Wired Connection  1629d82c-670d-4f9a-a532-c405236ccda0  ethernet  enp1s0f5 
    Wired Connection  1629d82c-670d-4f9a-a532-c405236ccda0  ethernet  enp1s0f6 
    Wired Connection  1629d82c-670d-4f9a-a532-c405236ccda0  ethernet  enp1s0f7 
    Wired Connection  1629d82c-670d-4f9a-a532-c405236ccda0  ethernet  enp2s0

Please ignore Comment #1 above ... here is updated testing:


General Information
===================
RHEL 8.2 testing will be done with GA DVD initramfs, as network-legacy is tried and tested.

Build initramfs with NetworkManager-1.26.0-12.el8_3 && dracut-049-133.git20210112.el8 that I will use for my RHEL 8.3 testing.
  lorax '--product=Red Hat Enterprise Linux' --version=8.3 --release=8.3 \
      --source=file:///scratch/repos/rhel8.3/{BaseOS,AppStream} \
      --enablerepo=rhel-8-for-x86_64-baseos-rpms \
      --source=file:///scratch/repos/NetworkManager-1.26.0-12.el8_3/ \
      --nomacboot --buildarch=x86_64 '--volid=RHEL 8.3' \
      /scratch/RHEL8.3b
-----8<------
(393/776) dracut-049-133.git20210112.el8.x86_64
-----8<------
(415/776) NetworkManager-1:1.26.0-12.el8_3.x86_64
-----8<------


Testing Summary
===============
Anaconda needs connection.{id,interface-name}, and this was consistently obtained by Network Manager when network-legacy network started interfaces in initramfs.  However, now that NetworkManager has taken over in initramfs there are many situtions customers use that are no longer working.  Key to this is:
  1. connection.{id,interface-name} failing to be set in many situtaions, and this data is needed for anaconda to properly propegate connection to installed image.
  2. When user doesn't provide specific interace, should only assign static IP to first interface with link (not all interfaces with link)

Only time RHEL 8.3 Network Manager works exactly like RHEL 8.2 is #1 below.
  This is when assinging static ip is if use ip= with all parameters (including '<interface>') and do NOT use BOOTIF= directive too.
  Adding the BOOTIF= in #2 works; however, results in erroneous 'BOOTIF Connection' too.

BOOTIF=<MAC> and blank <interface> for ip= does bring up interface as expected in 8.3
  NOTE: This is only way I know to boot/install system when ONLY know MAC address, have no DHCP, and want default predictable NIC names.
  NetMan fails to set connection.{id,interface-name} and these are required for anaconda to propegate to install
    This can be worked-around in kickstart %pre by using 'nmcli con modify' to set them

With neither BOOTIF=<MAC> or '<interface>' for ip= directive network-legacy uses first interface with link
  RHEL 8.3 NetMan assigns the same static ip to all interfaces with link and uses same UUID for all with no connection.{id,interface-name}.


Testing Details
===============
1.  BOOTIF= not used & '<interface>' ip= parameters on system with 1+ NICs
    # egrep -o '(BOOTIF|ip)=[[:alnum:][:punct:]]*' /proc/cmdline 
    ip=192.168.122.254::192.168.122.1:255.255.255.0:testhost.example.com:enp1s0f1:none:172.31.0.1:172.31.0.2

    RHEL 8.2 - Legacy network  - assigns static IP to the '<interface>'
    --------
      # ip -4 addr show | egrep -wo '^[0-9]*: enp[[:alnum:]]*|inet 192.168.122.[0-9]*'
      3: enp1s0f1
      inet 192.168.122.254

      # nmcli -t con show
      enp1s0f1:5a303456-b1ff-487c-8dc5-9a6ac0470774:802-3-ethernet:enp1s0f1

     # nmcli -t con show enp1s0f1 | grep -e ^connection.*:enp -e ipv4.add
      connection.id:enp1s0f1
      connection.interface-name:enp1s0f1
      ipv4.addresses:192.168.122.254/24

    RHEL 8.3 - Network Manager - assigns static IP to the specified interface with connection.{id,interface-name} set as anaconda needs
    --------
      # ip -4 addr show | egrep -wo '^[0-9]*: enp[[:alnum:]]*|inet 192.168.122.[0-9]*'
      3: enp1s0f1
      inet 192.168.122.254

      # nmcli -t con show
      enp1s0f1:bea2ec53-e50d-4a2f-96f8-6b4ffaa4f2f4:802-3-ethernet:enp1s0f1

      # nmcli -t con show 'enp1s0f1' | grep -e ^connection.*:enp -e ipv4.add
      connection.id:enp1s0f1
      connection.interface-name:enp1s0f1
      ipv4.addresses:192.168.122.254/24


2.  BOOTIF=<MAC> used & '<interface>' ip= parameters on system with 1+ NICs
    # egrep -o '(BOOTIF|ip)=[[:alnum:][:punct:]]*' /proc/cmdline
    BOOTIF=52-54-00-33-00-93
    ip=192.168.122.254::192.168.122.1:255.255.255.0:testhost.example.com:enp1s0f1:none:172.31.0.1:172.31.0.2

    # ip link show enp1s0f1 | grep ether
        link/ether 52:54:00:33:00:93 <snip>

    RHEL 8.2 - 
    --------
      # ip -4 addr show | egrep -wo '^[0-9]*: enp[[:alnum:]]*|inet 192.168.122.[0-9]*'
      3: enp1s0f1
      inet 192.168.122.254

      # nmcli -t con show
      enp1s0f1:049dd04b-3d7a-4097-8284-f264c375076d:802-3-ethernet:enp1s0f1

      # nmcli -t con show enp1s0f1 | grep -e ^connection.*:enp -e ipv4.add
      connection.id:enp1s0f1
      connection.interface-name:enp1s0f1
      ipv4.addresses:192.168.122.254/24


    RHEL 8.3 - Network Manager - assigns static IP to the specified interface with connection.{id,interface-name} set as anaconda needs. However, there is erroneous 'BOOTIF Connection' now.
    --------
      # ip -4 addr show | egrep -wo '^[0-9]*: enp[[:alnum:]]*|inet 192.168.122.[0-9]*'
      3: enp1s0f1
      inet 192.168.122.254

      # nmcli -t con show
      enp1s0f1:c8e8b8c4-df8c-49b2-9df1-3e8cddd4f406:802-3-ethernet:enp1s0f1
      BOOTIF Connection:fbd12706-303e-49d5-8765-25f793312c33:802-3-ethernet: <<<<<< erroneous

      # nmcli -t con show 'enp1s0f1' | grep -e ^connection.*:enp -e ipv4.add
      connection.id:enp1s0f1
      connection.interface-name:enp1s0f1
      ipv4.addresses:192.168.122.254/24

      # nmcli -t con show 'BOOTIF Connection' | grep -e ^connection.*:enp -e ipv4.add
      ipv4.addresses:


3.  BOOTIF=<MAC> used & blank '<interface>' parameter in ip= directive on system with 1+ NICs.  Needed when customer knows MAC address but not interface name prior to install over network (no DHCP).
    # egrep -o '(BOOTIF|ip)=[[:alnum:][:punct:]]*' /proc/cmdline
    BOOTIF=52-54-00-33-00-93
    ip=192.168.122.254::192.168.122.1:255.255.255.0:testhost.example.com::none:172.31.0.1:172.31.0.2


    RHEL 8.2 - Legacy network  - assigns static IP to the BOOTIF interface
    --------
      # ip -4 addr show | egrep -wo '^[0-9]*: enp[[:alnum:]]*|inet 192.168.122.[0-9]*'
      3: enp1s0f1
      inet 192.168.122.254

      # nmcli -t con show
      enp1s0f1:2c57234d-e556-431e-bb94-34292948c163:802-3-ethernet:enp1s0f1

      # nmcli -t con show enp1s0f1 | grep -e ^connection.*:enp -e ipv4.add
      connection.id:enp1s0f1
      connection.interface-name:enp1s0f1
      ipv4.addresses:192.168.122.254/24


    RHEL 8.3 - Network Manager - Assigns IP to BOOTIF interface as 'Wired Connection' & no connection.{id,interface-name} anaconda needs
    --------
      # ip -4 addr show | egrep -wo '^[0-9]*: enp[[:alnum:]]*|inet 192.168.122.[0-9]*'
      3: enp1s0f1
      inet 192.168.122.254

      # nmcli -t con show
      Wired Connection:7f459129-3c9f-48c7-a4a1-87385290b387:802-3-ethernet:enp1s0f1

      # nmcli -t con show 'Wired Connection' | grep -e ^connection.*:enp -e ipv4.add <<<<<<<< Missing id & interface-name
      ipv4.addresses:192.168.122.254/24


5.  BOOTIF not used & blank '<interface>' (ie ::) in ip= parameters on system with 2+ NICs.
    # egrep -o '(BOOTIF|ip)=[[:alnum:][:punct:]]*' /proc/cmdline
    ip=192.168.122.254::192.168.122.1:255.255.255.0:testhost.example.com::none:172.31.0.1:172.31.0.2

    RHEL 8.2 - Legacy network  - boots and assigns IP to first NIC w/ link (not enp1s0f0 here not *f1)
    --------
      # ip -4 addr show | egrep -wo '^[0-9]*: enp[[:alnum:]]*|inet 192.168.122.[0-9]*'
      2: enp1s0f0
      inet 192.168.122.254

      # nmcli -t con show
      enp1s0f0:95624d5f-f15a-4a38-b857-ffa09e5a6aa6:802-3-ethernet:enp1s0f0

      # nmcli -t con show enp1s0f0 | grep -e ^connection.*:enp -e ipv4.add
      connection.id:enp1s0f0
      connection.interface-name:enp1s0f0
      ipv4.addresses:192.168.122.254/24

    RHEL 8.3 - Network Manager - boots and assigns same static IP to all interface with link and assigns name 'Wired Connection' & no connection.{id,interface-name} anaconda needs
    --------
      # ip -4 addr show | egrep -wo '^[0-9]*: enp[[:alnum:]]*|inet 192.168.122.[0-9]*'
      2: enp1s0f0
      inet 192.168.122.254
      3: enp1s0f1
      inet 192.168.122.254
      4: enp1s0f2
      inet 192.168.122.254
      5: enp1s0f3
      inet 192.168.122.254
      6: enp1s0f4
      inet 192.168.122.254
      7: enp1s0f5
      inet 192.168.122.254
      8: enp1s0f6
      inet 192.168.122.254
      9: enp1s0f7
      inet 192.168.122.254
      10: enp2s0
      inet 192.168.122.254

      # nmcli -t con show
      Wired Connection:cb7c1bf0-f40f-4a7c-9145-aab7fc0a7aa4:802-3-ethernet:enp1s0f0
      Wired Connection:cb7c1bf0-f40f-4a7c-9145-aab7fc0a7aa4:802-3-ethernet:enp1s0f1
      Wired Connection:cb7c1bf0-f40f-4a7c-9145-aab7fc0a7aa4:802-3-ethernet:enp1s0f2
      Wired Connection:cb7c1bf0-f40f-4a7c-9145-aab7fc0a7aa4:802-3-ethernet:enp1s0f3
      Wired Connection:cb7c1bf0-f40f-4a7c-9145-aab7fc0a7aa4:802-3-ethernet:enp1s0f4
      Wired Connection:cb7c1bf0-f40f-4a7c-9145-aab7fc0a7aa4:802-3-ethernet:enp1s0f5
      Wired Connection:cb7c1bf0-f40f-4a7c-9145-aab7fc0a7aa4:802-3-ethernet:enp1s0f6
      Wired Connection:cb7c1bf0-f40f-4a7c-9145-aab7fc0a7aa4:802-3-ethernet:enp1s0f7
      Wired Connection:cb7c1bf0-f40f-4a7c-9145-aab7fc0a7aa4:802-3-ethernet:enp2s0

      # nmcli -t con show 'Wired Connection' | grep -e ^connection.*:enp -e ipv4.add
      ipv4.addresses:192.168.122.254/24


6.  BOOTIF not used & blank '<interface>' (ie ::) in ip= parameters on system with 1 NIC
    # egrep -o '(BOOTIF|ip)=[[:alnum:][:punct:]]*' /proc/cmdline
    ip=192.168.122.254::192.168.122.1:255.255.255.0:testhost.example.com::none:172.31.0.1:172.31.0.2

    RHEL 8.2 - Legacy network  - boots and assigns IP to first (and this time only) NIC w/ link
    --------
    This is identical to 8.2 in #5

    RHEL 8.3 - Network Manager - assigns static IP to the only interface with name 'Wired Connection' & no connection.{id,interface-name} anaconda needs
    --------
      # ip -4 addr show | egrep -wo '^[0-9]*: enp[[:alnum:]]*|inet 192.168.122.[0-9]*'
      2: enp1s0f0
      inet 192.168.122.254

      # nmcli -t con show
      Wired Connection:cdd491e7-1524-49c0-9718-aa6d955cfcdd:802-3-ethernet:enp1s0f0

      # nmcli -t con show 'Wired Connection' | grep -e ^connection.*:enp -e ipv4.add
      ipv4.addresses:192.168.122.254/24

(In reply to James Hartsock from comment #2)

> 2.  BOOTIF=<MAC> used & '<interface>' ip= parameters on system with 1+ NICs
>  BOOTIF=52-54-00-33-00-93 ip=192.168.122.254::192.168.122.1:255.255.255.0:testhost.example.com:enp1s0f1:none:172.31.0.1:172.31.0.2

While this example looks legitimate, I can't think of a reason why the
command line would specify both the interface name and the MAC
address.

> However, there is erroneous 'BOOTIF Connection' now.

Yes, because once there is an interface name specified, the generator
doesn't know what to do with the MAC address, as it is redundant
information. I'll prepare a patch to fix this.

> 3.  BOOTIF=<MAC> used & blank '<interface>' parameter in ip= directive on system with 1+ NICs.
>       Needed when customer knows MAC address but not interface name prior to install over network (no DHCP).
>    BOOTIF=52-54-00-33-00-93 ip=192.168.122.254::192.168.122.1:255.255.255.0:testhost.example.com::none:172.31.0.1:172.31.0.2
>
> RHEL 8.3 - Network Manager - Assigns IP to BOOTIF interface as 'Wired Connection' & no connection.{id,interface-name} anaconda needs

Can you elaborate on why Anaconda needs the id and the interface name? I am not aware of any issues of such kind.

> 5.  BOOTIF not used & blank '<interface>' (ie ::) in ip= parameters on system with 2+ NICs.
>  ip=192.168.122.254::192.168.122.1:255.255.255.0:testhost.example.com::none:172.31.0.1:172.31.0.2

> RHEL 8.2 - Legacy network  - boots and assigns IP to first NIC w/ link (not enp1s0f0 here not *f1)
> RHEL 8.3 - Network Manager - boots and assigns same static IP to all interface with link ...

Yes, this is a change in behavior. But I wonder what are users' real
expectations when configuring a static IP on an the first NIC with
link. The order in which devices are discovered by kernel can change
and also the order in which interfaces get carrier. So the the choice
doesn't seem very deterministic.

We can easily change this behavior in NM: if the address is static the
generator should create a connection with multi-connect=single instead
of =multiple, so that the connection can be active only on one device.

But as said, I think it would be better if the command line specified
which interface (either by name or MAC) to configure instead of having
the initrd pick one arbitrarily.

(In reply to Beniamino Galvani from comment #4)
> (In reply to James Hartsock from comment #2)
> 
> > 2.  BOOTIF=<MAC> used & '<interface>' ip= parameters on system with 1+ NICs
> >  BOOTIF=52-54-00-33-00-93 ip=192.168.122.254::192.168.122.1:255.255.255.0:testhost.example.com:enp1s0f1:none:172.31.0.1:172.31.0.2
> 
> While this example looks legitimate, I can't think of a reason why the
> command line would specify both the interface name and the MAC
> address.
> 
> > However, there is erroneous 'BOOTIF Connection' now.
> 
> Yes, because once there is an interface name specified, the generator
> doesn't know what to do with the MAC address, as it is redundant
> information. I'll prepare a patch to fix this.

Sounds good.

> 
> > 3.  BOOTIF=<MAC> used & blank '<interface>' parameter in ip= directive on system with 1+ NICs.
> >       Needed when customer knows MAC address but not interface name prior to install over network (no DHCP).
> >    BOOTIF=52-54-00-33-00-93 ip=192.168.122.254::192.168.122.1:255.255.255.0:testhost.example.com::none:172.31.0.1:172.31.0.2
> >
> > RHEL 8.3 - Network Manager - Assigns IP to BOOTIF interface as 'Wired Connection' & no connection.{id,interface-name} anaconda needs
> 
> Can you elaborate on why Anaconda needs the id and the interface name? I am
> not aware of any issues of such kind.


Without both connection.{id,interface-name} anaconda fails to properly correlate the connection to NIC.
So the 8.3 system ends up with the NIC having 2 NetworkManager connections.  Once with the static IP, and another with the default DHCP anaconda sets up.
For customer in case 02831610 they do not have DHCP, so NetworkManager takes several minutes for system to come online with static IP as it waits for DHCP timeout.


> 
> > 5.  BOOTIF not used & blank '<interface>' (ie ::) in ip= parameters on system with 2+ NICs.
> >  ip=192.168.122.254::192.168.122.1:255.255.255.0:testhost.example.com::none:172.31.0.1:172.31.0.2
> 
> > RHEL 8.2 - Legacy network  - boots and assigns IP to first NIC w/ link (not enp1s0f0 here not *f1)
> > RHEL 8.3 - Network Manager - boots and assigns same static IP to all interface with link ...
> 
> Yes, this is a change in behavior. But I wonder what are users' real
> expectations when configuring a static IP on an the first NIC with
> link. The order in which devices are discovered by kernel can change
> and also the order in which interfaces get carrier. So the the choice
> doesn't seem very deterministic.

It is very deterministic if this is the first time booting system for install and only one cable is pulled.
Even if a VM, can set interfaces to not have a link to control this.

> 
> We can easily change this behavior in NM: if the address is static the
> generator should create a connection with multi-connect=single instead
> of =multiple, so that the connection can be active only on one device.
> 
> But as said, I think it would be better if the command line specified
> which interface (either by name or MAC) to configure instead of having
> the initrd pick one arbitrarily.

Understand your point that better to specify interface name; however, if first time booting bare-metal for install do not know the name.

And ip= doesn't let you specify a static IP and MAC address. You can use ifname=<interface>:<MAC> however, this interface name provided here will be used on the final installed system too (at least in 8.1 & 8.2).  Thus the only solution in RHEL 8 were able to get work (in 8.2 testing) was to specify BOOTIF= and not specify interface name in ip=.
  https://access.redhat.com/solutions/5019271

And in doing testing for behavior changes from RHEL 8.2 to 8.3, we tried it without BOOTIF= and believe not only is this a change in behavior but bad behavior from NetworkManager in dracut general.

I've opened a merge request [1] to fix cases 2. (BOOTIF=<MAC> used &
'<interface>') and 5. (static IP without ifname/BOOTIF, 2+ NICS).

[1] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/779

> Without both connection.{id,interface-name} anaconda fails to
> properly correlate the connection to NIC.

> So the 8.3 system ends up with the NIC having 2 NetworkManager
> connections.  Once with the static IP, and another with the default
> DHCP anaconda sets up.

> For customer in case 02831610 they do not have DHCP, so
> NetworkManager takes several minutes for system to come online with
> static IP as it waits for DHCP timeout.

Understood, I think we need to involve the Anaconda team for this.

Radek, do you know why Anaconda creates an additional DHCP
connection even if the device already has a connection with
static IP?

> It is very deterministic if this is the first time booting system
> for install and only one cable is pulled.  Even if a VM, can set
> interfaces to not have a link to control this.

Okay, makes sense.

> And ip= doesn't let you specify a static IP and MAC address. You can
> use ifname=<interface>:<MAC> however, this interface name provided
> here will be used on the final installed system too (at least in 8.1
> & 8.2).

> Thus the only solution in RHEL 8 were able to get work (in 8.2
> testing) was to specify BOOTIF= and not specify interface name in
> ip=.  https://access.redhat.com/solutions/5019271

I'm not sure about RHEL 8.2 but in 8.3 you should be able to use a MAC
(in the dashed notation) instead of the interface name:

 ip=192.168.122.254:::24::00-11-22-33-44-55

From the dracut code it looks like this should also work on RHEL 8.2,
but I haven't tested it yet.

(In reply to Beniamino Galvani from comment #6)
> 
> I'm not sure about RHEL 8.2 but in 8.3 you should be able to use a MAC
> (in the dashed notation) instead of the interface name:
> 

Does seem to work in both.  Reading 'man dracut.cmdline' do not see it noted that can use the mac-address (in dash notation) there in ip= <interface> field.

Which code you looking at so I can reference that in portal solution article update (and notify a customer of this news)?

Is this what you refer to?

Looking at dracut's ifup.sh it uses `net-lib.sh` function `ip_to_var()` parses the ip= and sets interface field to $dev

It then has the following code, which parses the MAC in dashed notation.  But in this case (as ip= parameters colon delimited) the first format would never match.

    case "$dev" in
        ??:??:??:??:??:??)  # MAC address
            _dev=$(iface_for_mac $dev)
            [ -n "$_dev" ] && dev="$_dev"
            ;;
        ??-??-??-??-??-??)  # MAC address in BOOTIF form
            _dev=$(iface_for_mac $(fix_bootif $dev))
            [ -n "$_dev" ] && dev="$_dev"
            ;;
    esac

(In reply to James Hartsock from comment #8)
> Is this what you refer to?

Yes.

> It then has the following code, which parses the MAC in dashed notation. 
> But in this case (as ip= parameters colon delimited) the first format would
> never match.

Correct, it doesn't work with colons.

(In reply to Beniamino Galvani from comment #6)
 
> > Without both connection.{id,interface-name} anaconda fails to
> > properly correlate the connection to NIC.
> 
> > So the 8.3 system ends up with the NIC having 2 NetworkManager
> > connections.  Once with the static IP, and another with the default
> > DHCP anaconda sets up.
> 
> > For customer in case 02831610 they do not have DHCP, so
> > NetworkManager takes several minutes for system to come online with
> > static IP as it waits for DHCP timeout.
> 
> Understood, I think we need to involve the Anaconda team for this.
> 
> Radek, do you know why Anaconda creates an additional DHCP
> connection even if the device already has a connection with
> static IP?

Anaconda is creating persistent connection profiles for each wired interface as a legacy (perhaps something to get rid of in the future, at least optionally).

If it doesn't identify such connection from initramfs that could be made persistent (by the .id or .device, see https://github.com/rhinstaller/anaconda/blob/6fcd2e248303f0f5f686956a5556ea536baf48e5/pyanaconda/modules/network/initialization.py#L424) it creates a default one (dhcp). And this is what happens in this case - see https://bugzilla.redhat.com/show_bug.cgi?id=1910438#c5. There is an upstream fix for that on Anaconda side referred in the comment - instead of creating a default connection from scratch clone the generic (multiconnect > 1) Wired Connection for the persistent connection - which would fix also the #3 case I think.

PR for Anaconda kickstart tests covering some of the cases from coment #2:
https://github.com/rhinstaller/kickstart-tests/pull/494

(In reply to Radek Vykydal from comment #12)
> PR for Anaconda kickstart tests covering some of the cases from coment #2:
> https://github.com/rhinstaller/kickstart-tests/pull/494

Hi Radek,

can you please create a new bugzilla (or clone it) for the Anaconda issue? So that this bz tracks only the NetworkManager part. Thank you.

This is a scratch build with the NM fixes:

https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=35505410

Changes:

 - in scenario 2. the generator now creates a single connection with both ifname and mac address set;

 - in scenario 5. NM now activates the static-IP connection only on one interface.

The remaining issue (Anaconda creates new connection with DHCP) must be fixed in Anaconda.

James, would you be able to test this scratch build and see if it behaves correctly in the scenarios you described above?

(In reply to Beniamino Galvani from comment #19)
> This is a scratch build with the NM fixes:
> 
> https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=35505410
> 
> Changes:
> 
>  - in scenario 2. the generator now creates a single connection with both
> ifname and mac address set;
> 
>  - in scenario 5. NM now activates the static-IP connection only on one
> interface.
> 
> The remaining issue (Anaconda creates new connection with DHCP) must be
> fixed in Anaconda.

Then if we want to fix scenario 3. from comment #2 wë́'ll need to fix bug 1910438 by applying the fix from https://bugzilla.redhat.com/show_bug.cgi?id=1910438#c5
and request an exception for the bug 1910438.

Also needed libndp from following to build my 8.3 with updated NetworkManager
  Used: https://brewweb.engineering.redhat.com/brew/buildinfo?buildID=1527698

# lorax --product='Red Hat Enterprise Linux' --version=8.3 --release=8.3 --source=file:///scratch/repos/rhel8.3/{BaseOS,AppStream} --source=file:///scratch/repos/BZ1915493 --nomacboot --buildarch=x86_64 --volid='RHEL 8.3' /scratch/RHEL8.3
...
2021-03-17 13:11:53,466: Added 'lorax-repo-0': file:///scratch/repos/rhel8.3/BaseOS
2021-03-17 13:11:53,475: Added 'lorax-repo-1': file:///scratch/repos/rhel8.3/AppStream
2021-03-17 13:11:53,495: Added 'lorax-repo-2': file:///scratch/repos/BZ1915493
...
(417/778) NetworkManager-1:1.30.0-4.1.bz1915493.el8.x86_64

TEST SUMMARY
============
Why are NICs that were not asked to be activated being setup for DHCP?

1. DHCP for interfaces that were (and should) be offline in RHEL 8.3
   Otherwise still works
2. DHCP for interfaces that were (and should) be offline in RHEL 8.3
   Fixed: No erronous 'BOOTIF Connection'
3. DHCP for interfaces that were (and should) be offline in RHEL 8.3
   Fixed no 'Wired Connection'
   Fixed have connection{id,interface-name} anaconda needs
4. SKIP -- I didn't know how to count in comment #2
5. DHCP for interfaces that were (and should) be offline in RHEL 8.3
   Fixed only 1 interface has static IP assigned
6. Fixed only 1 interface has static IP assigned
   The DHCP for all unconfigured not issue here as only 1 NIC visible and has static assignment

Testing Details
===============
1.  BOOTIF= not used & '<interface>' ip= parameters on system with 1+ NICs
    # egrep -o '(BOOTIF|ip)=[[:alnum:][:punct:]]*' /proc/cmdline
    ip=192.168.122.254::192.168.122.1:255.255.255.0:testhost.example.com:enp1s0f1:none:172.31.0.1:172.31.0.2

    RHEL 8.3 w/ NetworkManager-1:1.30.0-4.1.bz1915493.el8
    -----------------------------------------------------
    # ip -4 addr show | egrep -wo '^[0-9]*: enp[[:alnum:]]*|inet 192.168.122.[0-9]*'
    3: enp1s0f1
    inet 192.168.122.254

    # nmcli -t con show
    enp1s0f1:0b2f4907-e4a0-4c9e-8805-53d5af6e95c0:802-3-ethernet:enp1s0f1
    enp1s0f0:26cb3748-42be-4932-80ce-0c4153715dab:802-3-ethernet: <---.
    enp1s0f2:8a4c586c-cbd9-443d-88b5-d4f1f6ceba77:802-3-ethernet:     |
    enp1s0f3:e6dbd0cd-aeb1-4796-b615-4f2d3d84c7a2:802-3-ethernet:     |
    enp1s0f4:eb08edbd-3c5c-4cba-84f7-507fe1fada0b:802-3-ethernet:     |-- Why all these setup for DHCP?
    enp1s0f5:0126467e-e94f-4fdd-9da2-1b5baa0e1a76:802-3-ethernet:     |   Nothing asked for this!!!!
    enp1s0f6:20a7b8fb-b198-492b-9d72-06645dbda7dc:802-3-ethernet:     |
    enp1s0f7:dd17257c-10a6-43b4-b1ac-7906598bc9e7:802-3-ethernet:     |
    enp2s0:c13f3455-b6be-4acc-bded-aed376b75e65:802-3-ethernet: <-----'

    # nmcli -t con show enp1s0f1 | grep -e ^connection.*:enp -e ipv4.add
    connection.id:enp1s0f1
    connection.interface-name:enp1s0f1
    ipv4.addresses:192.168.122.254/24

    # nmcli -t con show enp2s0 | grep ^ip.*method
    ipv4.method:auto
    ipv6.method:auto


2.  BOOTIF=<MAC> used & '<interface>' ip= parameters on system with 1+ NICs
    # egrep -o '(BOOTIF|ip)=[[:alnum:][:punct:]]*' /proc/cmdline
    BOOTIF=52-54-00-33-00-93
    ip=192.168.122.254::192.168.122.1:255.255.255.0:testhost.example.com:enp1s0f1:none:172.31.0.1:172.31.0.2

    # ip link show enp1s0f1 | grep ether
        link/ether 52:54:00:33:00:93 <snip>

    RHEL 8.3 w/ NetworkManager-1:1.30.0-4.1.bz1915493.el8
    -----------------------------------------------------
    # ip -4 addr show | egrep -wo '^[0-9]*: enp[[:alnum:]]*|inet 192.168.122.[0-9]*'
    3: enp1s0f1
    inet 192.168.122.254

    # nmcli -t con show
    enp1s0f1:372adfc7-a6c5-4c43-993d-2fd59ce8117c:802-3-ethernet:enp1s0f1
    enp1s0f0:170a1fef-c4c8-4e5e-906c-10c4d3945da5:802-3-ethernet: <---.
    enp1s0f2:ac288e6b-51c0-4a96-ac68-9af585cb6882:802-3-ethernet:     |
    enp1s0f3:1f0510ed-1b2d-4256-8e56-7ce8a48da1d8:802-3-ethernet:     |
    enp1s0f4:e61abee1-7891-48e9-a701-9cfbd644e89b:802-3-ethernet:     |-- Why all these setup for DHCP?
    enp1s0f5:0cdcfb6c-215e-4eab-baa1-4efe0e59b126:802-3-ethernet:     |   Nothing asked for this!!!!
    enp1s0f6:d20deb74-a657-411f-87d3-7cdcc4a161b1:802-3-ethernet:     |
    enp1s0f7:787be672-4662-4946-9ed1-feff39afe864:802-3-ethernet:     |
    enp2s0:4589d9ab-c67b-490f-9d83-108b8050261e:802-3-ethernet: <-----'

    # nmcli -t con show enp1s0f1 | grep -e ^connection.*:enp -e ipv4.add
    connection.id:enp1s0f1
    connection.interface-name:enp1s0f1
    ipv4.addresses:192.168.122.254/24


3.  BOOTIF=<MAC> used & blank '<interface>' parameter in ip= directive on system with 1+ NICs.  Needed when customer knows MAC address but not interface name prior to install over network (no DHCP).
    # egrep -o '(BOOTIF|ip)=[[:alnum:][:punct:]]*' /proc/cmdline
    BOOTIF=52-54-00-33-00-93
    ip=192.168.122.254::192.168.122.1:255.255.255.0:testhost.example.com::none:172.31.0.1:172.31.0.2

    RHEL 8.3 w/ NetworkManager-1:1.30.0-4.1.bz1915493.el8
    -----------------------------------------------------
    # ip -4 addr show | egrep -wo '^[0-9]*: enp[[:alnum:]]*|inet 192.168.122.[0-9]*'
    3: enp1s0f1
    inet 192.168.122.254

    # nmcli -t con show
    enp1s0f1:347f3d15-59f1-4560-94c0-0f53100d3b28:802-3-ethernet:enp1s0f1
    enp1s0f0:805e9767-15b9-496c-9a51-68cf28864708:802-3-ethernet: <---.
    enp1s0f2:a96241f5-2edf-4c82-a743-79d8f2843021:802-3-ethernet:     |
    enp1s0f3:aeaacd2b-55b1-46be-a638-643b51370dd4:802-3-ethernet:     |
    enp1s0f4:1b162734-6815-4fb8-b285-0d35272177f2:802-3-ethernet:     |-- Why all these setup for DHCP?
    enp1s0f5:9ffb4601-dc86-4831-a2c1-554e0b87f201:802-3-ethernet:     |   Nothing asked for this!!!!
    enp1s0f6:21693f80-ff31-49d9-8d30-cb8e95ad2891:802-3-ethernet:     |
    enp1s0f7:9ac58f75-f1be-4d57-86bd-fd6f6ec616d9:802-3-ethernet:     |
    enp2s0:e2d6c27e-c7cf-4776-97cc-06224b0a454f:802-3-ethernet: <-----'

    # nmcli -t con show enp1s0f1 | grep -e ^connection.*:enp -e ipv4.add
    connection.id:enp1s0f1 <--------------.
    connection.interface-name:enp1s0f1 <--+---- Fixed
    ipv4.addresses:192.168.122.254/24


4. SKIPPING AGAIN (I failed to counting in comment #2)


5.  BOOTIF not used & blank '<interface>' (ie ::) in ip= parameters on system with 2+ NICs.
    # egrep -o '(BOOTIF|ip)=[[:alnum:][:punct:]]*' /proc/cmdline
    ip=192.168.122.254::192.168.122.1:255.255.255.0:testhost.example.com::none:172.31.0.1:172.31.0.2

    RHEL 8.3 w/ NetworkManager-1:1.30.0-4.1.bz1915493.el8
    -----------------------------------------------------
    # ip -4 addr show | egrep -wo '^[0-9]*: enp[[:alnum:]]*|inet 192.168.122.[0-9]*'
    2: enp1s0f0
    inet 192.168.122.254

    # nmcli -t con show
    enp1s0f0:3f92cee5-5d4b-4adc-8ecf-3ca9e92f036c:802-3-ethernet:enp1s0f0
    enp1s0f1:7eaff0c0-8081-43a2-8432-b4635dd830f2:802-3-ethernet: <---.
    enp1s0f2:b64c171c-a36d-4228-9d6e-e2918818d8b2:802-3-ethernet:     |
    enp1s0f3:1b55adf1-cff4-45f6-887d-bddd56b71c8e:802-3-ethernet:     |
    enp1s0f4:79653d58-44ae-4be4-9923-f295772fb2f4:802-3-ethernet:     |-- Why all these setup for DHCP?
    enp1s0f5:384c0184-9689-4f94-98ff-e31e465a3ee3:802-3-ethernet:     |   Nothing asked for this!!!!
    enp1s0f6:6222acc7-7c25-48fa-bf05-d817e9a10f61:802-3-ethernet:     |
    enp1s0f7:81d1a273-4fcb-40cc-89d6-e373b3158fee:802-3-ethernet:     |
    enp2s0:38edad6b-4b9f-46dc-9710-b2706513fb25:802-3-ethernet: <-----'

    # nmcli -t con show enp1s0f0 | grep -e ^connection.*:enp -e ipv4.add -e ^ip.*method
    connection.id:enp1s0f0
    connection.interface-name:enp1s0f0
    ipv4.method:manual
    ipv4.addresses:192.168.122.254/24
    ipv6.method:disabled



6.  BOOTIF not used & blank '<interface>' (ie ::) in ip= parameters on system with 1 NIC
    # egrep -o '(BOOTIF|ip)=[[:alnum:][:punct:]]*' /proc/cmdline
    ip=192.168.122.254::192.168.122.1:255.255.255.0:testhost.example.com::none:172.31.0.1:172.31.0.2

    RHEL 8.3 w/ NetworkManager-1:1.30.0-4.1.bz1915493.el8
    -----------------------------------------------------
    # ip -4 addr show | egrep -wo '^[0-9]*: enp[[:alnum:]]*|inet 192.168.122.[0-9]*'
    2: enp2s0
    inet 192.168.122.254

    # nmcli -t con show
    enp2s0:88021e0b-5721-4321-84fd-c5a20fd14617:802-3-ethernet:enp2s0

    # nmcli -t con show enp2s0 | grep -e ^connection.*:enp -e ipv4.add -e ^ip.*method
    connection.id:enp2s0
    connection.interface-name:enp2s0
    ipv4.method:manual
    ipv4.addresses:192.168.122.254/24
    ipv6.method:disabled

BTW ... all this testing is done on a KVM guest with 2 nics, one with multiple ports.
I then just use static kernel & initrd, and then tweak cmdline for each test case.
So anybody should be able to test, I use my local http but should easily be able point internal HTTP.

$ virsh -c qemu:///system dumpxml inst8  | sed -n -e '/<os/,/<\/os/p' -e '/<interface.*network/,/<\/interface/p'
  <os>
    <type arch='x86_64' machine='pc-q35-rhel7.6.0'>hvm</type>
    <kernel>/home/jhartsoc/VirtualMachines/boot/RHEL83b_vmlinuz</kernel>
    <initrd>/home/jhartsoc/VirtualMachines/boot/RHEL83b_initrd.img</initrd>
    <cmdline>inst.stage2=http://172.31.0.1/repos/rhel8.3/ inst.repo=http://172.31.0.1/repos/rhel8.3/ inst.ks=http://172.31.0.1/KS/8.3/virt-min.cfg console=tty0 console=ttyS0,115200 ip=192.168.122.254::192.168.122.1:255.255.255.0:testhost.example.com:52-54-00-33-00-93:none:172.31.0.1:172.31.0.2</cmdline>
    <bootmenu enable='yes'/>
    <smbios mode='host'/>
  </os>
    <interface type='network'>
      <mac address='52:54:00:33:00:92'/>
      <source network='default' portid='0e4ec00d-8202-404f-b95b-5ad92b6b3fe1' bridge='virbr0'/>
      <target dev='vnet0'/>
      <model type='virtio'/>
      <link state='up'/>
      <alias name='net0'/>
      <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0' multifunction='on'/>
    </interface>
    <interface type='network'>
      <mac address='52:54:00:33:00:93'/>
      <source network='default' portid='e11aa251-b64c-4677-b30f-8c6fe1b910d8' bridge='virbr0'/>
      <target dev='vnet1'/>
      <model type='virtio'/>
      <alias name='net1'/>
      <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x1'/>
    </interface>
    <interface type='network'>
      <mac address='52:54:00:33:00:94'/>
      <source network='default' portid='abe4ffbf-06d9-4d40-a053-107e0184a6d2' bridge='virbr0'/>
      <target dev='vnet2'/>
      <model type='virtio'/>
      <alias name='net2'/>
      <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x2'/>
    </interface>
    <interface type='network'>
      <mac address='52:54:00:33:00:95'/>
      <source network='default' portid='459e9445-2229-4c4e-aab9-129a41defdd7' bridge='virbr0'/>
      <target dev='vnet3'/>
      <model type='virtio'/>
      <alias name='net3'/>
      <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x3'/>
    </interface>
    <interface type='network'>
      <mac address='52:54:00:33:00:96'/>
      <source network='default' portid='106dc2d4-cf5e-44a5-b181-e70e0ea38633' bridge='virbr0'/>
      <target dev='vnet4'/>
      <model type='virtio'/>
      <alias name='net4'/>
      <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x4'/>
    </interface>
    <interface type='network'>
      <mac address='52:54:00:33:00:97'/>
      <source network='default' portid='3762adf9-f277-4ec8-8319-5dbfddba3c52' bridge='virbr0'/>
      <target dev='vnet5'/>
      <model type='virtio'/>
      <alias name='net5'/>
      <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x5'/>
    </interface>
    <interface type='network'>
      <mac address='52:54:00:33:00:98'/>
      <source network='default' portid='f88dc7a3-b9c4-425f-a502-9639798dcae4' bridge='virbr0'/>
      <target dev='vnet6'/>
      <model type='virtio'/>
      <alias name='net6'/>
      <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x6'/>
    </interface>
    <interface type='network'>
      <mac address='52:54:00:33:00:99'/>
      <source network='default' portid='1edf361c-19f4-4dd7-a5f0-ce0c6a0b7072' bridge='virbr0'/>
      <target dev='vnet7'/>
      <model type='virtio'/>
      <alias name='net7'/>
      <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x7'/>
    </interface>
    <interface type='network'>
      <mac address='52:54:00:33:00:a0'/>
      <source network='default' portid='3c7e7bf9-f8ad-4847-bec4-c0f974ad8c44' bridge='virbr0'/>
      <target dev='vnet8'/>
      <model type='virtio'/>
      <alias name='net8'/>
      <address type='pci' domain='0x0000' bus='0x02' slot='0x00' function='0x0'/>
    </interface>

And a new issue present when I use the MAC-Address as <interface> in ip= directive as discussed earlier in this case


# egrep -o '(BOOTIF|ip)=[[:alnum:][:punct:]]*' /proc/cmdline
ip=192.168.122.254::192.168.122.1:255.255.255.0:testhost.example.com:52-54-00-33-00-93:none:172.31.0.1:172.31.0.2

# ip -o link show enp1s0f1 | grep -o 'ether [[:xdigit:]:]*'                    
ether 52:54:00:33:00:93

# nmcli -t con show
52\:54\:00\:33\:00\:93:b4fe3c0a-89dd-49d2-b1ac-94162a2f6392:802-3-ethernet:enp1s0f1
enp1s0f0:fb60cf07-f5d9-41ad-9b71-32aab4021761:802-3-ethernet:               '  
enp1s0f1:292c04db-cf8a-4b06-bd68-0a6e05c2137c:802-3-ethernet: <-------------+--------- DUPLICATE                 
enp1s0f2:6c55e33f-66de-470d-a1a0-035887fc9780:802-3-ethernet:                  
enp1s0f3:b7ea615e-9acf-4580-960e-d7b7777a8d40:802-3-ethernet:                  
enp1s0f4:cab1b608-8a78-46f6-8f7a-0b6926ce1ca9:802-3-ethernet:                  
enp1s0f5:b8964a47-eb76-4944-b0f8-8bea531af2cf:802-3-ethernet:                  
enp1s0f6:0578d589-fe19-48ec-9121-4fbadbce090c:802-3-ethernet:                  
enp1s0f7:59907a1e-cad0-4ed5-8dec-beb014d73723:802-3-ethernet:                  
enp2s0:dc6ad768-426a-4334-8b38-e5bd410e2b9c:802-3-ethernet: 


# nmcli -t con show b4fe3c0a-89dd-49d2-b1ac-94162a2f6392 | grep -e ^connection.*:enp -e ipv4.add -e ^ip.*method                                                
ipv4.method:manual
ipv4.addresses:192.168.122.254/24
ipv6.method:disabled

# nmcli -t con show enp1s0f1 | grep -e ^connection.*:enp -e ipv4.add -e ^ip.*method
connection.id:enp1s0f1 <---------------------.
connection.interface-name:enp1s0f1 <---------+--------------- connection.{id,interface-name} ONLY set on this connection!!!
ipv4.method:auto
ipv4.addresses:
ipv6.method:auto

(In reply to James Hartsock from comment #21)

> TEST SUMMARY
> ============
> Why are NICs that were not asked to be activated being setup for DHCP?

James could you please attach link to the built boot.iso ?
I would check if these connections are created / activated in initramfs or after switch root (which could be default autoconnections that are disabled on RHEL with NM conifiguration in installer image).
I could also run Anaconda kickstart tests on it to check for regressions.

> 
> 1. DHCP for interfaces that were (and should) be offline in RHEL 8.3
>    Otherwise still works
> 2. DHCP for interfaces that were (and should) be offline in RHEL 8.3
>    Fixed: No erronous 'BOOTIF Connection'
> 3. DHCP for interfaces that were (and should) be offline in RHEL 8.3
>    Fixed no 'Wired Connection'
>    Fixed have connection{id,interface-name} anaconda needs

I am surprised that the NM fix involves creating dedicated connection with connection.id and connection.interface-name set. I wouldn't expect this based on comment #19. In this case there is no need to fix on Anaconda side (bug 1910438).

> 
> 3.  BOOTIF=<MAC> used & blank '<interface>' parameter in ip= directive on
> system with 1+ NICs.  Needed when customer knows MAC address but not
> interface name prior to install over network (no DHCP).
>     # egrep -o '(BOOTIF|ip)=[[:alnum:][:punct:]]*' /proc/cmdline
>     BOOTIF=52-54-00-33-00-93
>    
> ip=192.168.122.254::192.168.122.1:255.255.255.0:testhost.example.com::none:
> 172.31.0.1:172.31.0.2
> 
>     RHEL 8.3 w/ NetworkManager-1:1.30.0-4.1.bz1915493.el8
>     -----------------------------------------------------
>     # ip -4 addr show | egrep -wo '^[0-9]*: enp[[:alnum:]]*|inet
> 192.168.122.[0-9]*'
>     3: enp1s0f1
>     inet 192.168.122.254
> 
>     # nmcli -t con show
>     enp1s0f1:347f3d15-59f1-4560-94c0-0f53100d3b28:802-3-ethernet:enp1s0f1
>     enp1s0f0:805e9767-15b9-496c-9a51-68cf28864708:802-3-ethernet: <---.
>     enp1s0f2:a96241f5-2edf-4c82-a743-79d8f2843021:802-3-ethernet:     |
>     enp1s0f3:aeaacd2b-55b1-46be-a638-643b51370dd4:802-3-ethernet:     |
>     enp1s0f4:1b162734-6815-4fb8-b285-0d35272177f2:802-3-ethernet:     |--
> Why all these setup for DHCP?
>     enp1s0f5:9ffb4601-dc86-4831-a2c1-554e0b87f201:802-3-ethernet:     |  
> Nothing asked for this!!!!
>     enp1s0f6:21693f80-ff31-49d9-8d30-cb8e95ad2891:802-3-ethernet:     |
>     enp1s0f7:9ac58f75-f1be-4d57-86bd-fd6f6ec616d9:802-3-ethernet:     |
>     enp2s0:e2d6c27e-c7cf-4776-97cc-06224b0a454f:802-3-ethernet: <-----'
> 
>     # nmcli -t con show enp1s0f1 | grep -e ^connection.*:enp -e ipv4.add
>     connection.id:enp1s0f1 <--------------.
>     connection.interface-name:enp1s0f1 <--+---- Fixed
>     ipv4.addresses:192.168.122.254/24

> I am surprised that the NM fix involves creating dedicated connection with
> connection.id and connection.interface-name set. I wouldn't expect this
> based on comment #19. In this case there is no need to fix on Anaconda side
> (bug 1910438).

For 3. now NM creates a single "Wired Connection" with the MAC address
set and no id or interface-name:

  [root@localhost ~]# rpm -q NetworkManager
  NetworkManager-1.30.0-4.1.bz1915493.el8.x86_64

  [root@localhost ~]# /usr/libexec/nm-initrd-generator --stdout -- BOOTIF=52-54-00-33-00-93 \
    ip=192.168.122.254::192.168.122.1:255.255.255.0:testhost.example.com::none:172.31.0.1:172.31.0.2

  *** Hostname 'testhost.example.com' ***

  *** Connection 'default_connection' ***

  [connection]
  id=Wired Connection
  uuid=3e8da025-8ac3-4797-a8b0-04e3574364e3
  type=ethernet
  autoconnect-retries=1
  multi-connect=1
  permissions=

  [ethernet]
  mac-address=52:54:00:33:00:93
  mac-address-blacklist=

  [ipv4]
  address1=192.168.122.254/24,192.168.122.1
  dhcp-hostname=testhost.example.com
  dhcp-timeout=90
  dns=172.31.0.1;172.31.0.2;
  dns-search=
  may-fail=false
  method=manual

  [ipv6]
  addr-gen-mode=eui64
  dhcp-hostname=testhost.example.com
  dhcp-timeout=90
  dns-search=
  method=disabled

  [proxy]


I don't know why the connection doesn't show up in the installed
system.

(In reply to James Hartsock from comment #21)
> Also needed libndp from following to build my 8.3 with updated NetworkManager
>   Used: https://brewweb.engineering.redhat.com/brew/buildinfo?buildID=1527698
> 
> # lorax --product='Red Hat Enterprise Linux' --version=8.3 --release=8.3
> --source=file:///scratch/repos/rhel8.3/{BaseOS,AppStream}
> --source=file:///scratch/repos/BZ1915493 --nomacboot --buildarch=x86_64
> --volid='RHEL 8.3' /scratch/RHEL8.3
> ...

I wonder if we should use latest RHEL 8.4 repos here:
http://download.eng.brq.redhat.com/nightly/rhel-8/RHEL-8/latest-RHEL-8.4/compose/

I was using
lorax --product="Red Hat Enterprise Linux" --version=8.4 --release=8.4 \
  --workdir ./lorax-work \
  --variant=BaseOS --nomacboot --buildarch=x86_64 --volid=RHEL-8-4-0-BaseOS-x86_64 \
  -s http://download.eng.brq.redhat.com/nightly/rhel-8/RHEL-8/latest-RHEL-8.4/compose/BaseOS/x86_64/os/ \
  -s http://download.eng.brq.redhat.com/nightly/rhel-8/RHEL-8/latest-RHEL-8.4/compose/AppStream/x86_64/os/ \
  -s http://download.eng.brq.redhat.com/nightly/rhel-8/RHEL-8/latest-RHEL-8.4/compose/CRB/x86_64/os/ \
  -s http://brew-task-repos.usersys.redhat.com/repos/scratch/bgalvani/NetworkManager/1.30.0/4.1.bz1915493.el8/x86_64/ \
  ./test/


to build:
http://file.brq.redhat.com/rvykydal/rhbz1915493/boot.iso

This iso seems to behave as expected to me, eg
- no other nics activated with DHCP
- no dedicated connection with connection.interface-name set, ie Anaconda patch still required
- specifying BOOTIF seems to work for me

I hope I am using the correct NM repo from scratch build.

(In reply to James Hartsock from comment #23)
> And a new issue present when I use the MAC-Address as <interface> in ip=
> directive as discussed earlier in this case
> 
> # egrep -o '(BOOTIF|ip)=[[:alnum:][:punct:]]*' /proc/cmdline
> ip=192.168.122.254::192.168.122.1:255.255.255.0:testhost.example.com:52-54-
> 00-33-00-93:none:172.31.0.1:172.31.0.2
> 
> # ip -o link show enp1s0f1 | grep -o 'ether [[:xdigit:]:]*'                 
> 
> ether 52:54:00:33:00:93
> 
> # nmcli -t con show
> 52\:54\:00\:33\:00\:93:b4fe3c0a-89dd-49d2-b1ac-94162a2f6392:802-3-ethernet:enp1s0f1
> enp1s0f0:fb60cf07-f5d9-41ad-9b71-32aab4021761:802-3-ethernet:               '  
> enp1s0f1:292c04db-cf8a-4b06-bd68-0a6e05c2137c:802-3-ethernet: <-------------+--------- DUPLICATE                 
> enp1s0f2:6c55e33f-66de-470d-a1a0-035887fc9780:802-3-ethernet:

Yeah, it's still the same issue as discussed above that Anaconda creates additional DHCP connections.

(In reply to Radek Vykydal from comment #26)
> http://brew-task-repos.usersys.redhat.com/repos/scratch/bgalvani/NetworkManager/1.30.0/4.1.bz1915493.el8/x86_64/ \
>   ./test/

> I hope I am using the correct NM repo from scratch build.

Yes, it looks correct.

(In reply to Beniamino Galvani from comment #25)
> > I am surprised that the NM fix involves creating dedicated connection with
> > connection.id and connection.interface-name set. I wouldn't expect this
> > based on comment #19. In this case there is no need to fix on Anaconda side
> > (bug 1910438).
> 
> For 3. now NM creates a single "Wired Connection" with the MAC address
> set and no id or interface-name:

Yes, that is what I am seeing with iso built in comment #26.

I've also prepared a scratch build with Anaconda fix, link to the repo is here:
https://bugzilla.redhat.com/show_bug.cgi?id=1910438#c20

Using also the anaconda scratch build the iso for testing with both Anaconda and NM fix should be created (similar to comment #26) like this:

lorax --product="Red Hat Enterprise Linux" --version=8.4 --release=8.4 \
  --workdir ./lorax-work \
  --variant=BaseOS --nomacboot --buildarch=x86_64 --volid=RHEL-8-4-0-BaseOS-x86_64 \
  -s http://download.eng.brq.redhat.com/nightly/rhel-8/RHEL-8/latest-RHEL-8.4/compose/BaseOS/x86_64/os/ \
  -s http://download.eng.brq.redhat.com/nightly/rhel-8/RHEL-8/latest-RHEL-8.4/compose/AppStream/x86_64/os/ \
  -s http://download.eng.brq.redhat.com/nightly/rhel-8/RHEL-8/latest-RHEL-8.4/compose/CRB/x86_64/os/ \
  -s http://brew-task-repos.usersys.redhat.com/repos/scratch/bgalvani/NetworkManager/1.30.0/4.1.bz1915493.el8/x86_64/ \
  -s http://brew-task-repos.usersys.redhat.com/repos/scratch/rvykydal/anaconda/33.16.4.13/2.el8/x86_64/ \
  ./test/

Honza (jstodola) from RTT would correct me eventually.

(In reply to Jan Stodola from comment #31)
> The command looks fine and here is boot.iso containing both anaconda and
> NetworkManager updated:
> http://file.emea.redhat.com/jstodola/bugs/1910438/boot_anaconda_nm.iso

Anaconda kickstart tests with the iso are passing with one exception (network-device-bootif-httpks for the record) that is related to case 2. from comment #2 I think. It is its modification where BOOTIF specifies another device than ip=. Regards both static and dhcp configuration, for example for

ip=ens3:dhcp BOOTIF=52-54-00-8e-57-91

where 52-54-00-8e-57-91 is MAC address of ens12 results in

RHEL 8.2 (dracut network module):
- both interfaces activated in initramfs
- ens3 and ens12 connections are active on respecitve devices in installer.

RHEL 8.4 development compose (8.3 would be the same I believe):
- both interfaces activated in initramfs
- ens3 connection is active on ens3 device and "BOOTIF Connection" active on ens12 initerface

The boot_anaconda_nm.iso from comment #31:
- no interface is activated in initramfs, installation hangs

The use case seems rather unusual to me, but I will let James and Jan comment on the severity of this change of behaviour.

In all cases (both dhcp or static configuration of ens3) the connection on ens12 is dhcp in comment #32.

I would prefer not to introduce this regression by this bug fix.
I do not see a reason why ens3 should not be configured with dhcp even though it's a different device than referenced by BOOTIF.

I think we should agree on what BOOTIF should do when there is another
ip= argument specifying an interface name (for example "ip=ens3:dhcp
BOOTIF=52-54-00-8e-57-91") Does it mean that:

 a) BOOTIF creates a new distinct connection with DHCP
    (the behaviour currently in 8.4)

 or

 b) the connection generated for ip= will be also be bound to the BOOTIF MAC
    (the behavior introduced by my patch)

?

From what I see in comment 2 (case 2) and comment 32, the legacy
module did b) or a) depending on whether the BOOTIF MAC matches (or
not) the MAC of the interface specified by ip=. Since the NM generator
potentially runs before interfaces are discovered, it can't do the
same and it must choose one of the two behaviors.

According to what Jan said, it would be a regression to introduce b)
in RHEL 8.4 and therefore I think we should drop my patch that changes
this behavior.

This means that in case 2 of comment 2 there will be an additional
"BOOTIF connection" created, which is not ideal but at least it
doesn't break the boot. And especially, users can fix this by simply
dropping the BOOTIF= parameter, as the ip= parameter already specifies
the interface name.

(In reply to Beniamino Galvani from comment #35)

Beniamino's approach seems reasonable to me.
 
> This means that in case 2 of comment 2 there will be an additional
> "BOOTIF connection" created, which is not ideal but at least it
> doesn't break the boot. And especially, users can fix this by simply
> dropping the BOOTIF= parameter, as the ip= parameter already specifies
> the interface name.

Actually the BOOTIF connection is not passed to the installed system which makes it even more acceptable I think.

So using the pxeboot initrd & vmlinuz files from ISO in comment #39 for testing here.
But note, that I do not have RHEL 8.4 stage 2 to match. Is there a full RHEL 8.4 ISO I can use to match (RHEL-8.4.0-20210309.1-x86_64-dvd1.iso was latest I found).

There are some concerning results in my testing

Test 3, 5, 6 all have connection named 'Wired Connection' and not the actual interface name.
Test 7 has connection name of the MAC address.
Teest 3, 5, 6, 7 all fail to set connection.{id,interface-name) to the interface name. In my experience this is what leads to anaconda not propegating a connection with the interface name to the final OS image install.

---

1.  BOOTIF= not used & '<interface>' ip= parameters on system with 1+ NICs

    # egrep -o '(BOOTIF|ip)=[[:alnum:][:punct:]]*' /proc/cmdline
    ip=192.168.122.254::192.168.122.1:255.255.255.0:testhost.example.com:enp1s0f1:none:172.31.0.1:172.31.0.2

    # ip link show enp1s0f1 | grep -o ether.*brd
    ether 52:54:00:33:00:93 brd

    # ip -o -4 addr  | grep -o '^[0-9]: enp.*scope'
    3: enp1s0f1    inet 192.168.122.254/24 brd 192.168.122.255 scope

    # nmcli -t con show
    enp1s0f1:4fddd663-a21a-4540-a972-572b6280f11a:802-3-ethernet:enp1s0f1

    # nmcli -t con show enp1s0f1 | grep -e ^connection.*:enp -e ipv4.add
    connection.id:enp1s0f1
    connection.interface-name:enp1s0f1
    ipv4.addresses:192.168.122.254/24


2.  BOOTIF=<MAC> used & '<interface>' ip= parameters on system with 1+ NICs

    # egrep -o '(BOOTIF|ip)=[[:alnum:][:punct:]]*' /proc/cmdline
    BOOTIF=52-54-00-33-00-93
    ip=192.168.122.254::192.168.122.1:255.255.255.0:testhost.example.com:enp1s0f1:none:172.31.0.1:172.31.0.2

    # ip link show enp1s0f1 | grep -o ether.*brd
    ether 52:54:00:33:00:93 brd

    # ip -o -4 addr  | grep -o '^[0-9]: enp.*scope'
    3: enp1s0f1    inet 192.168.122.89/24 brd 192.168.122.255 scope

    # nmcli -t con show
    BOOTIF Connection:7d065072-97dc-41f9-b360-67d52adf93da:802-3-ethernet:enp1s0f1
    enp1s0f1:db37862c-e2a8-4bf2-a9f6-bc3093da9622:802-3-ethernet:

    # nmcli -t con show enp1s0f1 | grep -e ^connection.*:enp -e ipv4.add
    connection.id:enp1s0f1
    connection.interface-name:enp1s0f1
    ipv4.addresses:192.168.122.254/24


3.  BOOTIF=<MAC> used & blank '<interface>' parameter in ip= directive on system with 1+ NICs.  Needed when customer knows MAC address but not interface name prior to install over network (no DHCP).

    # egrep -o '(BOOTIF|ip)=[[:alnum:][:punct:]]*' /proc/cmdline
    BOOTIF=52-54-00-33-00-93
    ip=192.168.122.254::192.168.122.1:255.255.255.0:testhost.example.com::none:172.31.0.1:172.31.0.2

    # ip link show enp1s0f1 | grep -o ether.*brd
    ether 52:54:00:33:00:93 brd

    # ip -o -4 addr  | grep -o '^[0-9]: enp.*scope'
    3: enp1s0f1    inet 192.168.122.254/24 brd 192.168.122.255 scope

    # nmcli -t con show
    Wired Connection:bc9cc698-e2f0-48ce-a207-0c2911c83f1a:802-3-ethernet:enp1s0f1

    # nmcli -t con show Wired\ Connection | grep -e ^connection.*:enp -e ipv4.add
    ipv4.addresses:192.168.122.254/24


4. SKIPPING AGAIN (I failed to counting in comment #2)


5.  BOOTIF not used & blank '<interface>' (ie ::) in ip= parameters on system with 2+ NICs.

    # egrep -o '(BOOTIF|ip)=[[:alnum:][:punct:]]*' /proc/cmdline
    ip=192.168.122.254::192.168.122.1:255.255.255.0:testhost.example.com::none:172.31.0.1:172.31.0.2

    # ip link show enp1s0f1 | grep -o ether.*brd
    ether 52:54:00:33:00:93 brd

    # ip -o -4 addr  | grep -o '^[0-9]: enp.*scope'
    3: enp1s0f1    inet 192.168.122.254/24 brd 192.168.122.255 scope

    # nmcli -t con show
    Wired Connection:6bfce1ee-aa5a-4d3d-be3b-55f6f2234e93:802-3-ethernet:enp1s0f1

    # nmcli -t con show Wired\ Connection | grep -e ^connection.*:enp -e ipv4.add
    ipv4.addresses:192.168.122.254/24


6.  BOOTIF not used & blank '<interface>' (ie ::) in ip= parameters on system with 1 NIC
    # egrep -o '(BOOTIF|ip)=[[:alnum:][:punct:]]*' /proc/cmdline
    ip=192.168.122.254::192.168.122.1:255.255.255.0:testhost.example.com::none:172.31.0.1:172.31.0.2

    # ip link show enp1s0 | grep -o ether.*brd
    ether 52:54:00:33:00:93 brd

    # ip -o -4 addr  | grep -o '^[0-9]: enp.*scope'
    2: enp1s0    inet 192.168.122.254/24 brd 192.168.122.255 scope

    # nmcli -t con show
    Wired Connection:c69fa077-b96d-4a55-a5d2-96ca4669f770:802-3-ethernet:enp1s0

    # nmcli -t con show Wired\ Connection | grep -e ^connection.*:enp -e ipv4.add
    ipv4.addresses:192.168.122.254/24


7.  BOOTIF not used & MAC-ADDR for ip= directive <interface> option

    # egrep -o '(BOOTIF|ip)=[[:alnum:][:punct:]]*' /proc/cmdline
    ip=192.168.122.254::192.168.122.1:255.255.255.0:testhost.example.com:52-54-00-33-00-93:none:172.31.0.1:172.31.0.2

    # ip link show enp1s0f1 | grep -o ether.*brd
    ether 52:54:00:33:00:93 brd

    # ip -o -4 addr  | grep -o '^[0-9]: enp.*scope'
    3: enp1s0f1    inet 192.168.122.254/24 brd 192.168.122.255 scope

    # nmcli -t con show
    52\:54\:00\:33\:00\:93:6440e800-2cdc-400c-abe5-283d802d556d:802-3-ethernet:enp1s0f1

    # nmcli -t con show 6440e800-2cdc-400c-abe5-283d802d556d | grep -e ^connection.*:enp -e ipv4.add
    ipv4.addresses:192.168.122.254/24

(In reply to James Hartsock from comment #41)
> So using the pxeboot initrd & vmlinuz files from ISO in comment #39 for
> testing here.
> But note, that I do not have RHEL 8.4 stage 2 to match. Is there a full RHEL
> 8.4 ISO I can use to match (RHEL-8.4.0-20210309.1-x86_64-dvd1.iso was latest
> I found).
> 

To test the fix also Anaconda updates should be included, which means the stage2 from the generated boot.iso needs to be used.
The stage2 is contained on the boot.iso as images/install.img. You can put it in some http location <URL>/images/install.img and add inst.stage2 installer boot option to use it:
inst.stage2=<URL>
Note that the url does not point directly to the install.img file but to the directory containing the path images/install.img, similar as if you would
use inst.stage2=http://download.eng.bos.redhat.com/rhel-8/development/RHEL-8/latest-RHEL-8/compose/BaseOS/x86_64/os/
to download the stage 2 from an installation tree.

The installation tree to use as software source can be the latest RHEL 8.4, ie using boot option
inst.repo=http://download.eng.bos.redhat.com/rhel-8/development/RHEL-8/latest-RHEL-8/compose/BaseOS/x86_64/os/ (additionally to inst.stage2)

> There are some concerning results in my testing

I am not sure if the testing info is relevant with testing the NM change only actually (because the Anaconda changes in the install.img from the boot.iso were not used). Also using vmlinuz+initrd.img with install.img from different composes (installer isos) is not supported and can have various unpredicted side-effects.

> Test 3, 5, 6 all have connection named 'Wired Connection' and not the actual
> interface name.
> Test 7 has connection name of the MAC address.
> Teest 3, 5, 6, 7 all fail to set connection.{id,interface-name) to the
> interface name. In my experience this is what leads to anaconda not
> propegating a connection with the interface name to the final OS image
> install.

To make sure we are on the same note - we agreed with NM that the fix on NM side would not involve creating of the connection bound to interface name but instead anaconda will apply a patch that would clone the "Wired Connection" to a persistent connection bound to the interface (Anaconda part of the fix in bug 1910438).
So it is relevant to check the connections passed to installed system or edited in UI - these should be the connections bound to the inteface by its .id and .interface-name (generated by Anaconda), while the connections used during installation will still be in most of the cases the connections ("Wired connection") created in initramfs.

Tha case 7 may be something to think/look about. I am not sure what is the expected (8.2, 7.X?) behaviour here.

(In reply to Radek Vykydal from comment #42)
 
> Tha case 7 may be something to think/look about. I am not sure what is the
> expected (8.2, 7.X?) behaviour here.


(In reply to James Hartsock from comment #41)
 
> 7.  BOOTIF not used & MAC-ADDR for ip= directive <interface> option
> 
>     # egrep -o '(BOOTIF|ip)=[[:alnum:][:punct:]]*' /proc/cmdline
>    
> ip=192.168.122.254::192.168.122.1:255.255.255.0:testhost.example.com:52-54-
> 00-33-00-93:none:172.31.0.1:172.31.0.2
> 
>     # ip link show enp1s0f1 | grep -o ether.*brd
>     ether 52:54:00:33:00:93 brd
> 
>     # ip -o -4 addr  | grep -o '^[0-9]: enp.*scope'
>     3: enp1s0f1    inet 192.168.122.254/24 brd 192.168.122.255 scope
> 
>     # nmcli -t con show
>    
> 52\:54\:00\:33\:00\:93:6440e800-2cdc-400c-abe5-283d802d556d:802-3-ethernet:
> enp1s0f1
> 
>     # nmcli -t con show 6440e800-2cdc-400c-abe5-283d802d556d | grep -e
> ^connection.*:enp -e ipv4.add
>     ipv4.addresses:192.168.122.254/24

My observations testing the boot.iso from comment #30:

* In RHEL 8.2 in intramfs ifcfg file with ifcfg-enp1s0f1 name(NAME=enp1s0f1), bound to DEVICE=enp1s0f1 with the correct static configuration would be created. And this is the connection that would be edited in Anaconda UI, or passed to installed system.

* In RHEL 8.3 the configuration would fail in initramfs.

* With boot.iso from comment #30 (same observations as James did above):
- connection named by MAC, bound to MAC address (802-3-ethernet.mac-address) is created
- Anaconda does not match this connection in any way and creates (not activates) default connection for the device, named enp1s0f1 with ipv4.method auto. This would be edited in UI and passed to installed system.

We'll most probably need a patch in Anaconda for creating of persistent connection from the connection created by NM in this case (7.).

There is a few questions though:

(1) would it be acceptable to NM name the connection by iface (setting connection.id also to the name)
(2) would it be acceptable to NM to bind the connection by interface-name, ie the connection is specified by MAC in options but bind by interface (which is the default for installer, even in kickstart when a device is specified by MAC, we bind the created connection by interface unless special --bindto=mac option is used)

Given traditional installer behavior (and same as in 8.2), the installer should transform the connection created by NM into a connection
- named by interface (ifcfg-enp1s0f1)
- bound to interface name
That would require more or less modifications on Anaconda side depending on how NM decides on (1) and (2)

Also perhaps we should handle the case 7. (comment #43) in a separate bug as it seems to be getting out of scope of the original issue in bug 1910438 ? And I would hate to block resolving bug 1910438 by the case 7.

(In reply to Radek Vykydal from comment #43)

> Given traditional installer behavior (and same as in 8.2), the installer
> should transform the connection created by NM into a connection
> - named by interface (ifcfg-enp1s0f1)

this is required 

> - bound to interface name

this may be debatable, but we already do that for connections created via BOOTIF= so it would be good to be consistent here

(In reply to Radek Vykydal from comment #43)
 
> Given traditional installer behavior (and same as in 8.2), the installer
> should transform the connection created by NM into a connection
> - named by interface (ifcfg-enp1s0f1)
> - bound to interface name
> That would require more or less modifications on Anaconda side depending on
> how NM decides on (1) and (2)

If the behaviour of (1) and (2) stays as in current patch (comment #39), Anaconda needs this patch:
https://github.com/rhinstaller/anaconda/pull/3258

(In reply to Radek Vykydal from comment #43)

fixing a reference type
 
> My observations testing the boot.iso from comment #30:
> 

I mean comment #39

> 
> * With boot.iso from comment #30 (same observations as James did above):

I mean comment #39

(In reply to Radek Vykydal from comment #43)

> (1) would it be acceptable to NM name the connection by iface (setting
> connection.id also to the name)

> (2) would it be acceptable to NM to bind the connection by interface-name,
> ie the connection is specified by MAC in options but bind by interface
> (which is the default for installer, even in kickstart when a device is
> specified by MAC, we bind the created connection by interface unless special
> --bindto=mac option is used)

In the current architecture of the NM dracut module, the output of the initrd generator depends only on the kernel command line, and not on the actual devices present on the machine.

Therefore, if the kernel command line only contains the MAC it is not possible to create a connection bound to the interface name because the generator doesn't have any knowledge on how to map the MAC address to an interface name.

While this seems easy to implement, it's not, because the generator currently is run only once during the startup. Interfaces can appear at any time, and so if the generator looked at kernel links to determine the output, this would be racy.

(In reply to Beniamino Galvani from comment #48)
> (In reply to Radek Vykydal from comment #43)
> 
> > (1) would it be acceptable to NM name the connection by iface (setting
> > connection.id also to the name)
> 
> > (2) would it be acceptable to NM to bind the connection by interface-name,
> > ie the connection is specified by MAC in options but bind by interface
> > (which is the default for installer, even in kickstart when a device is
> > specified by MAC, we bind the created connection by interface unless special
> > --bindto=mac option is used)
> 
> In the current architecture of the NM dracut module, the output of the
> initrd generator depends only on the kernel command line, and not on the
> actual devices present on the machine.
> 
> Therefore, if the kernel command line only contains the MAC it is not
> possible to create a connection bound to the interface name because the
> generator doesn't have any knowledge on how to map the MAC address to an
> interface name.
> 
> While this seems easy to implement, it's not, because the generator
> currently is run only once during the startup. Interfaces can appear at any
> time, and so if the generator looked at kernel links to determine the
> output, this would be racy.

I see, then we can go with Anaconda patch from comment #46.

(In reply to Radek Vykydal from comment #44)
> Also perhaps we should handle the case 7. (comment #43) in a separate bug as
> it seems to be getting out of scope of the original issue in bug 1910438 ?
> And I would hate to block resolving bug 1910438 by the case 7.

Given there would be no additional change in NM and Anaconda patch would be safe and isolated I think we could fix the case 7. in scope of Anaconda bug 1910438 (related).

We have this covered in unit tests.

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