root@lp1701023-x:/etc/network/interfaces.d# dpkg -l |grep ifupdown
ii ifupdown 0.8.10ubuntu1.4
amd64 high level tools to configure network interfaces
root@lp1701023-x:/etc/network/interfaces.d# dpkg -l |grep vlan
ii vlan 1.9-3.2ubuntu1.16.04.5
amd64 user mode programs to enable VLANs on your ethernet devices
all comment 19 tests work.
** Tags removed: verification-needed-xenial
** Tags added: verification-done-xenial
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ifupdown in Ubuntu.
(on trusty) version 1.9-3ubuntu10.4 regression blocking boot
Status in ifupdown package in Ubuntu:
Status in vlan package in Ubuntu:
Status in ifupdown source package in Trusty:
Status in vlan source package in Trusty:
Status in ifupdown source package in Xenial:
Status in vlan source package in Xenial:
Status in ifupdown source package in Artful:
Status in vlan source package in Artful:
Status in ifupdown source package in Bionic:
Status in vlan source package in Bionic:
Status in ifupdown package in Debian:
Status in vlan package in Debian:
in bug 1573272, the vlan pkg was changed to perform a full ifup inside
its if-pre-up.d/vlan script. This allowed correct ordering of ifup
for a vlan and its raw-device, as previously there was a race
condition between them (see that bug for details).
However, this causes hangs during ifup with certain specific configs.
The reasons are given starting in comment 13.
The result is a regression for those using the specific ifupdown
configs; when they try to reboot and/or ifup -a, it will hang trying
to bring up their network, preventing boot from finishing (or hanging
before the network is fully configured).
upgrade to the latest vlan package and configure the system with an
affected ifupdown config, then reboot. The reboot will hang while
trying to bring the network up.
see the original description below for an example ifupdown config to
reproduce this, although there are other possible configs that
will/may trigger this regression.
The fix for this moves the creation of the vlan(s) corresponding to a
physical raw-device 'hotplug' event out of the udev processing path
for the raw-device, and into an ifup post script for the raw-device
ifup. If this is not done correctly, then any interfaces that are
hotplugged, and have vlans configured on them, may fail to correctly
create/configure their vlan(s).
This change does remove the direct call to ifup from the if-pre-up.d
(or if-up.d) scripts, so there should not be any regression potential
for more ifup deadlocks.
this required both ifupdown and vlan to be patched. vlan was patched
to remove the problematic call to ifup from the vlan pre-up script,
and add a call to create the vlan interface(s) from a new post-up
script, as well as adding a parameter to vlan-network-interface script
to handle the call from udev itself differently than a call from
elsewhere (such as the if-up.d/vlan script). this works for bootup
and ifup/ifup -a, but fails for device hotplug because of a bug in
ifupdown that prevents calling ifquery from an ifup script; that has
been patched upstream already, and is the only ifupdown change needed
When upgrading from version 1.9-3ubuntu10.1, a previously working
machine can't successfully reboot completely.
ifup is hanging indefinitely, with this process structure (from
"pstree -a 1299"):
<begin content of /etc/network/interfaces>
iface lo inet loopback
iface eth0 inet static
iface br1134 inet manual
<end content of /etc/network/interfaces>
The underlying interface eth0.1134 is not explicitly defined, but was
previously auto-created during "ifup -a" execution. This apparently
Reverting back to the 10.1 version re-establishes old behavior.
To manage notifications about this bug go to:
Mailing list: https://launchpad.net/~touch-packages
Post to : firstname.lastname@example.org
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp