Bug 1882781
| Summary: | nameserver= option to dracut creates extra NM connection profile | ||
|---|---|---|---|
| Product: | OpenShift Container Platform | Reporter: | Dusty Mabe <dustymabe> |
| Component: | RHCOS | Assignee: | Dusty Mabe <dustymabe> |
| Status: | CLOSED ERRATA | QA Contact: | Michael Nguyen <mnguyen> |
| Severity: | low | Docs Contact: | |
| Priority: | low | ||
| Version: | 4.6 | CC: | bbreard, imcleod, jligon, miabbott, nbhatt, nstielau, sbelmasg, walters |
| Target Milestone: | --- | ||
| Target Release: | 4.7.0 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: |
Cause: Providing multiple `nameserver=` entries on the kernel command line can create multiple NetworkManager connection profiles.
Consequence: Incorrect networking configuration is created.
Fix: Using a newer version of NetworkManager in RHCOS that correctly handles multiple `nameserver=` entries.
Result: Networking configuration is properly generated when multiple `nameserver=` entries are provided.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2021-02-24 15:21:16 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: | |||
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, 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. *** |
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/