Recent Tumbleweed update broke my internet connection

Like the title says, I’ve tried running

zypper dup

as usual to update the system, on two different days this week. Both times I’ve had to rollback to the previous snapshot because something that’s getting updated breaks my WiFi connection - it says it’s connected, but there is no connection to the internet. Any help would be amazing, since I don’t have the experience with this kind of thing to track down what’s going wrong.

I can ping numerical IPs like, but not things like

The WiFi device is an Intel WiFi 6 AX200, driver in use is iwlwifi.

Not sure if it makes much difference, but I’m on Tumbleweed running Cinnamon.

So it is NOT the connection to the Internet, it is a failure of DNS resolution.

Check /etc/resolv.conf

Just looked, but there’s nothing there. As in, that file has one commented line that says Generated by NetworkManager.

I should probably mention that I had network issues when I first installed fresh back in May. The current issue may or may not be related, but I figured it provides a little more context at least:

The above is well known behavior. You may consider switching to systemd-resolved: Disable Changes To DNS Through Netconfig, Enable Network Name Resolution

Then DNS resolution obviously does not work. What are you using - wicked or NetworkManager? Show

ls -l /etc/resolv.conf
cat /etc/resolv.conf
grep hosts /etc/nsswitch.conf

What I meant by “nothing there” is that the file doesn’t contain anything besides a single comment, “Generated by NetworkManager.” The file itself is there, in /etc/resolv.conf, it just doesn’t have anything besides that comment. I’m using NetworkManager.

ls -l /etc/resolv.conf
-rw-r–r-- 1 root root 276 Aug 16 2022 /etc/resolv.conf

cat /etc/resolv.conf

Generated by NetworkManager


NOTE: the libc resolver may not support more than 3 nameservers.

The nameservers listed below may not be recognized.

nameserver 2606:4700:4700::1111
nameserver 2606:4700:4700::1001

grep hosts /etc/nsswitch.conf

Valid databases are: aliases, ethers, group, gshadow, hosts,

hosts: files mdns_minimal [NOTFOUND=return] dns

It is not standard configuration for openSUSE but it should work.


NOTE: the libc resolver may not support more than 3 nameservers.

The nameservers listed below may not be recognized.

nameserver 2606:4700:4700::1111
nameserver 2606:4700:4700::1001

This file is not empty. This file defines three nameservers (IPv6 addresses won’t be used as glibc only uses the first three addesses). Both Cloudflare addresses and seem to work from here. I do not know whether is correct for you, it may come from your router via DHCP.

Can you reach all these three addresses?

ping -c 3
ping -c3
ping -c3

can you resolve using these addresses explicitly?

dig @
dig @
dig @

And please use tags [noparse]


[/noparse] around computer text. You demonstrated in the first post that you are aware of them.

True, it isn’t now. When I looked at that file it was - granted I opened it from my Ubuntu install on the same PC since I’m not having any issues there. Trying to troubleshoot and responding online with network issues is pretty cumbersome as you might imagine.

I’ve since rolled back to the snapshot before running the update which caused my issues. In order to answer your questions I’ll need to re-run the update, assuming the issue will return, to see if I’m able to. Is there anything you’d recommend trying before running the update?

Well, we have no way to guess what problem was. If you have persistent journal, providing journalctl output for the time you observed this issue may give some hints. Otherwise running this as root when you have the issue

LANG=C date
LANG=C NetworkManager --print-config
LANG=C nmcli device show
LANG=C ls -l /etc/resolv.conf
cat /etc/resolv.conf

provides some starting points. First run the same commands now, before you update, to establish baseline. Upload both results to

Before update:

After update:


After update:

SUSE Paste

# rc-manager=auto

Well, the update on July 28 moved default configuration file from /etc to /usr/lib. Show

ls -l /etc/NetworkManager
ls -l /etc/NetworkManager/conf.d
stephen@opensuse:~> ls -l /etc/NetworkManager/
total 4
drwxr-xr-x 1 root root   0 Aug 14 09:07 conf.d
drwxr-xr-x 1 root root   0 Aug 14 09:07 dispatcher.d
-rw-r--r-- 1 root root 103 May 30 22:37 NetworkManager.conf.rpmsave
drwxr-xr-x 1 root root 258 Aug 14 09:07 system-connections
drwxr-xr-x 1 root root   0 Aug 14 09:07 VPN
stephen@opensuse:~> ls -l /etc/NetworkManager/conf.d
total 0

Well, rename NetworkManager.conf,rpmsave back to NetworkManager.conf and restart NetworkManager (or reboot).

That seems to have fixed the issue. It’s almost annoying that such a simple thing was the solution, but I guess that’s how it goes sometimes. Thanks so much for your patience and help!

Was there some kind of announcement I could’ve checked that would have advised of this change? I know some distros have release notes that warn about potential issues like this, but don’t remember seeing that for openSUSE.

From fedora - Why do I have .rpmnew file after an update? - Server Fault

After a system upgrade it is a good idea to scan your filesystem for these files and make sure that correct config files are active and maybe merge the new contents from the .rpmnew files into the production files. You can remove the .rpmsave and .rpmnew files when you’re done.

After a system upgrade it is a good idea to scan your filesystem for these files …

Indeed, as a matter of course it is a good idea to run “rpmconfigcheck” after each dup.

Interesting - I hadn’t heard of that command before, but I’ll definitely start using it. Thanks for the tip!

Well … yes, for each Tumbleweed snapshot there is announcement on factory mailing list with changed packages and chagelog since the previous snapshot. On 20220805 this announcement included:

==== NetworkManager ====
Subpackages: NetworkManager-bluetooth NetworkManager-lang NetworkManager-pppoe NetworkManager-tui NetworkManager-wwan libnm0 typelib-1_0-NM-1_0

- Create /etc/NetworkManager/conf.d by default, allowing easy
  override for NetworkManager.conf file with drop-in.
- **Move default config file to**
**  /usr/lib/NetworkManager/NetworkManager.conf, as part of main**
**  package.**

Now to interpret this you need to know where NM configuration was located before, you need to remember that your configuration file was modified and no more default and know how to check and merge back these changes. My tentative guess is that if this announcement provided enough information to you, you would not need to ask this question in the first place.

(And no, I do not read/memorize every announcement myself. Otherwise it would not take so much time to troubleshoot).

Your main problem was that you had modified default configuration. This automatically implies that you know what you are doing and know how to fix fallout. If configuration remained default (as is the case for most users) you would not notice anything - it does not matter where default is located. I still wonder what was the reason for changing default recolv.conf management method.

Otherwise nothing extraordinary happened that warranted special announcement. Configuration files get updated/changed/relocated on regular basis. It is up to you as local administrator to check for any outstanding issues, e.g. using command already mentioned.

I linked to this earlier in the thread but maybe you missed it: Reddit - Dive into anything

When I first installed a few months back I had a very similar connection issue. I fixed the issue using the official wiki and didn’t think much more about it - to my knowledge I didn’t change any other network settings. Not saying it’s anyone else’s fault that I had an issue, just wanting to understand how to avoid things like this in the future, hence asking about release notes.