Description of problem:
This seems to be consistent among several SUTs updated to RHEL82 snapshot2 at HPE: the DNS domain_search list is being striped of dots. Before the snapshot2 update:
messages-20191216:Dec 11 04:52:58 dl360g91 NetworkManager: <info> [1576065178.9771] dhcp4 (eno1): option domain_search => 'ftc.rdlabs.hpecorp.net americas.hpqcorp.net'
messages-20191216:Dec 13 11:43:17 dl360g91 NetworkManager: <info> [1576262597.9228] dhcp4 (eno1): option domain_search => 'ftcrdlabshpecorpnet americashpqcorpnet'
This winds up in /etc/resolv.conf thusly:
search ftcrdlabshpecorpnet americashpqcorpnet
And of course doesn't achieve the desired result.
Version-Release number of selected component (if applicable):
RHEL8.2 internal snapshot2
Apparently all our systems installed or updated to RHEL82 snapshot 2.
Steps to Reproduce:
1. Install RHEL82 snapshot2
2. Notice default domainname searches no longer work
For one obviouse example, nslookup of an expected host on the same subnet fails
nslookup of another host on same subnet works
I had submitted an sosreport from an affected system in bug 1783425. I hadn't reconized this problem at the time, but the /var/log/messages in that sosreport shows results before and after the update to snapshot 2.
Dec 13 04:52:58 dl360g91 NetworkManager: <info> [1576237978.5615] dhcp4 (eno1): option domain_search => 'ftc.rdlabs.hpecorp.net americas.hpqcorp.net'
Dec 13 10:46:24 dl360g91 NetworkManager: <info> [1576259184.1605] dhcp4 (eno1): option domain_search => 'ftcrdlabshpecorpnet americashpqcorpnet'
fixed upstream by https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/ea22135384edaf57a41293bd517ff1445b8c88a8
As workaround with beta snapshot, you could use
actually, it's a duplicate of bug 1783981.
If you dup this bug to 1783981, please grant HPE access to 1783981 so we can monitor status of the fix.
(In reply to Randy Wright from comment #3)
> If you dup this bug to 1783981, please grant HPE access to 1783981 so we can
> monitor status of the fix.
I didn't close this bug as duplicate exactly because you cannot access the other bug.
This bug will go it's normal way. The status MODIFIED is correct. No need to reset the state to NEW.
Monte, can you grant HPE access to duplicate bug 1783981?
fix is in NetworkManager-1.22.0-2.el8
can you tell me if NetworkManager-1.22.0-2.el8 is included in the latest RHEL8.2 Beta build?
With RHEL-8.2.0_Beta_1.0Server-x86_64 installed, I find I have the desired version of Network Manager:
[root@fingal01 ~]# rpm -qa > qa.txt
[root@fingal01 ~]# grep NetworkManager-1.22 qa.txt
So I remove the 99-temporary-workaround.conf file I had created per the comment 1 suggestion and rebooted.
Upon rebooting, I was able to verify that the symptoms I reported originally are no longer occurring, for example:
[root@fingal01 ~]# grep domain_search /var/log/messages|tail -2
Feb 13 15:13:20 fingal01 NetworkManager: <info> [1581632000.6451] dhcp4 (ens1f0): option domain_search => 'ftc.rdlabs.hpecorp.net americas.hpqcorp.net'
Feb 13 15:13:20 fingal01 NetworkManager: <info> [1581632000.6452] dhcp4 (ens1f0): option requested_domain_search => '1'
I can clearly see the dots that were missing from the domain_search string due to the reported bug are indeed present.
And /etc/resolv.conf is constructed as expected:
[root@fingal01 ~]# cat /etc/resolv.conf
# Generated by NetworkManager
search ftc.rdlabs.hpecorp.net americas.hpqcorp.net
I am marking this HPE verified.
(In reply to Trinh Dao from comment #7)
> can you tell me if NetworkManager-1.22.0-2.el8 is included in the latest
> RHEL8.2 Beta build?
Yes, it is.
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.