Recent timezone update killed my network?!

Hi folks. Got a really weird problem here. Last night I did a

zypper patch

on my OpenSuse 13.2 test server before I went to bed and it said there was just a timezone update to be done. So I applied the update and just restarted the machine. When the boot process finished I tried to log back in via ssh, but it kept telling me that there was no route to host. This morning, I managed to get the machine hooked up to a TV so that I could check that it is actually starting properly, and it is, but it seems that somehow the timezone update caused some weird kind of puging of the netweork card’s existence from the machine’s inventory. For example,

ls -l /dev/ | grep "eth"

returns absolutely nothing and if I look in the Network Devices > Network Settings module of YaST, it lists the only entry as “TI.8111/8168 PCI Express Gigabit Ethernet controller” in the “Name” collumn, the correct IP address in the coresponding collumn, but instead of having “eth0” in the “device” column, it has “enp5s0”. Has the update switched my internet connection to a serial port there or what? I don’t recognize the “enp5” bit. I am thoroughly baffled by this. Can anyone help me out? I haven’t tried to change anything since this happened in order to avoid making things worse, I just did enough to get a little bit of info about it.

openSUSE 13.2 uses predictable network interface names; for example, enp5s0.
Earlier and later openSUSE releases use persistent interface names; for example eth0.
[HR][/HR]With the user ‘root’ check the output of ‘ifconfig’ – it should list information related to enp5s0.
Then use ‘ethtool enp5s0’ to check the remaining information for enp5s0, such as:

  • Supported link modes
  • Supports auto-negotiation
  • Advertised link modes
  • Link partner advertised link modes
  • Link partner advertised auto-negotiation
  • Speed
  • Duplex
  • Auto-negotiation

[HR][/HR]My 13.2 system is not listing the network interface in /dev/ and I’m not expecting it to do so.
Take a look in /run/netconfig/ to find the network interfaces and the corresponding configuration information.
[HR][/HR]Check the content of the config files in /etc/ssh/.
Check that the systemd sshd.service is enabled and started.
Check the status of the systemd sshd.service.[HR][/HR]systemd is easy: check the usage of systemctl.

Are you sure it was that update, and not the previous “systemd” update that broke your system?

See this thread for my experience with the systemd update. Perhaps this was your first reboot since the systemd update.

Agree with nrickert’s suggested scenario.

More directly addressing your situation moving forward,

Determine whether the network interface name change also changed your IP address, on your openSUSE run the following command to determine current network configuration and status

ip addr

Depending on how your SSH authentication is configured, maybe all you need to do is specify a new, correct IP address when connecting.

TSU

Ok, it took me a while to get the output from ifconfig and ethtool-enp5s0 out of my server and into a text file so I can paste it here (lots of broken USB sticks >_<). So I’ll post their outputs and then act on your advice Nick, but to answer your aquestion about which update caused to problem; no, I’m not at all certain it was the timezone update that caused the problem. I did the update immediately before going to bed, so because I just wanted to get to bed, I just shut the thing down and switched it back on, rather than looking for any information about any processes that may need restarting. So it’s certainly possible that a previous update caused the problem, but it didn’t show up untill the restart. Anyway, here’s the output dcurtisfra asked for.

www:~ # ifconfig
lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:6 errors:0 dropped:0 overruns:0 frame:0
          TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:504 (504.0 b)  TX bytes:504 (504.0 b)


Yes, loopback really was the only thing listed.

www:~ # ethtool enp5s0
Settings for enp5s0:
    Supported ports:  TP MII ]
    Supported link modes:   10baseT/Half 10baseT/Full 
                            100baseT/Half 100baseT/Full 
                            1000baseT/Half 1000baseT/Full 
    Supported pause frame use: No
    Supports auto-negotiation: Yes
    Advertised link modes:  10baseT/Half 10baseT/Full 
                            100baseT/Half 100baseT/Full 
    Advertised pause frame use: No
    Advertised auto-negotiation: Yes
    Link partner advertised link modes:  10baseT/Half 10baseT/Full 
                                         100baseT/Half 100baseT/Full 
    Link partner advertised pause frame use: Symmetric Receive-only
    Link partner advertised auto-negotiation: Yes
    Speed: 100Mb/s
    Duplex: Full
    Port: MII
    PHYAD: 0
    Transceiver: internal
    Auto-negotiation: on
    Supports Wake-on: pumbg
    Wake-on: g
    Current message level: 0x00000033 (51)
                   drv probe ifdown ifup
    Link detected: no

Anyway, I’ll go grab the other output that’s been requested and have a look at the thread you pointed to, Nick.

That’s similar to what I saw. I think it very likely that this was the “systemd” update that caused the problem.

If your system behaves like mine, then you can get the network up. Use Yast, and edit the device settings. Change something (change on the general tab from start at boot up to start at cable connect, or vice versa). Then, when you finish, see if you have network. You will run into the same problem on the next reboot.

Then check my bug report (bug 976947). I listed the 8 packages that I reverted to an earlier version. That solved my problem.

If this turns out to be your problem, then maybe add a comment to the bug report.

Here’s the output from ip addr

www:~ # ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp5s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 20:cf:30:39:c8:41 brd ff:ff:ff:ff:ff:ff

This very likely was the first reboot since the systemd update. I had a look in the thread you linked to, Nick, and your situation seems to mirror mine. I also have a laptop with 13.2 installed which connects without a broblem at all after the update; it’s just the server box that’s affected. Is there a delta rpm to fix it, or should I try to do wahat you did in your thread?

Yup. That did it. Kust used YaST to change the network to come on when the cable is connected and eveything magically sorted its self out. I’ll add what I can to your bug report soon. Thanks for the help. :smiley:

I think you should do what I did – namely revert those recent systemd and udev package updates. And if that fixes it, indicate that on the bug report. Until somebody investigates the bug, there won’t be a fix.

I also marked those packages in yast as “do not change”, so that I don’t accidentally apply that patch in the future.

There’s no problem, however, on a different 13.2 system. So it’s a hardware dependent issue.

@Stephen_Philbin,
Combining the two above posts, it looks like it’s not really a problem?
Or, at least just recognizing that a new network interface(s)(At least the wired since it’s the only one displayed) has been created which needs to be configured, and simply making a physical connection to the network enabled the interface to self-configure, likely using DHCP.

So, at least to me it looks like I suspected that your network interface once physically connected to the network is working and has a new IP address which you may have to use depending how your SSH connection is configured.

You might notice this is a reason to use “ip addr” instead of “ifconfig”
With “ifconfig” all you saw was the loopback interface and nothing more
With “ip addr” you can also see that a wired ethernet interface with a new name exists, but its status is “down” and configured only with an IPv6 address which could lead you to know that it’s unconnected and unconfigured.

I don’t know if this description also applies to bug 976947,
It looks like maybe the so-called systemd update issue updated the network interface naming convention which needed resolving.

TSU

Tsu, am I understanding your message correctly there? You’re saying that the connection is fine, but that for some reason the host has decided it’s not going to use the IP address I’ve configured it to use any more?

Neil, I’m not sure how to roll back to a previous udev and is udev the only package I need to roll back? What about systemd that you’ve also mentioned? I looked in YaST to see if I could figure out how, but the closest I came was just a list of packages for various achitectures (by typung udev into the search box and changing the view to “Package Versions” [Alt + V x 2]). It showed the version you said you’d rolled back to, but for i586. I didn’t see a 64 bit version available.

I think Tsu was mistaken about the network.

Yes, you need to revert systemd and udev.

Here are the changes that I made:


libudev1                210.1456152170.f2b9ea6-25.34.1
libudev1-32bit          210.1456152170.f2b9ea6-25.34.1
libgudev-1_0-0          210.1456152170.f2b9ea6-25.34.1
udev                    210.1456152170.f2b9ea6-25.34.1
systemd                 210.1456152170.f2b9ea6-25.34.1
systemd-32bit           210.1456152170.f2b9ea6-25.34.1
systemd-sysvinit        210.1456152170.f2b9ea6-25.34.1
systemd-bash-completion 210.1456152170.f2b9ea6-25.34.1

These all had the same version, all were x86_64. I assume that they belong together, so I changed them all.

I’m not sure how you are trying to revert. I used the GUI Yast Software Manager, and clicked on the Versions tab. I used a search for “systemd” and a search for “udev”, found the components, and selected them.

It sounds as if you are doing it all with the command line interface (yast --ncurses), and that’s a bit trickier to find your way around.

was just me being a bit of an idiot. I didn’t notice that there were more files that I could scroll down to in the files window because the text-based UI made it difficult to see that a scroll bar was there (I have very poor eyesight). Once I double-checked the files and found the ones to roll back to, it all went fine. The working packages are installed and locked in place now, so I’ve added to your bug report. I assumed that hwinfo --network was probably the most relevant information I could provide, so I added that to the report. Thanks for the help, I didn’t even know you could roll back software packages until now. I just assumed old ones would be deleted automatically to save storage space.

:smiley:

Thanks for that update.