[opensuse] network bridge error, "systemd-udevd[1596]: Could not generate persistent MAC address for br0: No such file or directory" ?
I'm running opensuse leap 15.1 with linux kernel 5.4.11 as a Xen 4.13 Dom0/server.
I set up a br0 on boot in dom0,
cat /etc/sysconfig/network/ifcfg-br0
NAME='br0'
BRIDGE='yes'
STARTMODE='auto'
BOOTPROTO='static'
BRIDGE_PORTS='eno1'
BRIDGE_STP='on'
BRIDGE_MAXAGE='6'
BRIDGE_HELLOTIME='1'
BRIDGE_FORWARDDELAY='4'
IPV6INIT='no'
IPV6_AUTOCONF='no'
IPADDR0='10.0.0.1/24'
NETWORK=''
BROADCAST=''
REMOTE_IPADDR=''
USERCONTROL='no'
LINK_REQUIRED=no
on boot, the bridge is up/running,
ifconfig br0
br0: flags=4163
PGNet Dev wrote:
I'm running opensuse leap 15.1 with linux kernel 5.4.11 as a Xen 4.13 Dom0/server.
I set up a br0 on boot in dom0,
cat /etc/sysconfig/network/ifcfg-br0 NAME='br0' BRIDGE='yes' STARTMODE='auto' BOOTPROTO='static' BRIDGE_PORTS='eno1' [snip] [ 29.034678] e1000e: eno1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None [ 29.034714] br0: port 1(eno1) entered blocking state [ 29.034715] br0: port 1(eno1) entered listening state [ 33.288229] br0: port 1(eno1) entered learning state [ 37.384229] br0: port 1(eno1) entered forwarding state [ 37.384244] br0: topology change detected, propagating ...
reading
udevd: Could not generate persistent MAC address for $name: No such file or directory #3374 https://github.com/systemd/systemd/issues/3374
Looking at my own 15.0 xenhost, the MAC address for a bridge comes from the physical interface, in my case 'eth0', in your case 'eno1'. Your MAC address seems to be '0c:c4:7a:48:9a:7e' , which suggests Supermicro hardware. The bugreport is quite old, but it doesn't look like it has been fixed. I see some comments suggesting it is a timing or a race issue - any chance of that?
i created
/etc/udev/rules.d/01-net-setup-link.rules SUBSYSTEM=="net", ACTION=="add|change", ENV{INTERFACE}=="br-*", PROGRAM="/bin/sleep 0.5"
To delay things a bit, okay. "br-*" - does that hyphen belong in there ? -- Per Jessen, Zürich (4.9°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 1/15/20 10:53 PM, Per Jessen wrote:
Supermicro hardware.
yup.
I see some comments suggesting it is a timing or a race issue - any chance of that?
it appears that the bridge, although always 'up' after boot, is sometimes/infrequently 'dead'. meaning, I can't ping to external net. until I systemctl restart network then all's ok. the intermittency suggests a close race is possible. atm, not sure _what_ might be the cause.
/etc/udev/rules.d/01-net-setup-link.rules SUBSYSTEM=="net", ACTION=="add|change", ENV{INTERFACE}=="br-*", PROGRAM="/bin/sleep 0.5"
To delay things a bit, okay.
"br-*" - does that hyphen belong in there ?
I suspect not. Thx for the catch. Makes no difference to either the error msg, or the intermittent (maybe) race, unfortunately. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
PGNet Dev wrote:
On 1/15/20 10:53 PM, Per Jessen wrote:
I see some comments suggesting it is a timing or a race issue - any chance of that?
it appears that the bridge, although always 'up' after boot, is sometimes/infrequently 'dead'. meaning, I can't ping to external net.
until I
systemctl restart network
then all's ok.
Wild guess - on boot-up, any chance the bridge is being started before 'eno1' is up? That must be what you're thinking too, hence the attempt to delay? Could this theory be proven by leaving the bridge in manual start mode and then starting manually once the system is up? -- Per Jessen, Zürich (4.6°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 1/16/20 11:40 PM, Per Jessen wrote:
Wild guess - on boot-up, any chance the bridge is being started before 'eno1' is up? That must be what you're thinking too, hence the attempt to delay?
Could this theory be proven by leaving the bridge in manual start mode and then starting manually once the system is up?
I've found a workaround. not clear yet if it's a fix. still suspect a race ... In this case, the SM mobo's eth port (eno1) is 'e1000' class, 25: PCI 19.0: 0200 Ethernet controller ... Hardware Class: network Device Name: "Intel i217V #1" Model: "Intel Ethernet Connection I217-LM" Vendor: pci 0x8086 "Intel Corporation" Device: pci 0x153a "Ethernet Connection I217-LM" SubVendor: pci 0x15d9 "Super Micro Computer Inc" SubDevice: pci 0x153a Revision: 0x05 Driver: "e1000e" Driver Modules: "e1000e" Device File: eno1 ... digging around, I found an ~ 5yr-old issue, https://serverfault.com/questions/616485/e1000e-reset-adapter-unexpectedly-d... per that post, and some other related info, I added /etc/sysconfig/network/ifcfg-eno1 ... + POST_UP_SCRIPT="wicked:/etc/sysconfig/network/scripts/ethtool.loc" where, conditionally/explicitly, for real/physical interfaces (IFACE == eno1, NOT br0), /etc/sysconfig/network/scripts/ethtool.loc ... + ethtool -K ${IFACE} rx off tx off sg off tso off ufo off gso off gro off lro off rxvlan off txvlan off rxhash off now, on reboot -- after a dozen or so attempts -- there's no more br0 functional intermittency; it's up/functional each & every time and, dmesg | egrep "br0|bridge" | grep -v "pci 0000" [ 2.600285] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug [ 2.689167] PCI host bridge to bus 0000:00 [ 30.759526] bridge: filtering via arp/ip/ip6tables is no longer available by default. Update your scripts to load br_netfilter if you need this. [ 31.616612] br0: port 1(eno1) entered blocking state [ 31.616614] br0: port 1(eno1) entered disabled state [ 36.378775] br0: port 1(eno1) entered blocking state [ 36.378776] br0: port 1(eno1) entered listening state [ 40.440309] br0: port 1(eno1) entered learning state [ 44.536333] br0: port 1(eno1) entered forwarding state [ 44.536349] br0: topology change detected, propagating [ 44.536503] IPv6: ADDRCONF(NETDEV_CHANGE): br0: link becomes ready no more trace of that^^ "Could not generate persistent MAC address for br0: No such file or directory" error. ( side note: I _do_ have lsmod | grep br_netfilter br_netfilter 28672 0 bridge 208896 1 br_netfilter not clear whether the br_netfilter msg is a problem; suspect it's just a still noisy info/warn ) so, this^ worked to rm the error; atm, I'm not clear why ... or why it 'suddenly' manifested perhaps default ethtool setting attempts were incorrectly made on the br0 itfc? causing a (now sufficient) race cond? dunno. i've some concern that i've masked -- not fixed -- the problem, so will need to keep an eye on this awhile. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (2)
-
Per Jessen -
PGNet Dev