Comment 13 for bug 1701023

This bug is caused in two different ways, both not directly from ifupdown or vlan, but instead because of 'helpful' actions in the ifenslave and bridge-utils if-pre-up scripts.

First, as reported in this bug, the bridge-utils package adds a if-pre-up.d/bridge ifupdown script, and in that script it does this:

bridge_parse_ports $INTERFACES | while read i
do
  for port in $i
  do
    # We attach and configure each port of the bridge
    if [ "$MODE" = "start" ] && [ ! -d /sys/class/net/$IFACE/brif/$port ]; then
      if [ -x /etc/network/if-pre-up.d/vlan ]; then
        env IFACE=$port /etc/network/if-pre-up.d/vlan
      fi

As pointed out in comment 2, this is done because debian decided ifupdown should handle the case of a bridge configuration with port(s) using vlan(s) that are not configured/created anywhere else in the ifupdown configuration. So, bridge-utils must assume it needs to create any new vlan(s) for its port(s).

Unfortunately, now that the if-pre-up.d/vlan tries to ifup its raw-device interface (due to bug 1573272) this can lead to a hang, as shown in this bug's description.

Second, as reported in bug 1759573, the ifenslave package adds a if-pre-up.d/ifenslave script, and that script does this:

    # Trigger the udev bridging hook to bridge the bond if needed
    if [ -x /lib/udev/bridge-network-interface ]; then
        INTERFACE=$BOND_MASTER /lib/udev/bridge-network-interface
    fi

    # Trigger the udev bridging hook to tag the bond if needed
    if [ -x /lib/udev/vlan-network-interface ]; then
        INTERFACE=$BOND_MASTER /lib/udev/vlan-network-interface
    fi

This is done for the reasons commented there. Unfortunately, BOTH the /lib/udev/bridge-network-interface as well as the /lib/udev/vlan-network-interface call back to the if-pre-up.d/vlan script, which then tries to ifup the vlan's raw-device, again leading to a hang.