|
Bugzilla – Full Text Bug Listing |
| Summary: | nameserver line missing from /etc/resolv.conf; interface is controlled by networkmanager | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE Distribution | Reporter: | Lars Müller <lmuelle> |
| Component: | Network | Assignee: | openSUSE GNOME <os.gnome.maintainers> |
| Status: | RESOLVED WONTFIX | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Critical | ||
| Priority: | P5 - None | CC: | aplanas, erecio, forgotten_zxeoRDWLI0, msuchanek, mt |
| Version: | 13.2 | ||
| Target Milestone: | --- | ||
| Hardware: | x86-64 | ||
| OS: | openSUSE 13.2 | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: |
stdout of netconfig update -v
/var/log/NetworkManager as requested with comment #4 grep NETCONFIG /etc/sysconfig/network/config netconfig update -v |
||
|
Description
Lars Müller
2014-11-04 15:03:11 UTC
Passing to Marius as he's the dhcp-client package bug owner. This bug has nothing to do with the dhcp-client, which does not modify the resolv.conf directly but provides all data to the NetworkManager only. The NetworkManager is using own dhcp client scripts and is also the only service allowed to modify resolv.conf using netconfig (by default). As it starts working after cable reconnect, it is probably some missing resume hook triggering to confirm the leases in NetworkManager (reload or something like this). Whatever provides these resume hooks today.... I seem to have the same problem, but re-attaching the cable doesn't do the trick for me. After the DHCPACK, correct information is being shown in the <info> lines in /var/log/NetworkManager, including all nameservers; however these are not written in /etc/resolv.conf (and neither in resolv.conf.netconfig or whereever). I'm unclear about what component is failing, or what information to provide to help in the debugging. It would be probably helpful to attach the logs (/var/log/NetworkManager), probably with NETCONFIG_VERBOSE=yes in /etc/sysconfig/network/config. Please attach also the outputs of: grep ^NETCONFIG /etc/sysconfig/network/config netconfig update -v A call to: /sbin/netconfig modify -s NetworkManager <<EOF DNSSEARCH='example.net example.com' DNSDOMAIN='example.net' DNSSERVERS='192.168.0.10 192.168.0.20' EOF works fine for me, the settings are written properly as needed. Make sure that network.service points to NetworkManager (enabled via "systemctl enable NetworkManager.service", see also yast2 bug 895447). mug:~ # grep ^NETCONFIG /etc/sysconfig/network/config NETCONFIG_MODULES_ORDER="dns-resolver dns-bind dns-dnsmasq nis ntp-runtime" NETCONFIG_DNS_POLICY="auto" NETCONFIG_DNS_FORWARDER="resolver" NETCONFIG_DNS_FORWARDER_FALLBACK="yes" NETCONFIG_DNS_STATIC_SEARCHLIST="" NETCONFIG_DNS_STATIC_SERVERS="" NETCONFIG_DNS_RANKING="auto" NETCONFIG_DNS_RESOLVER_OPTIONS="" NETCONFIG_DNS_RESOLVER_SORTLIST="" NETCONFIG_NTP_POLICY="auto" NETCONFIG_NTP_STATIC_SERVERS="" NETCONFIG_NIS_POLICY="auto" NETCONFIG_NIS_SETDOMAINNAME="yes" NETCONFIG_NIS_STATIC_DOMAIN="" NETCONFIG_NIS_STATIC_SERVERS="" NETCONFIG_VERBOSE="yes" NETCONFIG_FORCE_REPLACE="no" Created attachment 614466 [details]
stdout of netconfig update -v
stderr:
netconfig: Executing 'update -v' for pid 3482
debug: lockfile created (/var/run/netconfig.pid) for PID 5711
debug: lockfile created
debug: Module order: dns-resolver dns-bind dns-dnsmasq nis ntp-runtime
Created attachment 614469 [details] /var/log/NetworkManager as requested with comment #4 Created attachment 614532 [details]
grep NETCONFIG /etc/sysconfig/network/config
Created attachment 614533 [details]
netconfig update -v
I can reproduce this same issue in a Lenovo x240. Fresh install from Factory 20141107 (NET image) to a minimalx. Attached same information required for c.#4 In this system, NETCONFIG_DNS_POLICY variable in /etc/sysconfig/network/config was "". I changed it to "auto" and revert from wicked to networkmanager again. Looks like worked. The question is why this variable was empty in the first instance. I can try to reproduce it in a spare laptop again, if this provide more information for this bug. (In reply to Alberto Planas Dominguez from comment #11) > In this system, NETCONFIG_DNS_POLICY variable in > /etc/sysconfig/network/config was "". > I changed it to "auto" and revert from > wicked to networkmanager again. Looks like worked. > > The question is why this variable was empty in the first instance. I've no idea who or why -- a yast2 issue? It is the only part which touches it -- anything else is just using the variable. With correct policy it obviously works, yes -- when NetworkManager provides something (see comment 6, it didn't). See also NM logs from comment 7, where a flip-flop of empty and non-empty setting is visible. So I guess there are now 4 other filed bugs of this type, the oldest being from 2010? I am asking because this is a serious issue, especially when I enable VPN connections, or move from one SSID to another, or from wireless to wired on a different network. Is there a solution? This version of openSUSE changed to end-of-life (EOL [1]) status. As such it is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of openSUSE, or consider the bug still valid, please feel free to reopen this bug against that version, or open a new ticket. Thank you for reporting this bug and we are sorry it could not be fixed during the lifetime of the release. [1] https://en.opensuse.org/Lifetime |