-
Notifications
You must be signed in to change notification settings - Fork 77
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ifup finishes successfully but interfaces are still down (bridge on a bond on SR-IOV VF's) #319
Comments
I have a similar issue, but added Ref: #213 |
What did you add allow-hotplug to? I tried it for the VF interfaces but it didn't work. I don't think you're supposed to use allow-hotplug for bonds/bridges. |
It solves the following bug: when I reboot there is no ip loaded, I need to run:
For reasons that I do not understand, it works. And yes, maybe only add for non bridge interfaces |
Ah that didn't work for me unfortunately. If I run |
I'm using ifupdown2
3.2.0-1+pmx11
(the 3.2.0 debian package with proxmox patches - see https://git.proxmox.com/?p=ifupdown2.git;a=summary).interfaces:
on boot
start-networking
runs successfully via systemd (i.e. exits 0), but the interfaces are all down:dmesg shows:
and debug logs show that it's running the commands to bring the interfaces up:
(full logs: ifupdown2.debug.failed.log)
Running
ifreload -a
orifup enp1s0f0v0 enp1s0f1v0
succeed but don't actually bring the interfaces up. If I do anifdown enp1s0f0v0 enp1s0f1v0
, first however, then either command successfully brings the interfaces up, and once everything is up, the network behaves as expected.Initially, I suspected some kind of race condition on boot because I'm setting up and using SR-IOV VF's with udev rules:
but 1) systemd is set up to run
udev settle
first, and in asystemd-analyze plot
, I can see the VF interfaces are up beforestart-networking
is run. Furthermore, if I add longsleep
commands to delayifup
, nothing changes.Weirdly, if I get rid of the bridge, and assign a static IP to the bond, it comes up as expected:
and now dmesg shows:
full logs for the successful case: ifupdown2.debug.succeeded.log
Finally, if I get rid of the SR-IOV VF's, and setup the bridge on the bond on two physical interfaces, it works as expected. I'm suspicious that it may be MAC address related, but as
ifup
runs successfully, I'm not sure where to look.If I do a diff of the two logs linked above, the key difference that I see is that the successful boot brings the bond up with:
MainThread: ifupdown2.NetlinkListenerWithCache: nlcache.py:2606:link_up(): info: bond0: netlink: ip link set dev bond0 up
, and the failed withMainThread: ifupdown: utils.py:305:_log_command_exec(): info: executing /bin/ip -force -batch - [link set dev bond0 up]
I've been debugging this for several days now and am now stuck, so any help is greatly appreciated. Ultimately, I do think this is an
ifupdown2
bug, because at the very least, it shouldn't be exiting 0 if it's not actually able to bring the interfaces up.The text was updated successfully, but these errors were encountered: