[Group.of.nepali.translators] [Bug 1701023] Re: (on trusty) version 1.9-3ubuntu10.4 regression blocking boot completion
** Changed in: ifupdown (Ubuntu) Status: In Progress => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1701023 Title: (on trusty) version 1.9-3ubuntu10.4 regression blocking boot completion Status in ifupdown package in Ubuntu: Fix Released Status in vlan package in Ubuntu: Fix Released Status in ifupdown source package in Trusty: Fix Released Status in vlan source package in Trusty: Fix Released Status in ifupdown source package in Xenial: Fix Released Status in vlan source package in Xenial: Fix Released Status in ifupdown source package in Artful: Fix Released Status in vlan source package in Artful: Fix Released Status in ifupdown source package in Bionic: Fix Released Status in vlan source package in Bionic: Fix Released Status in ifupdown package in Debian: Fix Released Status in vlan package in Debian: New Bug description: [impact] 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 -a 1299"): ifup,1299 -a └─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 auto lo iface lo inet loopback auto eth0 iface eth0 inet static address 192.168.10.65 netmask 255.255.255.192 gateway 192.168.10.66 auto eth0.11 address 192.168.11.1 netmask 255.255.255.0 auto br1134 iface br1134 inet manual bridge_ports eth0.1134 bridge_stp off bridge_fd 0 The underlying interface eth0.1134 is not explicitly defined, but was previously auto-created during "ifup -a" execution. This apparently fails now. Reverting back to the 10.1 version re-establishes old behavior. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1701023/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1701023] Re: (on trusty) version 1.9-3ubuntu10.4 regression blocking boot completion
This bug was fixed in the package vlan - 1.9-3.2ubuntu5.17.10.1 --- vlan (1.9-3.2ubuntu5.17.10.1) artful; urgency=medium * Revert change for lp1573272; instead fix by redesigning when vlan interfaces are created; after raw-device ifup, not during raw-device udev processing. (LP: #1701023) -- Dan Streetman Thu, 19 Apr 2018 18:10:17 -0400 ** Changed in: vlan (Ubuntu Artful) Status: Fix Committed => Fix Released ** Changed in: ifupdown (Ubuntu Artful) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1701023 Title: (on trusty) version 1.9-3ubuntu10.4 regression blocking boot completion Status in ifupdown package in Ubuntu: In Progress Status in vlan package in Ubuntu: Fix Released Status in ifupdown source package in Trusty: Fix Released Status in vlan source package in Trusty: Fix Released Status in ifupdown source package in Xenial: Fix Released Status in vlan source package in Xenial: Fix Released Status in ifupdown source package in Artful: Fix Released Status in vlan source package in Artful: Fix Released Status in ifupdown source package in Bionic: Fix Released Status in vlan source package in Bionic: Fix Released Status in ifupdown package in Debian: Fix Released Status in vlan package in Debian: New Bug description: [impact] 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 -a 1299"): ifup,1299 -a └─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 auto lo iface lo inet loopback auto eth0 iface eth0 inet static address 192.168.10.65 netmask 255.255.255.192 gateway 192.168.10.66 auto eth0.11 address 192.168.11.1 netmask 255.255.255.0 auto br1134 iface br1134 inet manual bridge_ports eth0.1134 bridge_stp off bridge_fd 0 The underlying interface eth0.1134 is not explicitly defined, but was previously auto-created during "ifup -a" execution. This apparently fails now. Reverting back to the 10.1 version re-establishes old behavior. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1701023/+subscriptions ___ Mailing l
[Group.of.nepali.translators] [Bug 1701023] Re: (on trusty) version 1.9-3ubuntu10.4 regression blocking boot completion
This bug was fixed in the package vlan - 1.9-3.2ubuntu1.16.04.5 --- vlan (1.9-3.2ubuntu1.16.04.5) xenial; urgency=medium * Revert change for lp1573272; instead fix by redesigning when vlan interfaces are created; after raw-device ifup, not during raw-device udev processing. (LP: #1701023) -- Dan Streetman Thu, 19 Apr 2018 18:10:17 -0400 ** Changed in: ifupdown (Ubuntu Xenial) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1701023 Title: (on trusty) version 1.9-3ubuntu10.4 regression blocking boot completion Status in ifupdown package in Ubuntu: In Progress Status in vlan package in Ubuntu: Fix Released Status in ifupdown source package in Trusty: Fix Released Status in vlan source package in Trusty: Fix Released Status in ifupdown source package in Xenial: Fix Released Status in vlan source package in Xenial: Fix Released Status in ifupdown source package in Artful: Fix Released Status in vlan source package in Artful: Fix Released Status in ifupdown source package in Bionic: Fix Released Status in vlan source package in Bionic: Fix Released Status in ifupdown package in Debian: Fix Released Status in vlan package in Debian: New Bug description: [impact] 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 -a 1299"): ifup,1299 -a └─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 auto lo iface lo inet loopback auto eth0 iface eth0 inet static address 192.168.10.65 netmask 255.255.255.192 gateway 192.168.10.66 auto eth0.11 address 192.168.11.1 netmask 255.255.255.0 auto br1134 iface br1134 inet manual bridge_ports eth0.1134 bridge_stp off bridge_fd 0 The underlying interface eth0.1134 is not explicitly defined, but was previously auto-created during "ifup -a" execution. This apparently fails now. Reverting back to the 10.1 version re-establishes old behavior. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1701023/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nep
[Group.of.nepali.translators] [Bug 1701023] Re: (on trusty) version 1.9-3ubuntu10.4 regression blocking boot completion
This bug was fixed in the package ifupdown - 0.8.16ubuntu2.1 --- ifupdown (0.8.16ubuntu2.1) artful; urgency=medium * We are not even reading the contents of the per-interface state files when running ifquery, so there is no need to lock them. Not locking will allow ifquery to be called recursively from ifup and ifdown. (LP: #1701023) -- Dan Streetman Fri, 27 Apr 2018 08:53:27 -0400 ** Changed in: vlan (Ubuntu Xenial) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1701023 Title: (on trusty) version 1.9-3ubuntu10.4 regression blocking boot completion Status in ifupdown package in Ubuntu: In Progress Status in vlan package in Ubuntu: Fix Released Status in ifupdown source package in Trusty: Fix Released Status in vlan source package in Trusty: Fix Released Status in ifupdown source package in Xenial: Fix Released Status in vlan source package in Xenial: Fix Released Status in ifupdown source package in Artful: Fix Released Status in vlan source package in Artful: Fix Released Status in ifupdown source package in Bionic: Fix Released Status in vlan source package in Bionic: Fix Released Status in ifupdown package in Debian: Fix Released Status in vlan package in Debian: New Bug description: [impact] 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 -a 1299"): ifup,1299 -a └─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 auto lo iface lo inet loopback auto eth0 iface eth0 inet static address 192.168.10.65 netmask 255.255.255.192 gateway 192.168.10.66 auto eth0.11 address 192.168.11.1 netmask 255.255.255.0 auto br1134 iface br1134 inet manual bridge_ports eth0.1134 bridge_stp off bridge_fd 0 The underlying interface eth0.1134 is not explicitly defined, but was previously auto-created during "ifup -a" execution. This apparently fails now. Reverting back to the 10.1 version re-establishes old behavior. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1701023/+subscriptions ___ Mailing list: https://launchpad.net/~group.of
[Group.of.nepali.translators] [Bug 1701023] Re: (on trusty) version 1.9-3ubuntu10.4 regression blocking boot completion
This bug was fixed in the package vlan - 1.9-3ubuntu10.6 --- vlan (1.9-3ubuntu10.6) trusty; urgency=medium * Revert change for lp1573272; instead fix by redesigning when vlan interfaces are created; after raw-device ifup, not during raw-device udev processing. (LP: #1701023) -- Dan Streetman Thu, 19 Apr 2018 18:10:17 -0400 ** Changed in: ifupdown (Ubuntu Trusty) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1701023 Title: (on trusty) version 1.9-3ubuntu10.4 regression blocking boot completion Status in ifupdown package in Ubuntu: In Progress Status in vlan package in Ubuntu: Fix Released Status in ifupdown source package in Trusty: Fix Released Status in vlan source package in Trusty: Fix Released Status in ifupdown source package in Xenial: Fix Released Status in vlan source package in Xenial: Fix Released Status in ifupdown source package in Artful: Fix Released Status in vlan source package in Artful: Fix Released Status in ifupdown source package in Bionic: Fix Released Status in vlan source package in Bionic: Fix Released Status in ifupdown package in Debian: Fix Released Status in vlan package in Debian: New Bug description: [impact] 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 -a 1299"): ifup,1299 -a └─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 auto lo iface lo inet loopback auto eth0 iface eth0 inet static address 192.168.10.65 netmask 255.255.255.192 gateway 192.168.10.66 auto eth0.11 address 192.168.11.1 netmask 255.255.255.0 auto br1134 iface br1134 inet manual bridge_ports eth0.1134 bridge_stp off bridge_fd 0 The underlying interface eth0.1134 is not explicitly defined, but was previously auto-created during "ifup -a" execution. This apparently fails now. Reverting back to the 10.1 version re-establishes old behavior. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1701023/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translator
[Group.of.nepali.translators] [Bug 1701023] Re: (on trusty) version 1.9-3ubuntu10.4 regression blocking boot completion
This bug was fixed in the package ifupdown - 0.8.10ubuntu1.4 --- ifupdown (0.8.10ubuntu1.4) xenial; urgency=medium * We are not even reading the contents of the per-interface state files when running ifquery, so there is no need to lock them. Not locking will allow ifquery to be called recursively from ifup and ifdown. (LP: #1701023) -- Dan Streetman Fri, 27 Apr 2018 08:56:12 -0400 ** Changed in: vlan (Ubuntu Trusty) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1701023 Title: (on trusty) version 1.9-3ubuntu10.4 regression blocking boot completion Status in ifupdown package in Ubuntu: In Progress Status in vlan package in Ubuntu: Fix Released Status in ifupdown source package in Trusty: Fix Released Status in vlan source package in Trusty: Fix Released Status in ifupdown source package in Xenial: Fix Released Status in vlan source package in Xenial: Fix Released Status in ifupdown source package in Artful: Fix Released Status in vlan source package in Artful: Fix Released Status in ifupdown source package in Bionic: Fix Released Status in vlan source package in Bionic: Fix Released Status in ifupdown package in Debian: Fix Released Status in vlan package in Debian: New Bug description: [impact] 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 -a 1299"): ifup,1299 -a └─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 auto lo iface lo inet loopback auto eth0 iface eth0 inet static address 192.168.10.65 netmask 255.255.255.192 gateway 192.168.10.66 auto eth0.11 address 192.168.11.1 netmask 255.255.255.0 auto br1134 iface br1134 inet manual bridge_ports eth0.1134 bridge_stp off bridge_fd 0 The underlying interface eth0.1134 is not explicitly defined, but was previously auto-created during "ifup -a" execution. This apparently fails now. Reverting back to the 10.1 version re-establishes old behavior. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1701023/+subscriptions ___ Mailing list: https://launchpad.net/~group.of
[Group.of.nepali.translators] [Bug 1701023] Re: (on trusty) version 1.9-3ubuntu10.4 regression blocking boot completion
This bug was fixed in the package vlan - 1.9-3.2ubuntu6 --- vlan (1.9-3.2ubuntu6) bionic; urgency=medium * Revert change for lp1573272; instead fix by redesigning when vlan interfaces are created; after raw-device ifup, not during raw-device udev processing. (LP: #1701023) -- Dan Streetman Thu, 19 Apr 2018 18:10:17 -0400 ** Changed in: vlan (Ubuntu Bionic) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1701023 Title: (on trusty) version 1.9-3ubuntu10.4 regression blocking boot completion Status in ifupdown package in Ubuntu: In Progress Status in vlan package in Ubuntu: Fix Released Status in ifupdown source package in Trusty: Fix Committed Status in vlan source package in Trusty: Fix Committed Status in ifupdown source package in Xenial: Fix Committed Status in vlan source package in Xenial: Fix Committed Status in ifupdown source package in Artful: Fix Committed Status in vlan source package in Artful: Fix Committed Status in ifupdown source package in Bionic: Fix Released Status in vlan source package in Bionic: Fix Released Status in ifupdown package in Debian: Fix Released Status in vlan package in Debian: New Bug description: [impact] 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 -a 1299"): ifup,1299 -a └─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 auto lo iface lo inet loopback auto eth0 iface eth0 inet static address 192.168.10.65 netmask 255.255.255.192 gateway 192.168.10.66 auto eth0.11 address 192.168.11.1 netmask 255.255.255.0 auto br1134 iface br1134 inet manual bridge_ports eth0.1134 bridge_stp off bridge_fd 0 The underlying interface eth0.1134 is not explicitly defined, but was previously auto-created during "ifup -a" execution. This apparently fails now. Reverting back to the 10.1 version re-establishes old behavior. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1701023/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translator
[Group.of.nepali.translators] [Bug 1701023] Re: (on trusty) version 1.9-3ubuntu10.4 regression blocking boot completion
This bug was fixed in the package ifupdown - 0.8.17ubuntu1.1 --- ifupdown (0.8.17ubuntu1.1) bionic; urgency=medium * We are not even reading the contents of the per-interface state files when running ifquery, so there is no need to lock them. Not locking will allow ifquery to be called recursively from ifup and ifdown. (LP: #1701023) -- Dan Streetman Fri, 27 Apr 2018 08:00:07 -0400 ** Changed in: ifupdown (Ubuntu Bionic) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1701023 Title: (on trusty) version 1.9-3ubuntu10.4 regression blocking boot completion Status in ifupdown package in Ubuntu: In Progress Status in vlan package in Ubuntu: Fix Released Status in ifupdown source package in Trusty: Fix Committed Status in vlan source package in Trusty: Fix Committed Status in ifupdown source package in Xenial: Fix Committed Status in vlan source package in Xenial: Fix Committed Status in ifupdown source package in Artful: Fix Committed Status in vlan source package in Artful: Fix Committed Status in ifupdown source package in Bionic: Fix Released Status in vlan source package in Bionic: Fix Released Status in ifupdown package in Debian: Fix Released Status in vlan package in Debian: New Bug description: [impact] 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 -a 1299"): ifup,1299 -a └─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 auto lo iface lo inet loopback auto eth0 iface eth0 inet static address 192.168.10.65 netmask 255.255.255.192 gateway 192.168.10.66 auto eth0.11 address 192.168.11.1 netmask 255.255.255.0 auto br1134 iface br1134 inet manual bridge_ports eth0.1134 bridge_stp off bridge_fd 0 The underlying interface eth0.1134 is not explicitly defined, but was previously auto-created during "ifup -a" execution. This apparently fails now. Reverting back to the 10.1 version re-establishes old behavior. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1701023/+subscriptions ___ Mailing list: https://launchpad.net
[Group.of.nepali.translators] [Bug 1701023] Re: (on trusty) version 1.9-3ubuntu10.4 regression blocking boot completion
This bug was fixed in the package vlan - 1.9-3.2ubuntu6 --- vlan (1.9-3.2ubuntu6) bionic; urgency=medium * Revert change for lp1573272; instead fix by redesigning when vlan interfaces are created; after raw-device ifup, not during raw-device udev processing. (LP: #1701023) -- Dan Streetman Thu, 19 Apr 2018 18:10:17 -0400 ** Changed in: vlan (Ubuntu) Status: In Progress => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1701023 Title: (on trusty) version 1.9-3ubuntu10.4 regression blocking boot completion Status in ifupdown package in Ubuntu: In Progress Status in vlan package in Ubuntu: Fix Released Status in ifupdown source package in Trusty: Fix Committed Status in vlan source package in Trusty: Fix Committed Status in ifupdown source package in Xenial: Fix Committed Status in vlan source package in Xenial: Fix Committed Status in ifupdown source package in Artful: Fix Committed Status in vlan source package in Artful: Fix Committed Status in ifupdown source package in Bionic: Fix Committed Status in vlan source package in Bionic: Fix Committed Status in ifupdown package in Debian: Fix Released Status in vlan package in Debian: New Bug description: [impact] 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 -a 1299"): ifup,1299 -a └─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 auto lo iface lo inet loopback auto eth0 iface eth0 inet static address 192.168.10.65 netmask 255.255.255.192 gateway 192.168.10.66 auto eth0.11 address 192.168.11.1 netmask 255.255.255.0 auto br1134 iface br1134 inet manual bridge_ports eth0.1134 bridge_stp off bridge_fd 0 The underlying interface eth0.1134 is not explicitly defined, but was previously auto-created during "ifup -a" execution. This apparently fails now. Reverting back to the 10.1 version re-establishes old behavior. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1701023/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists
[Group.of.nepali.translators] [Bug 1701023] Re: (on trusty) version 1.9-3ubuntu10.4 regression blocking boot completion
** Changed in: ifupdown (Debian) Status: New => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1701023 Title: (on trusty) version 1.9-3ubuntu10.4 regression blocking boot completion Status in ifupdown package in Ubuntu: In Progress Status in vlan package in Ubuntu: In Progress Status in ifupdown source package in Trusty: In Progress Status in vlan source package in Trusty: In Progress Status in ifupdown source package in Xenial: In Progress Status in vlan source package in Xenial: In Progress Status in ifupdown source package in Artful: In Progress Status in vlan source package in Artful: In Progress Status in ifupdown source package in Bionic: In Progress Status in vlan source package in Bionic: In Progress Status in ifupdown package in Debian: Fix Released Status in vlan package in Debian: New Bug 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 -a 1299"): ifup,1299 -a └─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 auto lo iface lo inet loopback auto eth0 iface eth0 inet static address 192.168.10.65 netmask 255.255.255.192 gateway 192.168.10.66 auto eth0.11 address 192.168.11.1 netmask 255.255.255.0 auto br1134 iface br1134 inet manual bridge_ports eth0.1134 bridge_stp off bridge_fd 0 The underlying interface eth0.1134 is not explicitly defined, but was previously auto-created during "ifup -a" execution. This apparently fails now. Reverting back to the 10.1 version re-establishes old behavior. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1701023/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1701023] Re: (on trusty) version 1.9-3ubuntu10.4 regression blocking boot completion
** Bug watch added: Debian Bug tracker #896433 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=896433 ** Also affects: ifupdown (Debian) via https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=896433 Importance: Unknown Status: Unknown ** Bug watch added: Debian Bug tracker #896434 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=896434 ** Also affects: vlan (Debian) via https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=896434 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1701023 Title: (on trusty) version 1.9-3ubuntu10.4 regression blocking boot completion Status in ifupdown package in Ubuntu: In Progress Status in vlan package in Ubuntu: In Progress Status in ifupdown source package in Trusty: In Progress Status in vlan source package in Trusty: In Progress Status in ifupdown source package in Xenial: In Progress Status in vlan source package in Xenial: In Progress Status in ifupdown source package in Artful: In Progress Status in vlan source package in Artful: In Progress Status in ifupdown source package in Bionic: In Progress Status in vlan source package in Bionic: In Progress Status in ifupdown package in Debian: Unknown Status in vlan package in Debian: Unknown Bug 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 -a 1299"): ifup,1299 -a └─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 auto lo iface lo inet loopback auto eth0 iface eth0 inet static address 192.168.10.65 netmask 255.255.255.192 gateway 192.168.10.66 auto eth0.11 address 192.168.11.1 netmask 255.255.255.0 auto br1134 iface br1134 inet manual bridge_ports eth0.1134 bridge_stp off bridge_fd 0 The underlying interface eth0.1134 is not explicitly defined, but was previously auto-created during "ifup -a" execution. This apparently fails now. Reverting back to the 10.1 version re-establishes old behavior. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1701023/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1701023] Re: (on trusty) version 1.9-3ubuntu10.4 regression blocking boot completion
** Also affects: ifupdown (Ubuntu) Importance: Undecided Status: New ** Changed in: ifupdown (Ubuntu Trusty) Importance: Undecided => Medium ** Changed in: ifupdown (Ubuntu Trusty) Status: New => In Progress ** Changed in: ifupdown (Ubuntu Trusty) Assignee: (unassigned) => Dan Streetman (ddstreet) ** Changed in: ifupdown (Ubuntu Xenial) Importance: Undecided => Medium ** Changed in: ifupdown (Ubuntu Xenial) Status: New => In Progress ** Changed in: ifupdown (Ubuntu Xenial) Assignee: (unassigned) => Dan Streetman (ddstreet) ** Changed in: ifupdown (Ubuntu Artful) Importance: Undecided => Medium ** Changed in: ifupdown (Ubuntu Artful) Status: New => In Progress ** Changed in: ifupdown (Ubuntu Artful) Assignee: (unassigned) => Dan Streetman (ddstreet) ** Changed in: ifupdown (Ubuntu Bionic) Importance: Undecided => Medium ** Changed in: ifupdown (Ubuntu Bionic) Status: New => In Progress ** Changed in: ifupdown (Ubuntu Bionic) Assignee: (unassigned) => Dan Streetman (ddstreet) -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1701023 Title: (on trusty) version 1.9-3ubuntu10.4 regression blocking boot completion Status in ifupdown package in Ubuntu: In Progress Status in vlan package in Ubuntu: In Progress Status in ifupdown source package in Trusty: In Progress Status in vlan source package in Trusty: In Progress Status in ifupdown source package in Xenial: In Progress Status in vlan source package in Xenial: In Progress Status in ifupdown source package in Artful: In Progress Status in vlan source package in Artful: In Progress Status in ifupdown source package in Bionic: In Progress Status in vlan source package in Bionic: In Progress Bug 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 -a 1299"): ifup,1299 -a └─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 auto lo iface lo inet loopback auto eth0 iface eth0 inet static address 192.168.10.65 netmask 255.255.255.192 gateway 192.168.10.66 auto eth0.11 address 192.168.11.1 netmask 255.255.255.0 auto br1134 iface br1134 inet manual bridge_ports eth0.1134 bridge_stp off bridge_fd 0 The underlying interface eth0.1134 is not explicitly defined, but was previously auto-created during "ifup -a" execution. This apparently fails now. Reverting back to the 10.1 version re-establishes old behavior. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1701023/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
