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 1873543

Summary: "network --nodefroute" seems to have no effect
Product: Red Hat Enterprise Linux 8 Reporter: Renaud Métrich <rmetrich>
Component: anacondaAssignee: Radek Vykydal <rvykydal>
Status: CLOSED DUPLICATE QA Contact: Release Test Team <release-test-team-automation>
Severity: medium Docs Contact:
Priority: medium    
Version: 8.2CC: jcastran, jkonecny, jstodola, rvykydal, sbarcomb
Target Milestone: rcKeywords: Patch, Triaged
Target Release: 8.0Flags: pm-rhel: mirror+
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2022-10-14 11:34:47 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
Kickstart to reproduce the issue
none
simplified kickstart (only "network" directives)
none
/tmp content
none
journal in rd.debug none

Description Renaud Métrich 2020-08-28 14:47:35 UTC
Created attachment 1712963 [details]
Kickstart to reproduce the issue

Description of problem:

When installing a VM with 2 network interfaces using "virt-install", a CDROM location and a kickstart, both network interfaces get configured as "DEFROUTE=yes" even though "--nodefroute was specified on one of them.


# grep network /run/install/ks.cfg 
network --hostname=vm-test
network --device ens2 --bootproto=static --ip=192.168.122.101 --netmask=255.255.255.0 --gateway=192.168.122.1 --noipv6 --nodefroute --activate
network --device ens3 --bootproto=static --ip=192.168.100.101 --netmask=255.255.255.0 --gateway=192.168.100.1 --noipv6 --activate

# ip r
default via 192.168.122.1 dev ens2 proto static metric 100 
default via 192.168.100.1 dev ens3 proto static metric 101 
192.168.100.0/24 dev ens3 proto kernel scope link src 192.168.100.101 metric 101 
192.168.122.0/24 dev ens2 proto kernel scope link src 192.168.122.101 metric 100 

Later after installation completes, /etc/sysconfig/network-scripts/ifcfg-XXX files will both contain "DEFROUTE=yes".


Version-Release number of selected component (if applicable):

29.19.2.17-1.el8 but also seen on RHEL 7


How reproducible:

Always


Steps to Reproduce:
1. Install a KVM with 2 disks and 2 network interfaces using the attached kickstart

# virt-install --name=test --memory=2048 --vcpus=2 --disk /tmp/test-01.img,size=23 --disk /tmp/test-02.img,size=20 --location rhel-8.2-x86_64-dvd.iso --network bridge=virbr0,model=virtio --network bridge=virbr1,model=virtio --os-variant=rhel7 --graphics=none --initrd-inject /tmp/kickstart_test.cfg --extra-args="ks=file:/kickstart_test.cfg console=tty0 console=ttyS0,115200n8 rd.debug"

2. Check the network in the console

Actual results:

See above description


Expected results:

ens2 configured without a default route.


Additional info:

2nd bug: When no "network --hostname=vm-test" is removed and only "network --device" stanzas are used, dracut still configured the first network interface specified in the kickstart with "DEFROUTE=yes":

Kickstart:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
network --device ens2 --bootproto=static --ip=192.168.122.101 --netmask=255.255.255.0 --gateway=192.168.122.1 --noipv6 --nodefroute --activate --hostname=vm-test
network --device ens3 --bootproto=static --ip=192.168.100.101 --netmask=255.255.255.0 --gateway=192.168.100.1 --noipv6 --activate
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

Result:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
# grep DEFROUTE /etc/sysconfig/network-scripts/ifcfg-ens2
DEFROUTE="yes"
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

Comment 1 Renaud Métrich 2020-09-01 11:29:00 UTC
This seems to only affect installation performed using "virt-install".
Using virt-manager doesn't reproduce.

Comment 2 Radek Vykydal 2020-09-01 12:58:21 UTC
(In reply to Renaud Métrich from comment #1)
> This seems to only affect installation performed using "virt-install".
> Using virt-manager doesn't reproduce.

The --nodefroute option is not working in case network device is activated in initramfs - when configuring network using dracut ip= boot options there is no way to specify something like --nodefroute (if I am not mistaken).
This applies also to the case (of this BZ - ks=file:/kickstart_test.cfg) when network is not required/activated to fetch kickstart (that would be done by default dhcp on all interfaces) and therefore the configuration from kickstart is applied already in initramfs. In this case it is translated to dracut boot options (so no way to specify --nodefroute) and executed by dracut network module (or NM).

A workaround here could be activating any device via boot options (eg ip=dhcp rd.neednet=1) so the kickstart is applied after switchroot by NM where the --nodefroute option is honored.

For the fix, ideally dracut could offer configuration for --nodefroute behaviour (ipv4.never-default or ipv6.never-default NetworkManager settings) that could be applied by NM in initramfs (since RHEL 8.3).

Comment 3 Renaud Métrich 2020-09-01 13:31:37 UTC
I'm not sure this is related to dracut at all.

1. Installing using virt-manager a system booted from cdrom with "ip=dhcp inst.ks=..." on the kernel command line doesn't reproduce.
2. Booting with virt-install and "rd.break" shows no network is configured in dracut

So it's NetworkManager that brings the network up after switching root

Comment 4 Radek Vykydal 2020-09-01 14:41:47 UTC
Could you please attach installation log /tmp/syslog from reproducer with rd.debug boot option added?

Comment 5 Renaud Métrich 2020-09-01 14:59:58 UTC
Created attachment 1713327 [details]
simplified kickstart (only "network" directives)

Comment 6 Renaud Métrich 2020-09-01 15:01:51 UTC
Created attachment 1713328 [details]
/tmp content

Comment 7 Renaud Métrich 2020-09-01 15:02:37 UTC
Created attachment 1713329 [details]
journal in rd.debug

Comment 8 Renaud Métrich 2020-09-01 15:05:00 UTC
The journal shows anaconda starts from scratch (no interface configured). NetworkManager sets the default route:

Sep 01 14:48:49.347577 localhost anaconda[1741]: anaconda: network: devices found ['enp1s0', 'enp2s0']
Sep 01 14:48:49.347700 localhost anaconda[1741]: ifcfg: content of files (network initialization): 
Sep 01 14:48:49.349330 localhost anaconda[1741]: ifcfg: all settings: [] 
Sep 01 14:48:49.349447 localhost anaconda[1741]: anaconda: network: ensure single initramfs connections
Sep 01 14:48:49.377723 localhost anaconda[1741]: anaconda: network: apply kickstart
Sep 01 14:48:49.382618 localhost anaconda[1741]: anaconda: network: apply kickstart: --device  does not exist
Sep 01 14:48:49.411332 localhost anaconda[1741]: anaconda: network: ifcfg file for enp1s0 not found  
Sep 01 14:48:49.411520 localhost anaconda[1741]: anaconda: network: pre kickstart - adding connection for enp1s0
Sep 01 14:48:49.416802 localhost NetworkManager[1596]: <debug> [1598971729.4167] ++ connection 'new connection' (0x563fe6b5c8a0/NMSimpleConnection/"802-3-ethernet"): [/org/freedesktop/NetworkManager/Settings/1]
...
Sep 01 14:48:49.425050 localhost NetworkManager[1596]: <debug> [1598971729.4250] device[179d6b62631192f0] (enp1s0): queued IP4 config change
Sep 01 14:48:49.425060 localhost NetworkManager[1596]: <debug> [1598971729.4250] platform-linux: do-add-ip4-address[2: 192.168.122.101/24]: success
Sep 01 14:48:49.425068 localhost NetworkManager[1596]: <debug> [1598971729.4250] platform: (enp1s0) route: append     IPv4 route: 192.168.122.0/24 via 0.0.0.0 dev 2 metric 100 mss 0 rt-src rt-kernel scope link pref-src 192.168.122.101
Sep 01 14:48:49.425089 localhost NetworkManager[1596]: <debug> [1598971729.4250] platform: (enp1s0) signal: route   4   added: 192.168.122.0/24 via 0.0.0.0 dev 2 metric 100 mss 0 rt-src rt-kernel scope link pref-src 192.168.122.101
Sep 01 14:48:49.425097 localhost NetworkManager[1596]: <debug> [1598971729.4250] platform-linux: do-add-ip4-route[192.168.122.0/24 via 0.0.0.0 dev 2 metric 100 mss 0 rt-src rt-kernel scope link pref-src 192.168.122.101]: success
Sep 01 14:48:49.425103 localhost NetworkManager[1596]: <debug> [1598971729.4251] platform: (enp1s0) route: append     IPv4 route: 0.0.0.0/0 via 192.168.122.1 dev 2 metric 100 mss 0 rt-src user
Sep 01 14:48:49.425119 localhost NetworkManager[1596]: <debug> [1598971729.4251] platform: (enp1s0) signal: route   4   added: 0.0.0.0/0 via 192.168.122.1 dev 2 metric 100 mss 0 rt-src rt-static scope global
Sep 01 14:48:49.425127 localhost NetworkManager[1596]: <debug> [1598971729.4251] platform-linux: do-add-ip4-route[0.0.0.0/0 via 192.168.122.1 dev 2 metric 100 mss 0 rt-src rt-static scope global]: success

Comment 9 Radek Vykydal 2020-09-03 09:59:54 UTC
Applying of kickstart configuration in initramfs fails because the network devices are not set up yet:

Sep 01 14:48:31.571860 localhost dracut-cmdline[310]: parse-kickstart DEBUG: ksdevice argument is not available
Sep 01 14:48:31.573450 localhost dracut-cmdline[310]: parse-kickstart INFO: processing kickstart file /tmp/ks.cfg
Sep 01 14:48:31.577542 localhost dracut-cmdline[310]: parse-kickstart DEBUG: kickstart line 1: handling network
Sep 01 14:48:31.578244 localhost dracut-cmdline[310]: parse-kickstart DEBUG: kickstart line 2: handling network
Sep 01 14:48:31.578786 localhost dracut-cmdline[310]: parse-kickstart INFO: can't find device enp1s0
Sep 01 14:48:31.579316 localhost dracut-cmdline[310]: parse-kickstart DEBUG: kickstart line 3: handling network
Sep 01 14:48:31.580047 localhost dracut-cmdline[310]: parse-kickstart INFO: can't find device enp2s0
Sep 01 14:48:31.580047 localhost dracut-cmdline[310]: parse-kickstart INFO: finished parsing kickstart
...
Sep 01 14:48:35.109318 localhost kernel: virtio_net virtio0 enp1s0: renamed from eth0

Anaconda then tries to apply the kickstart after switch root:

Sep 01 14:48:49.411520 localhost anaconda[1741]: anaconda: network: pre kickstart - adding connection for enp1s0

The --nodefroute option is not applied in this case, upstream PR with fix:
https://github.com/rhinstaller/anaconda/pull/2825


To workaround the issue the kickstart can be fetched from network (in this case the network devices are all set up when parsing the kickstart and creating configuration for NM) but maybe it won't fit into your use case.

Comment 12 Jan Stodola 2022-10-12 14:39:28 UTC
I was able to reproduce this problem on RHEL-8.5, but not on RHEL-8.6 any more. Perhaps the problem was fixed in bug 1990145. Can you confirm that, Radek?


The "2nd bug" from comment 0 is also fixed for DEFROUTE, however IPV6_DEFROUTE is set to "yes" for both devices - which doesn't look correct, especially when --noipv6 was used in the kickstart file:

[anaconda root@vm-test ~]# grep DEFROUTE /etc/sysconfig/network-scripts/*
/etc/sysconfig/network-scripts/ifcfg-enp1s0:DEFROUTE=no
/etc/sysconfig/network-scripts/ifcfg-enp1s0:IPV6_DEFROUTE=yes
/etc/sysconfig/network-scripts/ifcfg-enp2s0:DEFROUTE=yes
/etc/sysconfig/network-scripts/ifcfg-enp2s0:IPV6_DEFROUTE=yes
[anaconda root@vm-test ~]#

Comment 13 Radek Vykydal 2022-10-13 07:40:35 UTC
(In reply to Jan Stodola from comment #12)
> I was able to reproduce this problem on RHEL-8.5, but not on RHEL-8.6 any
> more. Perhaps the problem was fixed in bug 1990145. Can you confirm that,
> Radek?
> 

Yes.

> The "2nd bug" from comment 0 is also fixed for DEFROUTE, however
> IPV6_DEFROUTE is set to "yes" for both devices - which doesn't look correct,
> especially when --noipv6 was used in the kickstart file:

The --nodefroute option is targeting only IPv4 configuration. For IPv6 we would probably need to add another option (in a similar way as we have --gateway and --ipv6gateway).
Regarding the --noipv6 option, it is something we should address separately eventually, perhaps in the context of bug 1767091.

Comment 14 Jan Stodola 2022-10-14 11:34:47 UTC
OK, so I'm closing this bug as a duplicate 1990145, since the original issue has been already resolved.

*** This bug has been marked as a duplicate of bug 1990145 ***