could we get the SRU template information included in this bug?
doh. sorry, been awfully busy lately. added.
** Description changed:
+ 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).
+ [test case]
+ 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.
+ [regression potential]
+ 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.
+ [other info]
+ 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 here.
+ [original description]
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
- └─run-parts,1501 /etc/network/if-pre-up.d
- └─bridge,1502 /etc/network/if-pre-up.d/bridge
- └─bridge,1508 /etc/network/if-pre-up.d/bridge
- └─vlan,1511 /etc/network/if-pre-up.d/vlan
- └─ifup,1532 eth0
+ └─run-parts,1501 /etc/network/if-pre-up.d
+ └─bridge,1502 /etc/network/if-pre-up.d/bridge
+ └─bridge,1508 /etc/network/if-pre-up.d/bridge
+ └─vlan,1511 /etc/network/if-pre-up.d/vlan
+ └─ifup,1532 eth0
<begin content of /etc/network/interfaces>
iface lo inet loopback
iface eth0 inet static
- address 192.168.10.65
- netmask 255.255.255.192
- gateway 192.168.10.66
+ address 192.168.10.65
+ netmask 255.255.255.192
+ gateway 192.168.10.66
- address 192.168.11.1
- netmask 255.255.255.0
+ address 192.168.11.1
+ netmask 255.255.255.0
iface br1134 inet manual
- bridge_ports eth0.1134
- bridge_stp off
- bridge_fd 0
+ bridge_ports eth0.1134
+ bridge_stp off
+ bridge_fd 0
<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.
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
(on trusty) version 1.9-3ubuntu10.4 regression blocking boot
To manage notifications about this bug go to:
ubuntu-bugs mailing list