20190209 Update -> No Ethernet

English Install/Boot/Login
1

I’ve been watching the forum for about 16 hours, and I’m surprised no one else has reported this issue.

Yesterday I updated my desktop PC and my laptop to the 20190209 snapshot. After reboot, the desktop PC had no ethernet, but the laptop - a Lenovo 330 w/Ryzen 5 - did (however the laptop has a nasty issue that I’ll discuss in another post). Expecting the worst, I updated my wife’s desktop PC also, and it, too, had no ethernet after update.

At that point, especially seeing no similar reports on the forum, I had neither the time or the inclination to let the issue wag my tail. Consequently I reverted both desktop PC root partitions to the last archived Clonezilla images I had for each.

Am I the only one to experience this - on two separate PCs ??

2

Thus far, I have only updated systems in a VM. No problem, but perhaps that’s because it is a VM and getting its network from the host machine. I’m not planning updating bare-metal systems until Saturday.

Do your systems use “wicked” or “NetworkManager” (or something else)?

3

On Wed 13 Feb 2019 06:06:03 PM CST, sblass wrote:

I’ve been watching the forum for about 16 hours, and I’m surprised no
one else has reported this issue.

Yesterday I updated my desktop PC and my laptop to the 20190209
snapshot. After reboot, the desktop PC had no ethernet, but the laptop -
a Lenovo 330 w/Ryzen 5 - did (-however the laptop has a nasty issue that
I’ll discuss in another post-). Expecting the worst, I updated my wife’s
desktop PC also, and it, too, had no ethernet after update.

At that point, especially seeing no similar reports on the forum, I had
neither the time or the inclination to let the issue wag my tail.
Consequently I reverted both desktop PC root partitions to the last
archived Clonezilla images I had for each.

Am I the only one to experience this - on two separate PCs ??

Hi
No issues seen here;


/sbin/lspci -nnk |grep -A3 Network

00:19.0 Ethernet controller [0200]: Intel Corporation 82579LM Gigabit Network Connection (Lewisville) [8086:1502] (rev 04)
DeviceName:  L1U1
Subsystem: Intel Corporation Device [8086:2035]
Kernel driver in use: e1000e
--
03:00.0 Ethernet controller [0200]: Intel Corporation 82574L Gigabit Network Connection [8086:10d3]
DeviceName:  L2U1
Subsystem: Intel Corporation Device [8086:2035]
Kernel driver in use: e1000e

Maybe firmware required, check the output from the above and journalctl
-b

–
Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
SLES 15 | GNOME Shell 3.26.2 | 4.12.14-25.28-default
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!

4

Thanks, Malcolm. Here’s similar output from the 20190201 snapshot that I’m now running…

/sbin/lspci -nnk |grep -A3 Network
06:00.0 Network controller [0280]: Realtek Semiconductor Co., Ltd. RTL8821AE 802.11ac PCIe Wireless Network Adapter [10ec:8821]
Subsystem: AzureWave Device [1a3b:2161]
Kernel driver in use: rtl8821ae
Kernel modules: rtl8821ae

/sbin/lspci -nnk |grep -A3 Ethernet
02:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (r
ev 11)
Subsystem: ASUSTeK Computer Inc. Device [1043:8554]
Kernel driver in use: r8169
Kernel modules: r8169

All kosher. Don’t have the desire to dup to 20190209 once again, so will check in again on the next snapshot.

5

Hi
I think some folks have had issues with the above in the past with the r8169 driver, your driver also needs firmware so it might be the issue as well…

6

He’s baaaaaaaack!

Well, I had restored my desktop PC to 20190201, after the lost ethernet capability with 20190209. When 20190214 became available today I dup’ed once again to see if the problem is still present. And the answer is yes.

I’m only marginally Linux savvy, and I came to Tumbleweed about 3 years ago after about 10 nasty years on Kubuntu. I’ve learned enough to use zypper to regularly update the various PC’s in our house, and that has been the beauty of Tumbleweed so far. Despite allusions to extreme difficulty for users on rolling distributions, Tumbleweed has been amazingly trouble-free for me - everything just works.

Until now. I have had zero issues with the ethernet controllers on both my desktop PC and my wife’s. They were working just fine through snapshot 20190205, but something changed, commencing with 20190209.

With a little guidance I’ll gladly help to troubleshoot the issue.

7

Are you using “wicked” or are you using “NetworkManager”?

Whichever you are using, try switching to the other.

8

Sorry for having missed this query from you much earlier. Went into YaST and it was set to wicked, so I changed to NetworkManager. The wired connection icon is back in the system tray, as I would expect, and editing the wired conection tells me I’m connected.

Just one thing: I’m STILL not connected to the internet. Even checked ethernet cable to confirm no problem there. If I disconnect the ethernet cable, I do not get the Wired connection 1 deactivated message. Despite NetworkManager indicating I’m connected, I’m not. Something is not getting enabled.

The following truncated systemctl status NetworkManager listing appears to be virtually the same (other than the Process line) as on my laptop, whose wired connection is working fine.

NetworkManager.service - Network Manager
Loaded: loaded (/usr/lib/systemd/system/NetworkManager.service; enabled; vendor preset: disabled)
Drop-In: /usr/lib/systemd/system/NetworkManager.service.d
└─NetworkManager-ovs.conf
Active: active (running) since Fri 2019-02-15 22:45:06 PST; 10h ago
Docs: man:NetworkManager(8)
Process: 12016 ExecReload=/usr/bin/dbus-send --print-reply --system --type=method_call --dest=org.fre
Main PID: 1341 (NetworkManager)
Tasks: 4 (limit: 4915)
Memory: 13.7M
CGroup: /system.slice/NetworkManager.service
├─1341 /usr/sbin/NetworkManager --no-daemon
└─9759 /sbin/dhclient -d -q -sf /usr/lib/nm-dhcp-helper -pf /var/run/dhclient-enp2s0.pid -lf

Something is fundamentally missing. Ideas anyone ??

9

Try:

netconfig update -f

Run that as root.

They made changes which broke “/etc/resolv.conf” for some people. And that should fix it (assuming that’s your problem).

10

No luck.Would have been a nice, quick fix, but there seems to be something more insidious going on.

11

My one desktop PC has a wireless card, whihch I’ve never used. Attempting to connect with it yields the same result: no internet connectivity whatsoever.

Whatever changes they made have broken the whole enchilada!

Apparently my choices are to revert to the 20190201 snapshot, or to do a fresh install and hope everything turns out okay.

12

I have now updated two systems to 20190214. One of them uses “wicked” and the other uses “NetworkManager”. And networking is fine on both. But, of course, my hardware is different from yours, so perhaps not a good indicator.

I would suggest that you download the latest Tumbleweed installer, see if it boots and then check whether the network is functional when running the installer (or perhaps the rescue system from the installer medium).

13

I have a similar/same problem. After every update later than 20190201 resolving host names seems to be broken. I can still ping IP addresses and get a response. Also directly accessing my router by entering the IP address in the browser works. I’m using wicked but also tried to switch to NetworkManager without success. So I had no other idea than to snapper rollback to 20190201 (just did that once again). If I should provide any additional information please let me know.

14

Have you tried

netconfig update -f

There were recent changes to how “/etc/resolv.conf” is handled, and those changes caused problems for some people. Using “netconfig” as suggested is supposed to fix that.

15

I tried

netconfig update -f

with previous updates (didn’t help there) but not with the last one to 20190215. I’ll update again and post the result.

16

I was going to open a new thread, but - noticing some recent activity - I’ll keep this here.

I started the thread initially because, for me, it was an issue of losing ethernet connectivity. But, in reality, it’s a network configuration SNAFU. For some reason, however, it is not an issue on two laptops that I’ve been updating regularly.

Today I reloaded the 20120201 snapshot (from a Clonezilla image) onto my desktop PC, which was using wicked. I went into YaST and changed to Network Manager, and I still had network connectivity following the change. I rebooted the system to ensure the change would still be in effect, and indeed it was. A very positive sign.

So, I updated to the 20190215 snapshot, thinking that perhaps moving away from wicked to Network Manager might be the solution to all my problems. No joy, however! Following a reboot after the update, once again I had no connectivity.

So… for me this commenced with 20190209 and has prevailed on every snapshot thereafter. The exercise that I went through today - successfully changing from wicked to Network Manager on the 20190201 snapshot, but then losing everything after updating to 20190215 - would seem to indicate that it’s a deep seated network configuration issue.

I don’t know why I’m able to update my two laptops successfully, unless it has something to do with the recentness of Tumbleweed being installed on both. The two desktops that display this network configuration issue had Tumbleweed installed perhaps as much as two years ago.

I’m finding myself reverting to my old Navy vocabulary!

17

Updated again to 20190215 and tried

netconfig update -f

but unfortunately it didn’t help. A call

host www.opensuse.org

works but a

ping www.opensuse.org

doesn’t. On the other hand a ping to the IP of www.opensuse.org

ping 130.57.66.6

works. At that point I previously rolled back to working snapshot. But of course I’m willing to try other ideas / suggestions or provide further information, so I’m not changing anything for now.

18

What is the content of /etc/nsswitch.conf?

19 

passwd: compat [NOTFOUND=return] files
group:  compat [NOTFOUND=return] files

hosts:          files mdns_minimal [NOTFOUND=return] dns
networks:       files dns

services:       files
protocols:      files
rpc:            files
ethers:         files
netmasks:       files
netgroup:       files nis
publickey:      files

bootparams:     files
automount:      files nis
aliases:        files
20

NOTFOUND=return makes it skip DNS lookup entirely if nothing was found by preceding methods which means if mdns_minimal is actually present on your system, no DNS lookup is ever attempted. If you do not use mDNS, just delete it, otherwise at least remove [NOTFOUND=return] to make it try next choice.