The server is in a datacenter and the Remote Console/KVM isn’t always available. I do have a rescue system where I can mount the disk and restore a network config that does work, but without the bridge.
Since it happened with the latest tumbleweed update, I don’t think it’s hardware related.
What did change with the update was that the interface enp-s31f6 was eth0 before.
Is there another file somewhere perhaps that is still pointing to eth0 that could cause this?
I didn’t install brctl. I read it was deprecated. I used ip and even Yast to build the br0 device
But I can’t show any output like that or bridge vlan since I lose connection when the bridge tries to start.
When I had the Remote Console KVM and I still had server access the server didn’t hang or rebooted always. I noticed there was no internet connectivity. Also route n didn’t show the default route.
When I tried to add one, it said it was a duplicate. Yet, it didn’t work.
Simply returning the naming convention to what was before may not be enough…
You have to inspect the whole dependency chain to verify everything hands off to the next correctly.
Short of that…
Just create a new bridge configured however you wish(must have a different name like br5) and then configure your VMs to use the new bridge device. There won’t be any kind of system penalty having unused bridge devices. Or, once a working device has been created, delete it so that the name label can be re-used (although I wouldn’t necessarily re-use unless I was totally convinced the old device had been fully removed).
I don’t know if any official statement has been made deprecating brctl (unlike for instance ipconfig).
There should not be any problem using brctl or expecting brctl to be made available (through the bridge-utils package) for the forseeable future, it’s only if you’re scripting the creation or management of bridge devices that you might want to use ip or bridge instead so your scripts can live on without any concern for maintenance and obsolescence. To me, brctl is useful because its command options are simple, intuitive and easy to remember.
I also don’t know that there is any concept of a bridge device “starting,”
It’s a static configuration bound to an ordinary network interface so it either works or doesn’t and is “instant” when the underlying network interface is functional.
I didn’t figure it was actually starting something, yet it’s odd it fails like that and a couple of times even rebooted. The service provider offered to swap the hardware, but I am not quit yet there. I can’t imagine how this would be a hardware failure.
I’ll create a new bridge with a new name. See how that goes, tnx.
Just to clarify explicitly - when you used ‘net.ifnames=0’ to get the traditional Ethernet device naming again (ie eth0) did you also make sure to reflect that with the bridge configuration?
It might also be interesting to start the server without the bridge, then stop wicked and create the bridge manually and see if this works as expected.Maybe a regression with wicked somehow?
It’s just a (SUSE-specific) systemd-controlled framework used for ‘automated’ network configuration at boot. Alternative management frameworks are systemdnetworkd.service and NetworkManager (each with their own strengths).
Post the results of the following, assuming you have bridge-utils installed…Or, if you’re using ip or bridge instead the equivalent that displays all configured bridge devices
brctl show
Then,
Describe whether you are using YaST or some other tool to create your bridge device.
I agree that there is really no way that hardware should be an issue, provided that you have working hardware… ie a functioning network card that recognized by the operating system.
BTW - Do you have libvirt installed, and are you using it to manage your virtualization?
You can probably do the same with ip and bridge commands (instead of brctl), you’ll just end up displaying a lot of unnecessary information
eg
ip show
bridge show
Based on what is in the ip and bridge man pages…
Particularly with the ip utility you can probably use options to narrow down what is displayed but could accidentally block relevant data
Although I wouldn’t necessarily discourage any idea,
In general bridge devices are pretty universal…
It should not matter how a bridge device is created using any utility or virtualization technology,
The bridge device should be recognizable and usable by any application or virtualization.
Which reminds me…
I don’t think my earlier question was answered, is libvirt installed and being used?
I’m beginning to suspect by the way that virtualization was not installed using the YaST “Install hypervisor and tools” module,
This is another case where virtualization was installed using the Software Manager.
