So right now, I have to...

1) SSH into the host
2) Edit the /etc/sysconfig/network-scripts/ifcfg-<interface> file and add DNS1=, DNS2=, and DOMAIN=
3) Restart NM systemctl restart NetworkManager

The install then progresses as normal. For now, that's a workaround (albeit quite painful)

UPDATE:

So I did the following.


```
ip=<ipaddress>::<defaultgw>:<netmask>:<hostnamefqdn>:<iface>:none nameserver=<dns server 1> nameserver=<dns server 2>
```

And that worked!

```
[core@master0 ~]$ cat /etc/sysconfig/network-scripts/ifcfg-enp1s0 
# Generated by dracut initrd
NAME="enp1s0"
DEVICE="enp1s0"
ONBOOT=yes
NETBOOT=yes
UUID="31340e9a-e6f5-453d-8ab4-c0b28947d39b"
BOOTPROTO=none
IPADDR="192.168.7.21"
NETMASK="255.255.255.0"
GATEWAY="192.168.7.1"
TYPE=Ethernet
DNS1="192.168.7.77"
DNS1="192.168.7.78"
[core@master0 ~]$ cat /etc/resolv.conf 
# Generated by NetworkManager
search ocp4.example.com
nameserver 192.168.7.77
nameserver 192.168.7.78
```

Maybe this is a document issue....we should really get this documented because the dracut.cmdline man page lists both as valid configuration, but only this method works.

Just to pin this down, the changes were:

* didn't work: ip=<ipaddress>::<defaultgw>:<netmask>:<hostname>:<iface>:none:<dns server 1>:<dns server 2>
* did work: ip=<ipaddress>::<defaultgw>:<netmask>:<hostnamefqdn>:<iface>:none nameserver=<dns server 1> nameserver=<dns server 2>

So:

* hostname -> hostnamefqdn and
* ':<dns server *>' -> ' nameserver=<dns server *>'

Do you need both of those?  Or do you just need the nameserver= change?

(In reply to W. Trevor King from comment #3)
> Just to pin this down, the changes were:
> 
> * didn't work:
> ip=<ipaddress>::<defaultgw>:<netmask>:<hostname>:<iface>:none:<dns server
> 1>:<dns server 2>
> * did work:
> ip=<ipaddress>::<defaultgw>:<netmask>:<hostnamefqdn>:<iface>:none
> nameserver=<dns server 1> nameserver=<dns server 2>
> 
> So:
> 
> * hostname -> hostnamefqdn and
> * ':<dns server *>' -> ' nameserver=<dns server *>'
> 
> Do you need both of those?  Or do you just need the nameserver= change?

Yes, correct. I needed both. I needed `nameserver=` for the nameservers to appear in both `/etc/sysconfig/network-scripts/ifcfg-<interface>` and in `/etc/resolv.conf`. I needed to provide `hostnamefqdn` in order to get the `search` field to appear in the `/etc/resolv.conf` file.

So yes, both changes were necessary.

UPDATE:

So I just tried it a few more times...so I consistently only get the first DNS server when passing multiple "nameservers"

I passed...

```
ip=<ipaddress>::<defaultgw>:<netmask>:<hostnamefqdn>:<iface>:none nameserver=<dns server 1> nameserver=<dns server 2>
```

But only get the first nameserver

```
[core@bootstrap ~]$ cat /etc/resolv.conf 
# Generated by NetworkManager
search ocp4.example.com
nameserver 192.168.7.1
[core@bootstrap ~]$ cat /etc/sysconfig/network-scripts/ifcfg-enp1s0 
# Generated by dracut initrd
NAME="enp1s0"
DEVICE="enp1s0"
ONBOOT=yes
NETBOOT=yes
UUID="755578a1-bf10-4885-b434-8d035f0b7d94"
BOOTPROTO=none
IPADDR="192.168.7.20"
NETMASK="255.255.255.0"
GATEWAY="192.168.7.1"
TYPE=Ethernet
DNS1="192.168.7.1"
```

It seems to only take the last provided "nameserver="

We should still document this procedure...but still need to figure out how to get multiple DNS servers passed through.

I tried reproducing this with a new RHEL8 install in a VM and found that the multiple `nameserver` entries were persisted into the real root:

```
$ cat /proc/cmdline 
BOOT_IMAGE=(hd0,msdos1)/vmlinuz-4.18.0-80.el8.x86_64 root=/dev/mapper/rhel-root ro crashkernel=auto resume=/dev/mapper/rhel-swap rd.lvm.lv=rhel/root rd.lvm.lv=rhel/swap ip=192.168.124.30::192.168.124.1:255.255.255.0:rhel8.example.com:enp1s0:none nameserver=192.168.124.1 nameserver=1.1.1.1

$ cat /etc/resolv.conf 
# Generated by NetworkManager
nameserver 192.168.124.1
nameserver 1.1.1.1

$ cat /etc/sysconfig/network-scripts/ifcfg-enp1s0 
# Generated by dracut initrd
NAME="enp1s0"
DEVICE="enp1s0"
ONBOOT=yes
NETBOOT=yes
UUID="a7561c53-3b6c-4332-9b41-3e1a3160e5c2"
BOOTPROTO=none
IPADDR="192.168.124.30"
NETMASK="255.255.255.0"
GATEWAY="192.168.124.1"
TYPE=Ethernet
DNS1="192.168.124.1"
DNS2="1.1.1.1"
```

This was a RHEL8 install I did from an ISO and on the first boot I provided the `ip=...` line.

From a documentation perspective, setting a static IP from the kernel command line should be nearly the same as experience as setting the IP on a RHEL system.  The RHEL7 docs cover this here:

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/networking_guide/sec-configuring_ip_networking_from_the_kernel_command_line

In that section, it does correctly point out that the `nameserver=` configuration is separate from the `ip=` configuration


Additionally, I found this KBase article covering setting the static IP for RHCOS nodes:

https://access.redhat.com/solutions/4531011

I've updated it with information gleaned from this BZ.


I'm inclined to close this, as we have reasonable documentation in place.

@Christian, do you feel that's appropriate?

@Maicah

The only thing is that the doc[1] mentions that you can pass multiple `nameserver=` entries. Although this works on RHEL 8, it doesn't work on RHCOS 4.2. It only ever picks up the last provided `nameserver=`. Most enterprises have 2,3, even 4 nameservers in their environment.

The issue now, I think, is less of documentation (which I think is sufficient with that Kbase) and more of the fact that customers are going to want to put more than 1 DNS server in their production instances.

[1] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/networking_guide/sec-configuring_ip_networking_from_the_kernel_command_line

There is an updated version of the `coreos-installer` for the 4.3 release - `coreos-installer-0-11.rhaos4.3.gitce8e9a8.el8`

The same build is tagged into the 4.2 puddle, but it is unlikely we will ship an updated installer ISO for 4.2.

However, since the installer is the same across 4.2/4.3, it *may* be possible (but totally not officially supported) to use the 4.3 installer ISO to land RHCOS 4.2 with multiple nameservers specified on the kernel cmdline.

Verified with rhcos-43.81.201912041553.0-installer.x86_64.iso

- Passed `ip=192.168.124.199::192.168.124.1:255.255.255.0:rhcos:ens3:none nameserver=192.168.124.1 nameserver=1.1.1.1` as additional kargs to the installer ISO
- Booted into RHCOS successfully

```
$ cat /proc/cmdline 
BOOT_IMAGE=(hd0,gpt1)/ostree/rhcos-81113d19266ec11c650908011b140f0ba2e11a327e502b5c88f9a99fc0f61d67/vmlinuz-4.18.0-147.0.3.el8_1.x86_64 ignition.firstboot rd.neednet=1 ip=192.168.124.199::192.168.124.1:255.255.255.0:rhcos:ens3:none nameserver=192.168.124.1 nameserver=1.1.1.1 console=tty0 console=ttyS0,115200n8 ignition.platform.id=qemu rd.luks.options=discard ostree=/ostree/boot.1/rhcos/81113d19266ec11c650908011b140f0ba2e11a327e502b5c88f9a99fc0f61d67/0

$ cat /etc/sysconfig/network-scripts/ifcfg-ens3
# Generated by dracut initrd
NAME="ens3"
DEVICE="ens3"
ONBOOT=yes
NETBOOT=yes
UUID="29bcc111-6897-4afd-a5b0-f0df7350db3c"
BOOTPROTO=none
IPADDR="192.168.124.199"
NETMASK="255.255.255.0"
GATEWAY="192.168.124.1"
TYPE=Ethernet
DNS1="192.168.124.1"
DNS2="1.1.1.1"

$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 52:54:00:47:81:d3 brd ff:ff:ff:ff:ff:ff
    inet 192.168.124.199/24 brd 192.168.124.255 scope global noprefixroute ens3
       valid_lft forever preferred_lft forever
    inet6 fe80::5054:ff:fe47:81d3/64 scope link 
       valid_lft forever preferred_lft forever


$ cat /etc/resolv.conf 
# Generated by NetworkManager
nameserver 192.168.124.1
nameserver 1.1.1.1
```

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, 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:0062