ifup bridge network configuration does not survive zypper dup 12.3 -> 13.1 possibly init -> systemd

English Install/Boot/Login
1

I’ve spent about a week working through the pain of getting my network back into some kind of order following a zypper dup upgrade from 12.3 to 13.1.

The problem is this. Since I run several kvm instances I bridge my local NIC (eth0). So eth0 configured with a 0.0.0.0/32 address, and br0 bridging eth0 and configured through DHCP.

But after the upgrade, (and i suspect that the real culprit here is systemd as I was still deliberately on sysVinit in 12.2), it looked from the boot logs as if systemd was trying to start eth0 on it’s own.

So I bring up my system, and all I have is a down’ed eth0 and a loopback.

I go into yast, where I see the bridge seemingly properly configured. Going through the menus triggers yast’s network reconfig, which seems to do the trick … until the next reboot, when all my settings yet again go away.

In the way this is what I ended up doing:

Boot the system into the multi-user.target (this is really annoying btw in how to do it now btw - it’s not described anywhere that I could find and I ended up having to second-guess and find through directory trees to find a likely candidate)


systemctl set-default --force multi-user.target
reboot

Now once the system is back up, I only see lo0 and eth0 in ip addr.

Go into yast → Network Devices and delete everything. Absolutely everything.

When you come out of yast, you’ll see nothing has actually changed. yast doesn’t seem to understand systemd networking (who actually does?)

So, I finally figured out there was a command that looked like


systemctl stop network@eth0

That actually got rid of my network for eth0.

Now, do yet another reboot.

So you’ve rebooted back. Now go back into yast, and set up the bridged configuration.

Reboot again (does this feel like Windows yet?)

This finally seems to work. At least so far. I shudder to think what will happen if I try to enable the wireless NIC on this box.

2

Seems like you have solved it.

I get a feeling that this is an effect of the old/new network card naming scheme. Maybe another approach could have solved it in a little more Linux like manner (not booting that much).

I have upgraded 12.3 -> 13.1 myself using zypper dup.

I do not have bridged networking, however, so my experience may not (entirely) apply. I have three cards, each to its own firewall zone. And that’s about it.

When I zypper dup-ed , I lost all network communication, but the old cards (old names) were present, but disabled. There were three new cards too (new names), but not configured. I knew from my betatesting experience that these new cards were the old cards with new names, and that they are meant to replace the old cards.

Instead of trying to continue using the old card-names, I configured the cards having new card-names and discarded the old card-names. That was pretty straight forward from inside Yast. I could even lift the old configuration from the old card-names (they were still available for reading, even though they were disabled). When I had copied over the config-data, I deleted the old card-names.

I had to enter the Network Device setup in Yast twice, though, one time to configure the cards themselves, and one time to configure routing after activating the new card-names, and thus making them available for the routing part.

The last thing I had to do, was to enter the firewall and make adjustments there. Then all communications worked, and I made no reboots for my networking to be activated.

My impression is that is the method planned for by the designers, and if you prefer the old card names, you are expected to reuse them after moving configuration data from the old card names to the new ones, and then deleting the old card names. There is a “card name field” that you can use for that purpose.

There’s another side too. This is a one-time only problem that you solve once and for all. It only happens when upgrading. Fresh installs will not have such problems.

I for one like the idea behind predictable network card naming, which is what you experienced the effect of upgrading to. I admit that they are harder to remember than the old eth<n>-scheme, but issuing “ifconfig” as root in a terminal window takes care of that.

dayfinger

3

dayfinger wrote:
>
> Seems like you have solved it.
>
> I get a feeling that this is an effect of the old/new network card
> naming scheme. Maybe another approach could have solved it in a little
> more Linux like manner (not booting that much).
>

This change caught me completely offguard. Even though mine is a fresh
install i saw two network card in YaST instead of one with names eth0
and enp2S0 .My network worked only when i switched to network manager.
But my internet connection is always flaky with NM. I had a hunch that
if i delete one of the cards in YaST and reconfigure i would be able to
connect using ifup. My hunch proved right. of-course i saw the change
being mentioned in release notes later.

–
GNOME 3.10.1
openSUSE 13.1 (Bottle) (x86_64) 64-bit
Kernel Linux 3.11.6-4-desktop

4

Are you saying that you ended up with two network card names [on a single network-card computer] after a fresh install? That isn’t my experience, nor is it according to what I remember reading from others during the beta-testing period.

So I hope you don’t mind my asking: How fresh was your fresh install?

  1. It was installed over an existing openSUSE installation, reusing all partitions. All partitions were formatted by the installation procedure after configuring the installation.
  2. It was installed over an existing openSUSE installation, reusing all partitions. All partitions except /home were formatted by the installation procedure after configuring the installation. The /home partition was carried over from the previous installation.
  3. It was installed into a fresh harddisk that had no other previous data whatsoever, and there were no other Linux elsewhere on that computer.
  4. It was installed into a fresh harddisk that had no other previous data whatsoever, but there is another Linux installed elsewhere on that computer.
  5. It was a two-step installation over an existing openSUSE installation. First step was to remove and/or format all old openSUSE partitions using a tool different from the installation medium (DVD or USB). The second step was to boot from the installation medium and execute the installation. There were no other Linux installed elsewhere on that computer.
  6. As item 5 above, but there were another Linux installation elsewhere on that computer.
  7. As item 5 above, but the /home partition was carried over and not formatted.
  8. None of the above accurately describe the installation. (Please explain).

Also, did you or did you not enable automatic configuration?

I am curious since your experience seems to be different from mine. I remember reading that openSUSE installation under some circumstances do read old configuration data and base the new configuration on that. Maybe networking is such an item?

dayfinger