Network mesh after upgrade

Hello,
I have a huge problem with the network of my desktop after the upgrade from 13.1 to 13.2
My box uses a static IP (192.168.0.3) and the relevant file seems OK:

cat /etc/sysconfig/network/ifcfg-enp2s0 
BOOTPROTO='static'
IPADDR='192.168.0.3/24'
BROADCAST=''
STARTMODE='auto'
NAME='RTL8111/8168B PCI Express Gigabit Ethernet controller'
ETHTOOL_OPTIONS=''
MTU=''
NETWORK=''
REMOTE_IPADDR=''

However, after reboot I have no network. I do not use NetworkManager (it’s not even installed), so the only network service installed is the wickedd:

systemctl list-units -t service | grep -i net
wicked.service                                                                         loaded failed failed  wicked managed network interfaces
wickedd-nanny.service                                                                  loaded active running wicked network nanny service
wickedd.service                                                                        loaded active running wicked network management service daemon

I tried to restart wicked service with no difference and then I tried to manually start the interface and and I saw the following errors:


ifup enp2s0
wicked: /org/opensuse/Network/Interface.getManagedObjects failed. Server responds:
wicked: org.freedesktop.DBus.Error.ServiceUnknown: The name org.opensuse.Network was not provided by any .service files
wicked: Couldn't refresh list of active network interfaces

Restaring again made no difference, but then I could use ifup to start the interface:


ifup enp2s0
enp2s0          up

Trying to find out what the problem is:

#journalctl -p err
Dec 20 18:12:31 peter systemd[1]: Job wickedd-dhcp4.service/start deleted to break ordering cycle starting with wicked.service/start
Dec 20 18:12:31 peter systemd[1]: Job wickedd-auto4.service/start deleted to break ordering cycle starting with wicked.service/start
Dec 20 18:12:31 peter systemd[1]: Job wickedd-dhcp6.service/start deleted to break ordering cycle starting with wicked.service/start
Dec 20 18:12:31 peter systemd[1]: Job auditd.service/start deleted to break ordering cycle starting with basic.target/start
Dec 20 18:12:31 peter systemd[1]: Job systemd-tmpfiles-setup.service/start deleted to break ordering cycle starting with basic.target/star
Dec 20 18:12:31 peter systemd[1]: Job YaST2-Second-Stage.service/start deleted to break ordering cycle starting with wicked.service/start
Dec 20 18:12:31 peter systemd[1]: Job YaST2-Firstboot.service/start deleted to break ordering cycle starting with wicked.service/start
Dec 20 18:12:31 peter systemd[1]: Job local-fs.target/start deleted to break ordering cycle starting with basic.target/start
Dec 20 18:12:31 peter systemd[1]: Job wickedd-nanny.service/start deleted to break ordering cycle starting with wicked.service/start
Dec 20 18:12:31 peter systemd[1]: Job wickedd.service/start deleted to break ordering cycle starting with wicked.service/start
Dec 20 18:12:32 peter systemd[1]: Job wickedd-nanny.service/start deleted to break ordering cycle starting with wicked.service/start
Dec 20 18:12:32 peter systemd[1]: Job wickedd.service/start deleted to break ordering cycle starting with wicked.service/start
Dec 20 18:12:32 peter systemd[1]: Job systemd-tmpfiles-setup.service/start deleted to break ordering cycle starting with basic.target/star
Dec 20 18:12:32 peter systemd[1]: Job local-fs.target/start deleted to break ordering cycle starting with basic.target/start

Any ideas?

  1. My preference for re-initialize networking is to simply restart the network service (still works in 13.2)
systemctl restart network.service
  1. The starting point for investigating anything that is amiss on a systemd system is to invoke the “status” of the service which if having failed will include a relevant snippet of the problem from your system journal. So, for example for one of the failed services you identified
systemctl status wicked.service

If you can’t decypher the errors, post those results here (in CODE blocks) for all to see.

Also, there <may> be an issue with the default kernel in openSUSE for your NIC (as described in another thread)
Here are some additional results for “linux kernel error RTL8111”
https://bbs.archlinux.org/viewtopic.php?id=184033
https://bbs.archlinux.org/viewtopic.php?id=186370

So, you can also try the Factory kernel
https://en.opensuse.org/Kernel

TSU

The errors are already posted.

I don’t believe that this is a driver issue, since I have no problem with NetworkManager, but I don’t want to use NM for a static IP.

Are you saying that if you run the “status” I suggested that you return exactly the same entries from the journal?
The reason why I’m asking is that I’m not able to decipher your errors and wonder if the system determined that the errors you posted are most relevant to your problem.

TSU

I nave the same problem (https://forums.opensuse.org/showthread.php/503660-Upgrade-from-13-1-to-13-2-wicked-problem). Tried with driver r8168, but nothing help.>:(

Maybe, maybe not.
The problem comparing your two threads is that between the two of you, no errors or logs posted are the same.

So, although the symptoms appear similar it’s anyone’s guess whether they’re caused by the same thing or not.

Your thread contains more typical investigative evidence. This thread does not although the information can still be useful. In this thread the OP seems to possibly have located some hints (certain services stopped when they shouldn’t), but does not seem able to take the next step. In yours, some people seem to have suggested some solutions but since backtracked so they need further analysis.

TSU

Pls post the result of

journatlctl | grep -i wicked.service

I find it interesting that although you returned a “failed” in your journal as follows, the status of the service reports normal…

wicked.service                                                                         loaded failed failed  wicked managed

The following you reported does look suspicious and suggests a wicked coding error, maybe grepping for the missing service might help as well

ifup enp2s0

wicked: /org/opensuse/Network/Interface.getManagedObjects failed. Server responds:
wicked: org.freedesktop.DBus.Error.ServiceUnknown: The name org.opensuse.Network was not provided by any .service files 

TSU

I don’t think so. The problem with Realtek exists since 2008. I’ve found following (http://wiki.hetzner.de/index.php/Installation_des_r8168-Treibers/en). The problem is the kernel with RTL driver. It seams to be, that 3.11 kernel had r8168, but up 3.13 the new driver r6189.
“The Linux r8169 driver for the Realtek network chips does not always work correctly, even in the newest kernel versions. There can be timeouts and/or frequent link up/link down state changes. Even system crashes may occur.
One solution is to use the official Realtek r8168 driver. Unfortunately this driver is not included in any distribution.”
For Suse with kernel default is proposed:
"Installing r8168-kmp from the OpenSUSE NIC drivers repo
OpenSUSE offers pre-built kernel module packages (kmp). You just have to add the repository to zypper and install the matching package. In the following example OpenSUSE with the default kernel is used.
cd /etc/zypp/repos.d
wget http://download.opensuse.org/repositories/drivers:/nic/openSUSE_Tumbleweed/drivers:nic.repo
zypper refresh
zypper install r8168-kmp-default

Before rebooting, the r8169 driver must be blocked from loading.
echo “blacklist r8169” >> /etc/modprobe.d/99-local.conf
After the reboot only the r8168 module should be active and show up in ‘lsmod’. "
I will try.

Nothing new. Only eth0 is now epn4s0…

The problem with postings like what you referenced is that they are not dated.
But, a clue can be what the author considered “latest” which is Ubuntu 6. Considering that today’s current Ubuntu is 14.x, that probably dates the article to “pre 2.6.25” kernel which would mean a completely different architecture so is totally irrelevant to anything today. You would probably want to do something to doublecheck the existence of a problem, for instance Googling your NIC firmware with current versions of kernel firmware and/or current distro versions.

TSU

You are right. So I have r8168 driver from Realtek site installed. With the same result.

Can I ask you why you are investigating the problem at the driver level? Since I have a fine network using NetworkManager I don’t see why this is a driver related issue.

Personally, I believe that this is a problem of the service script. Because when you start the service manually, it’s OK. I will try the the upgraded wicked package and I will report back.

I have not a fine network using NetworkManager. With NM i have connection only by eth0, but eth1 not work at all. I’ve allways used ifup, so I feel wicked much comfortale. I have the latest for suse wicked version. I think I should wait on the next version and the try it again (I mean suse 13.2). Thank you for answers.