Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1853277

Summary: anaconda sets ONBOOT=yes for NICs not used for installation
Product: Red Hat Enterprise Linux 8 Reporter: Jan Tluka <jtluka>
Component: NetworkManagerAssignee: Beniamino Galvani <bgalvani>
Status: CLOSED ERRATA QA Contact: Desktop QE <desktop-qa-list>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 8.3CC: acardace, atragler, bgalvani, lnst-team, lnykryn, lrintel, rkhan, rvykydal, sukulkar, thaller, till, vbenes
Target Milestone: rcKeywords: Regression, TestBlocker
Target Release: 8.3Flags: pm-rhel: mirror+
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: NetworkManager-1.26.0-0.2.1.el8 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-11-04 01:50:15 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 Flags
anaconda logs RHEL-8.3.0-20200616.0 none

Description Jan Tluka 2020-07-02 10:43:47 UTC
Description of problem:

With compose RHEL-8.3.0-20200616.0, the RHEL installation ends up with ONBOOT=yes configured in /etc/sysconfig/network-scripts/ifcfg* files (those that have a link).

This is different from RHEL-8.2.0 where only the interface that was used for installation has ONBOOT=yes, the rest of interfaces have ONBOOT=no.

Version-Release number of selected component (if applicable):
anaconda-33.16.3.6-1.el8

How reproducible:


Steps to Reproduce:
1. install RHEL-8.3.0-20200616.0 on a machine that has multiple NICs available
2. check the ONBOOT parameter in /etc/sysconfig/network-scripts/ifcfg*
3.

Actual results:

With RHEL-8.2.0, relevant devices are p5p1 and p5p2

/etc/sysconfig/network-scripts/ifcfg-em3
# Generated by parse-kickstart
TYPE="Ethernet"
DEVICE="em3"
UUID="3693cacf-355f-4be3-9fcc-08beb04ae594"
ONBOOT="yes"
BOOTPROTO="dhcp"
DHCP_HOSTNAME="wsfd-netdev54.ntdv.lab.eng.bos.redhat.com"
IPV6INIT="yes"

/etc/sysconfig/network-scripts/ifcfg-em4
TYPE=Ethernet
PROXY_METHOD=none
BROWSER_ONLY=no
BOOTPROTO=dhcp
DEFROUTE=yes
IPV4_FAILURE_FATAL=no
IPV6INIT=yes
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
IPV6_FAILURE_FATAL=no
IPV6_ADDR_GEN_MODE=stable-privacy
NAME=em4
UUID=7561459a-37c7-497c-9f3b-38f2a0d3a54f
DEVICE=em4
ONBOOT=no

/etc/sysconfig/network-scripts/ifcfg-p5p1
TYPE=Ethernet
PROXY_METHOD=none
BROWSER_ONLY=no
BOOTPROTO=dhcp
DEFROUTE=yes
IPV4_FAILURE_FATAL=no
IPV6INIT=yes
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
IPV6_FAILURE_FATAL=no
IPV6_ADDR_GEN_MODE=stable-privacy
NAME=p5p1
UUID=dd731afa-0996-4de2-b917-b7729295fd65
DEVICE=p5p1
ONBOOT=no

/etc/sysconfig/network-scripts/ifcfg-p5p2
TYPE=Ethernet
PROXY_METHOD=none
BROWSER_ONLY=no
BOOTPROTO=dhcp
DEFROUTE=yes
IPV4_FAILURE_FATAL=no
IPV6INIT=yes
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
IPV6_FAILURE_FATAL=no
IPV6_ADDR_GEN_MODE=stable-privacy
NAME=p5p2
UUID=0af171c5-b9f2-4da9-9ef3-867859a4589a
DEVICE=p5p2
ONBOOT=no
++ echo


With RHEL-8.3.0-20200616.0, this is on different machine, the relevant devices are em1 and em2

/etc/sysconfig/network-scripts/ifcfg-em1
TYPE=Ethernet
PROXY_METHOD=none
BROWSER_ONLY=no
BOOTPROTO=dhcp
DEFROUTE=yes
IPV4_FAILURE_FATAL=no
IPV6INIT=yes
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
IPV6_FAILURE_FATAL=no
IPV6_ADDR_GEN_MODE=stable-privacy
NAME=em1
UUID=71f97506-ee8b-4f32-8c34-b54eaeedb555
DEVICE=em1
ONBOOT=yes

/etc/sysconfig/network-scripts/ifcfg-em2
TYPE=Ethernet
PROXY_METHOD=none
BROWSER_ONLY=no
BOOTPROTO=dhcp
DEFROUTE=yes
IPV4_FAILURE_FATAL=no
IPV6INIT=yes
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
IPV6_FAILURE_FATAL=no
IPV6_ADDR_GEN_MODE=stable-privacy
NAME=em2
UUID=e611f3a2-fbb5-4846-9472-05d2c7af962c
DEVICE=em2
ONBOOT=yes

/etc/sysconfig/network-scripts/ifcfg-em3
# Generated by parse-kickstart
TYPE=Ethernet
DEVICE=em3
UUID=7930441d-9b31-426e-84ec-b448b7b3816f
ONBOOT=yes
BOOTPROTO=dhcp
DHCP_HOSTNAME=wsfd-netdev56.ntdv.lab.eng.bos.redhat.com
IPV6INIT=yes
PROXY_METHOD=none
BROWSER_ONLY=no
DEFROUTE=yes
IPV4_FAILURE_FATAL=no
IPV6_AUTOCONF=yes
DHCPV6_HOSTNAME=wsfd-netdev56.ntdv.lab.eng.bos.redhat.com
IPV6_DEFROUTE=yes
IPV6_FAILURE_FATAL=no
NAME="System em3"

/etc/sysconfig/network-scripts/ifcfg-em4
TYPE=Ethernet
PROXY_METHOD=none
BROWSER_ONLY=no
BOOTPROTO=dhcp
DEFROUTE=yes
IPV4_FAILURE_FATAL=no
IPV6INIT=yes
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
IPV6_FAILURE_FATAL=no
IPV6_ADDR_GEN_MODE=stable-privacy
NAME=em4
UUID=e0349aff-43a0-4d71-88f1-4c357ae479fe
DEVICE=em4
ONBOOT=no


Expected results:
ONBOOT=no for devices not used for installation

Additional info:

Comment 1 Radek Vykydal 2020-07-02 12:50:44 UTC
Jan, could you please attach logs from the installation?
Either /tmp/syslog from installed environment or
/var/log/anaconda/journal.log from installed system.

Comment 2 Radek Vykydal 2020-07-02 12:51:15 UTC
(In reply to Radek Vykydal from comment #1)
> Jan, could you please attach logs from the installation?
> Either /tmp/syslog from installed environment or
I mean from *installer* environment

Comment 3 Radek Vykydal 2020-07-02 13:31:00 UTC
I am not able to reproduce the issue in common use cases, also our kickstart tests don't indicate any regression.

Comment 4 Jan Tluka 2020-07-02 13:35:54 UTC
Created attachment 1699632 [details]
anaconda logs RHEL-8.3.0-20200616.0

Logs from the installer, compose RHEL-8.3.0-20200616.0.

Comment 5 Jan Tluka 2020-07-02 13:37:20 UTC
(In reply to Jan Tluka from comment #4)
> Created attachment 1699632 [details]
> anaconda logs RHEL-8.3.0-20200616.0
> 
> Logs from the installer, compose RHEL-8.3.0-20200616.0.

Relevant devices are em1 and em2.

Comment 6 Jan Tluka 2020-07-02 13:48:14 UTC
For the reference, here's a beaker job link.

https://beaker.engineering.redhat.com/jobs/4396507

Comment 7 Radek Vykydal 2020-07-03 10:10:29 UTC
(In reply to Jan Tluka from comment #5)
> (In reply to Jan Tluka from comment #4)
> > Created attachment 1699632 [details]
> > anaconda logs RHEL-8.3.0-20200616.0

As per IRC communication with Jan the issue started to appear at this compose, which could point to a new NetworkManager version (1:1.25.2-1 -> 1:1.26.0-0.1). There are no changes in Anaconda that could cause a regression of this kind (anconda 33.16.3.5-1 -> 33.16.3.6-1).

I think a change in NM could maybe cause the regression by some race condition starting to appear, I am not not sure which rhel 8.3 compose (NM version) was actually working for the setup. 

Nevertheless, the root cause - and regression / change of behavior compared to RHEL 8.2 seems to be handling of BOOTIF installer boot option (supplied by PXE) by NM dracut module. 


> 
> Relevant devices are em1 and em2.

Unlike in RHEL 8.2 (dracut network module) the em1 and em2 devices are unsuccessfully tried to be activated in initramfs (using dhcp) and also after switchroot, which is making the ONBOOT value to be set to yes for installed system (assuming there was an intention to have them activated/configured in installer and therefore in target system).

In RHEL 8.2 only the device specified by BOOTIF option (em3) would be activated in intramfs.

Thomas, any ideas about NM dracut module honouring BOOTIF option (as the legacy dracut network module used to I believe) ?
I'll look at it as well.

Comment 8 Radek Vykydal 2020-07-03 10:19:54 UTC
(In reply to Radek Vykydal from comment #7)
 
> Thomas, any ideas about NM dracut module honouring BOOTIF option (as the
> legacy dracut network module used to I believe) ?

Asking also Lukas from dracut.

Comment 9 Radek Vykydal 2020-07-03 11:21:52 UTC
 
> Thomas, any ideas about NM dracut module honouring BOOTIF option (as the
> legacy dracut network module used to I believe) ?
> I'll look at it as well.

Connections generated in initramfs:

# cat /run/NetworkManager/system-connections/default_connection.nmconn
[connection]
id=Wired Connection
uuid=58e90d13-6186-470e-b8d3-480899ab1489
type=ethernet
multi-connect=3
permissions=

[ethernet]
mac-address-blacklist=

[ipv4]
dns-search=
method=auto

[ipv6]
addr-gen-mode=eui64
dns-search=
method=auto

[proxy]

pre-pivot:/# cat /proc/cmdline
initrd=test/rv/scripted/r83-latest/initrd.img repo=http://download.eng.brq.redhat.com/rhel-8/nightly/RHEL-8/latest-RHEL-8.3.0/compose/BaseOS/x86_64/os/ inst.addrepo=APPSTREAM,http://download.eng.brq.redhat.com/rhel-8/nightly/RHEL-8/latest-RHEL-8.3/compose/AppStream/x86_64/os/ updates=http://10.43.136.2/ks/rv/updates.bootvirtual.img ksdevice=52:54:00:9f:21:28 ks=http://10.43.136.2/ks/rv/ks.onboot83.cfg rd.break=pre-pivot rd.bootif=1 console=ttyS0 BOOT_IMAGE=test/rv/scripted/r83-latest/vmlinuz BOOTIF=01-52-54-00-9f-21-28 
pre-pivot:/# /usr/libexec/nm-initrd-generator BOOTIF=01-52-54-00-9f-21-28 -s

(nm-initrd-generator:1546): libnm-CRITICAL **: 11:20:48.010: ((libnm-core/nm-setting-wired.c:205)): assertion '<dropped>' failed

(nm-initrd-generator:1546): GLib-GObject-CRITICAL **: 11:20:48.010: g_object_set: assertion 'G_IS_OBJECT (object)' failed

*** Connection 'default_connection' ***

[connection]
id=Wired Connection
uuid=b693a970-af74-47e3-ad69-eaab89fa7678
type=ethernet
multi-connect=3
permissions=

[ethernet]
mac-address-blacklist=

[ipv4]
dns-search=
method=auto

[ipv6]
addr-gen-mode=eui64
dns-search=
method=auto

[proxy]

Comment 10 Radek Vykydal 2020-07-03 11:45:38 UTC
Interestingly, if I add ip=dhcp to the boot options the generated connection seems to be as some we would expect (bound to MAC):

pre-pivot:/# /usr/libexec/nm-initrd-generator -s -- BOOTIF=01-52-54-00-9f-21-28 ip=dhcp

*** Connection 'default_connection' ***

[connection]
id=Wired Connection
uuid=0cb1ef31-a1c9-4541-9a5f-c5d87c4ac8be
type=ethernet
multi-connect=3
permissions=

[ethernet]
mac-address=52:54:99:9F:21:28
mac-address-blacklist=

[ipv4]
dns-search=
may-fail=false
method=auto

[ipv6]
addr-gen-mode=eui64
dns-search=
method=auto

[proxy]

Comment 11 Beniamino Galvani 2020-07-03 15:02:17 UTC
Hi, this is caused by a bug in the NM initrd generator, which creates a default connection without a mac-address property.

This upstream merge request fixes it:

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

I think this bz can be reassigned to NM.

Comment 12 Jan Tluka 2020-07-03 15:08:35 UTC
Adding TestBlocker. There's no workaround other than to use RHEL-8.2.0 for our test runs because of this bug.

Comment 16 Radek Vykydal 2020-07-07 12:53:06 UTC
For the reference, PR for Anaconda kickstart test for the issue: https://github.com/rhinstaller/kickstart-tests/pull/348

Comment 17 Vladimir Benes 2020-08-07 13:36:07 UTC
Covered in anaconda test suite. No auto test case added. Just default device now has ONBOOT set.

Comment 20 errata-xmlrpc 2020-11-04 01:50:15 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 (NetworkManager 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/RHBA-2020:4499