Description of problem: In RHCOS 4.6 we moved to using NetworkManager in the initramfs. This means we now use nm-initrd-generator to parse networking kernel arguments. In early versions of nm-initrd-generator there was a bug [1] where giving the nameserver= argument could lead to undesired results. This bug is fixed upstream [2] and in RHEL 8.3 (NetworkManager-1.26.0-0.2.el8.x86_64), which should be the basis for RHCOS 4.7. There is a full summary of the problem in the upstream bug [1]. Here is a summary of cases that work perfectly and cases that don't work and need to be worked around: 1. specifying nameserver as part of ip= argument - good, works as expected - `ip=${ip}::${gateway}:${netmask}:${hostname}:${devname}:none:${nameserver1}` - `ip=${ip}::${gateway}:${netmask}:${hostname}:${devname}:none:${nameserver1}:${nameserver2}` 2. specifying nameserver after a single ip= argument - good, works as expected - `ip=${ip}::${gateway}:${netmask}:${hostname}:${devname}:none nameserver=${nameserver1}` 3. specifying nameserver after multiple ip= arguments - partially bad, nameserver only gets applied to a single connection - `ip=${ip}::${gateway}:${netmask}:${hostname}:${devname}:none ip=${ip}::${gateway}:${netmask}:${hostname}:${devname}:none nameserver=${nameserver1}` 4. specifying nameserver before any ip= arguments - bad, gives extra "default" connection profile that has the nameserver - `nameserver=${nameserver1} ip=${ip}::${gateway}:${netmask}:${initramfshostname}:${devname}:none` To workaround case 3 you can: - change to the syntax in #1 - provide networking configs via Ignition To workaround case 4 you can: - move your nameserver= arg to the end of the kernel command line - be careful as this will likely land you in either case 2 (good) or case 3 (partially bad) - if you land in case 3 then see the above workaround for case 3 [1] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/391 [2] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/447 Version-Release number of selected component (if applicable): RHCOS 4.6 - How reproducible: Always Steps to Reproduce: 1. Set nameserver= argument before ip= arguments and view an extra connection file gets created in /etc/NetworkManager/system-connections/
and the version of the rpm (currently) in 4.6 is NetworkManager-1.22.8-6.el8_2.x86_64
I'm pre-emptively moving this BZ to POST as we should get the fix for free once when we use RHEL 8.3 in RHCOS 4.7
Also related to this https://github.com/coreos/fedora-coreos-config/pull/636
Marking for the UpcomingSprint; we know the fix is in NM, we are just waiting for all of our bits to switch over to 4.7
Marking for the UpcomingSprint; we know the fix is in NM as part of RHEL 8.3, we are waiting for RHCOS 4.7 to start using RHEL 8.3
RHCOS 47.83.202012020056-0 includes RHEL 8.3 and `NetworkManager-1.26.0-9.el8_3` which should include the fix in comment #1. Moving to MODIFIED
Verified with RHCOS 47.83.202012072242-0 ``` [core@coreos ~]$ rpm-ostree status State: idle Deployments: * ostree://d70e44dde4765c2b59cedae6c399c7255a4bb877cc80b1be5c93cbe614b1d395 Version: 47.83.202012072242-0 (2020-12-07T22:46:11Z) [core@coreos ~]$ rpm -q NetworkManager NetworkManager-1.26.0-9.el8_3.x86_64 [core@coreos ~]$ cat /proc/cmdline | more BOOT_IMAGE=(hd0,gpt3)/ostree/rhcos-da2a55fc8655016771f867e78910e69d6ee3b93e3cbc5 aad74660e2b8d9c8e19/vmlinuz-4.18.0-240.7.1.el8_3.x86_64 random.trust_cpu=on cons ole=tty0 console=ttyS0,115200n8 ignition.platform.id=qemu ignition.firstboot ost ree=/ostree/boot.1/rhcos/da2a55fc8655016771f867e78910e69d6ee3b93e3cbc5aad74660e2 b8d9c8e19/0 nameserver=192.168.122.1 ip=192.168.122.100::192.168.122.1:255.255.2 55.0:coreos:ens5:none [core@coreos ~]$ sudo ls /etc/NetworkManager/system-connections/ ens5.nmconnection [core@coreos ~]$ sudo cat /etc/NetworkManager/system-connections/ens5.nmconnectio [connection] id=ens5 uuid=4fa2d4eb-b6e8-402f-8d17-1ef93cae17f3 type=ethernet interface-name=ens5 multi-connect=1 permissions= [ethernet] mac-address-blacklist= [ipv4] address1=192.168.122.100/24,192.168.122.1 dhcp-hostname=coreos dns=192.168.122.1; dns-search= may-fail=false method=manual [ipv6] addr-gen-mode=eui64 dhcp-hostname=coreos dns-search= method=auto [proxy] ``` ``` [core@coreos ~]$ rpm-ostree status State: idle Deployments: * ostree://d70e44dde4765c2b59cedae6c399c7255a4bb877cc80b1be5c93cbe614b1d395 Version: 47.83.202012072242-0 (2020-12-07T22:46:11Z) [core@coreos ~]$ rpm -q NetworkManager NetworkManager-1.26.0-9.el8_3.x86_64 [core@coreos ~]$ cat /proc/cmdline | more BOOT_IMAGE=(hd0,gpt3)/ostree/rhcos-da2a55fc8655016771f867e78910e69d6ee3b93e3cbc5 aad74660e2b8d9c8e19/vmlinuz-4.18.0-240.7.1.el8_3.x86_64 random.trust_cpu=on cons ole=tty0 console=ttyS0,115200n8 ignition.platform.id=qemu ignition.firstboot ost ree=/ostree/boot.1/rhcos/da2a55fc8655016771f867e78910e69d6ee3b93e3cbc5aad74660e2 b8d9c8e19/0 ip=192.168.122.100::192.168.122.1:255.255.255.0:coreos:ens5:none nam eserver=192.158.122.1 [core@coreos ~]$ sudo ls /etc/NetworkManager/system-connections/ ens5.nmconnection [core@coreos ~]$ sudo cat /etc/NetworkManager/system-connections/ens5.nmconnectio [connection] id=ens5 uuid=85c88c7a-444d-472f-ac84-6e4eb6af17ce type=ethernet interface-name=ens5 multi-connect=1 permissions= [ethernet] mac-address-blacklist= [ipv4] address1=192.168.122.100/24,192.168.122.1 dhcp-hostname=coreos dns=192.158.122.1; dns-search= may-fail=false method=manual [ipv6] addr-gen-mode=eui64 dhcp-hostname=coreos dns-search= method=auto [proxy] ```
*** Bug 1918658 has been marked as a duplicate of this bug. ***
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: OpenShift Container Platform 4.7.0 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-2020:5633
*** Bug 1940871 has been marked as a duplicate of this bug. ***