Since update, ifup vmbr1 bridge stucked in state UNKNOWN

[kariboo92]

Since recently, from a fresh install, when I add a second bridge vmbr1 (from Proxmox GUI) for a private network, the vmbr1 interface never goes UP and get stucked in UNKNOWN state. ( the same configuration was working last month )

/etc/network/interfaces

auto lo
iface lo inet loopback


iface enp1s0 inet manual


auto vmbr0
iface vmbr0 inet static
        address xxxxxx/24
        gateway xxxxxxxx
        bridge-ports enp1s0
        bridge-stp off
        bridge-fd 0


auto vmbr1
iface vmbr1 inet static
        address 192.168.0.1/24
        bridge-ports none
        bridge-stp off
        bridge-fd 0
        post-up echo 1 > /proc/sys/net/ipv4/ip_forward

The server get stuck at reboot.

After investigation, in fact the server's script /etc/network/if-pre-up.d/wait_for_link_up loops forever because it is waiting for the vmbr1 interface to show UP, which never happens.

when I manually bring up vmbr1 interface (ifup vmbr1), the state is never going UP but stays UNKNOWN

2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master vmbr0 state UP group default qlen 1000
    link/ether 00:25:90:22:1a:02 brd ff:ff:ff:ff:ff:ff
4: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether xxxxxxxxxxxx brd ff:ff:ff:ff:ff:ff
    inet xxxxxxxxxxx/24 brd xxxxxxx scope global vmbr0
       valid_lft forever preferred_lft forever
6: vmbr1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
    link/ether 4a:aa:07:9a:e1:a9 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.1/24 scope global vmbr1
       valid_lft forever preferred_lft forever

Is this a newly introduced bug ?

proxmox-ve: 6.3-1 (running kernel: 5.4.106-1-pve)
pve-manager: 6.3-6 (running version: 6.3-6/2184247e)
pve-kernel-5.4: 6.3-8
pve-kernel-helper: 6.3-8
pve-kernel-5.4.106-1-pve: 5.4.106-1
ceph-fuse: 12.2.11+dfsg1-2.1+b1
corosync: 3.1.2-pve1
criu: 3.11-3
glusterfs-client: 5.5-3
ifupdown: not correctly installed
ifupdown2: 3.0.0-1+pve3
libjs-extjs: 6.0.1-10
libknet1: 1.20-pve1
libproxmox-acme-perl: 1.0.8
libproxmox-backup-qemu0: 1.0.3-1
libpve-access-control: 6.1-3
libpve-apiclient-perl: 3.1-3
libpve-common-perl: 6.3-5
libpve-guest-common-perl: 3.1-5
libpve-http-server-perl: 3.1-1
libpve-storage-perl: 6.3-9
libqb0: 1.0.5-1
libspice-server1: 0.14.2-4~pve6+1
lvm2: 2.03.02-pve4
lxc-pve: 4.0.6-2
lxcfs: 4.0.6-pve1
novnc-pve: 1.1.0-1
proxmox-backup-client: 1.1.1-1
proxmox-mini-journalreader: 1.1-1
proxmox-widget-toolkit: 2.5-1
pve-cluster: 6.2-1
pve-container: 3.3-4
pve-docs: 6.3-1
pve-edk2-firmware: 2.20200531-1
pve-firewall: 4.1-3
pve-firmware: 3.2-2
pve-ha-manager: 3.1-1
pve-i18n: 2.3-1
pve-qemu-kvm: 5.2.0-5
pve-xtermjs: 4.7.0-3
pve-zsync: 2.0-4
qemu-server: 6.3-10
smartmontools: 7.2-pve2
spiceterm: 3.1-1
vncterm: 1.6-2
zfsutils-linux: 2.0.4-pve1

 

[Stoiko Ivanov]

After investigation, in fact the server's script /etc/network/if-pre-up.d/wait_for_link_up loops forever because it is waiting for the vmbr1 interface to show UP, which never happens.

where does `wait_for_link_up` come from (I don't have that on my test-systems)?
(if it's provided by a debian package `dpkg -S /etc/network/if-pre-up.d/wait_for_link_up` should say which package it is from)

the config should work from a quick glance.

I hope this helps!

 

[kariboo92]

It seems /etc/network/if-pre-up.d/wait_for_link_up is not provided by Proxmox ISO but OVH unattended install's scripts

I've removed this script and everything is fine.
I've opened a ticket at OVH but still no answer. I suspected with the datetime of script that it has been changed or added 23th of april.

Thank you

PS:
The vmbr1 bridge interface changes from state UNKNOW to UP only when VM are starting to use it.

 

[Stoiko Ivanov]

The vmbr1 bridge interface changes from state UNKNOW to UP only when VM are starting to use it.

guess this is the state a bridge interface is in if it has no port associated with it!

I never looked up what the state field there actually indicates (usually the flags between '<' and '>' show the needed information:

<BROADCAST,MULTICAST,UP,LOWER_UP>

says that the interface is administratively up ('UP') and that there is a link present on the lower layer ('LOWER_UP')

 

[haywoodspartan]

I have also come across this issue and it seems that deleting that file fixes all of the issues accordingly as stated above.
I was trying to wrap my head around this when my proxmox on OVH decided to Stall on boot because of wait for link up file causing this.