DNS trouble after zypper dup

Ran zypper dup today to install about a month worth of updates (about 3000 packages to 20190226, previously 201901xx) on a machine that has been working fine for more than a year. Since then the NetworkManager applet shows a yellow exclamation mark next to the connection and anything requiring domain names fails (including zypper).

IP connectivity is still there and

heptapus:/home/valentin # host google.com
google.com has address
google.com has IPv6 address 2a00:1450:4001:819::200e
google.com mail is handled by 40 alt3.aspmx.l.google.com.
google.com mail is handled by 10 aspmx.l.google.com.
google.com mail is handled by 20 alt1.aspmx.l.google.com.
google.com mail is handled by 50 alt4.aspmx.l.google.com.
google.com mail is handled by 30 alt2.aspmx.l.google.com.

looks okay to me as well.

Can’t see anything unusual here either, but networking is not really my expertise:

heptapus:/home/valentin # ip addr show wlp3s03: 
wlp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 08:11:96:a7:04:d8 brd ff:ff:ff:ff:ff:ff
    inet brd scope global dynamic noprefixroute wlp3s0
       valid_lft 862694sec preferred_lft 862694sec
    inet6 2001:4dd2:9d45:0:903:7fbe:4f96:5e1/64 scope global temporary dynamic 
       valid_lft 6931sec preferred_lft 3331sec
    inet6 2001:4dd2:9d45:0:204:835e:576b:6b04/64 scope global dynamic mngtmpaddr noprefixroute 
       valid_lft 6931sec preferred_lft 3331sec
    inet6 fe80::c93f:6be7:a6a1:d65f/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

Already tried the Troubleshooting guide, looked at /etc/resolv.conf and tried using wicked instead of NetworkManager. The problem has persisted across several reboots. Previous system snapshots fail to boot because of Name Service Cache Daemon not starting, so a rollback seem not to be an option, while the current configuration work except for that DNS problem.

I’m running out of ideas where to look for possible causes or how to fix this short of attempting a complete reinstall.

Seems it’s a know issue, try;

netconfig update -f

If that doesn’t work you may need to manually create the softlink to it’s new location…

ln -s /var/run/netconfig/resolv.conf /etc/resolv.conf

Bug: https://bugzilla.opensuse.org/show_bug.cgi?id=1124152
Also: https://lists.opensuse.org/opensuse-factory/2019-02/msg00088.html


I ended up with the same problem after zypper dup. Machine been running tumbleweed since 2015 without problem. Been using linux since 2001. However, after several hours of searching for solution still came out a bust. DNS worked, according to nslookup etc, but still failed to resolve. Ended up reinstalling, which annoyed me a lot. One of the few problems I haven’t been able to solve.

Checked resolv.conf:

erlangen:~ # readlink -f /etc/resolv.conf 
erlangen:~ # 

Any idea why /var got dropped from pathname? Tumbleweed 20190108 definitely had a file /etc/resolv.conf instead of a link. Name resolution failed randomly and required restarting the network e.g. after resume from suspend. The linked version never failed so far.

If you cat the contents;

### /etc/resolv.conf is a symlink to /var/run/netconfig/resolv.conf
### autogenerated by netconfig!

The /run not sure why that’s created, maybe systemd related…

Re-read Malcom’s post,
And run the netconfig command exactly how he posted.

You appear to have mixed up the netconfig update command with the command to create a symlink.


It’s a compatibility issue: “It is valid to implement /var/run as a symlink to /run.” http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch05s13.html

erlangen:~ # ll /var/run
lrwxrwxrwx 1 root root 4 Nov  9  2016 /var/run -> /run
erlangen:~ # 

#Both pathnames are valid:

erlangen:~ # ll /var/run/netconfig/resolv.conf
-rw-r--r-- 1 root root 683 Mar  4 07:08 /var/run/netconfig/resolv.conf
erlangen:~ # ll /run/netconfig/resolv.conf
-rw-r--r-- 1 root root 683 Mar  4 07:08 /run/netconfig/resolv.conf
erlangen:~ #