Here attached the trace I did with WITHOUT my 'dns=node' statement (thus without any 'dns=' directive)
To sump up : 1. node pxe boots : gets the System enp33s0f0 03a3d6a6-33d2-bba1-f78c-e1d7861520ba ethernet -- profile 2. an xCAT postbootscript adds the followin profile xcat-enp33s0f0 af4416ad-a9c2-4e7c-95e9-ad62b759d549 ethernet enp33s0f0 So once booted : [root@maestro-1001 ~]# nmcli con show NAME UUID TYPE DEVICE xcat-enp33s0f0 af4416ad-a9c2-4e7c-95e9-ad62b759d549 ethernet enp33s0f0 System enp33s0f0 03a3d6a6-33d2-bba1-f78c-e1d7861520ba ethernet -- None of those profile has any dns properties set :# nmcli -f connection.autoconnect,connection.autoconnect-priority,ipv4.dns,ipv4.dns-search con show 'System enp33s0f0'
connection.autoconnect: yes connection.autoconnect-priority: 0 ipv4.dns: -- ipv4.dns-search: --# nmcli -f connection.autoconnect,connection.autoconnect-priority,ipv4.dns,ipv4.dns-search con show xcat-enp33s0f0
connection.autoconnect: yes connection.autoconnect-priority: 9 ipv4.dns: -- ipv4.dns-search: --I'm not really sure what the trace shows but it seems to me that /etc/resolv.conf gets updated:
- a first time following dhclient- a second time, I guess as a result of the second profile autoconnection, where it is actually emptied, resulting in:
# cat /etc/resolv.conf # Generated by NetworkManager This could seem logical although- it goes against your first answer (NM wouldn't empty a working /etc/resolv.conf)
- it is not consistent with the same test where 'dns=none' is stated, resulting in the node booted with the dhcp provided /etc/resolv.conf left untouched and then the second profile reactivated (con up) without 'dns=none' : /etc/resolv.conf still not emptied as we could expect
Or maybe the difference in the latter test is that dhcp is out of the picture ?
I'm sure I'm missing something obious, sorry... Thanks for your help -- TH
Attachment:
trace.log.bz2
Description: application/bzip