[Touch-packages] [Bug 1701023] Re: (on trusty) version 1.9-3ubuntu10.4 regression blocking boot completion

2020-07-14 Thread Dan Streetman
removing sts tag, as this is still marked new for vlan in debian; any
vlan delta to debian should be handled elsewhere and is more than this
bug's patches.

** Tags removed: sts

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ifupdown in Ubuntu.
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/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1701023] Re: (on trusty) version 1.9-3ubuntu10.4 regression blocking boot completion

2018-05-25 Thread Dan Streetman
** Changed in: ifupdown (Ubuntu)
   Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ifupdown in Ubuntu.
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/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1701023] Re: (on trusty) version 1.9-3ubuntu10.4 regression blocking boot completion

2018-05-24 Thread Launchpad Bug Tracker
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 Ubuntu
Touch seeded packages, which is subscribed to ifupdown in Ubuntu.
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/~touch-packages
Post to : touch-packages@lis

[Touch-packages] [Bug 1701023] Re: (on trusty) version 1.9-3ubuntu10.4 regression blocking boot completion

2018-05-24 Thread Launchpad Bug Tracker
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 Ubuntu
Touch seeded packages, which is subscribed to ifupdown in Ubuntu.
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/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   :

[Touch-packages] [Bug 1701023] Re: (on trusty) version 1.9-3ubuntu10.4 regression blocking boot completion

2018-05-24 Thread Launchpad Bug Tracker
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 Ubuntu
Touch seeded packages, which is subscribed to ifupdown in Ubuntu.
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/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https

[Touch-packages] [Bug 1701023] Re: (on trusty) version 1.9-3ubuntu10.4 regression blocking boot completion

2018-05-24 Thread Launchpad Bug Tracker
This bug was fixed in the package ifupdown - 0.7.47.2ubuntu4.5

---
ifupdown (0.7.47.2ubuntu4.5) trusty; 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 09:03:18
-0400

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ifupdown in Ubuntu.
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/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/List

[Touch-packages] [Bug 1701023] Re: (on trusty) version 1.9-3ubuntu10.4 regression blocking boot completion

2018-05-24 Thread Launchpad Bug Tracker
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 Ubuntu
Touch seeded packages, which is subscribed to ifupdown in Ubuntu.
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/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.

[Touch-packages] [Bug 1701023] Re: (on trusty) version 1.9-3ubuntu10.4 regression blocking boot completion

2018-05-24 Thread Launchpad Bug Tracker
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 Ubuntu
Touch seeded packages, which is subscribed to ifupdown in Ubuntu.
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/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https

[Touch-packages] [Bug 1701023] Re: (on trusty) version 1.9-3ubuntu10.4 regression blocking boot completion

2018-05-24 Thread Launchpad Bug Tracker
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 Ubuntu
Touch seeded packages, which is subscribed to ifupdown in Ubuntu.
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/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.

[Touch-packages] [Bug 1701023] Re: (on trusty) version 1.9-3ubuntu10.4 regression blocking boot completion

2018-05-24 Thread Launchpad Bug Tracker
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 Ubuntu
Touch seeded packages, which is subscribed to ifupdown in Ubuntu.
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/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscri

[Touch-packages] [Bug 1701023] Re: (on trusty) version 1.9-3ubuntu10.4 regression blocking boot completion

2018-05-24 Thread Łukasz Zemczak
I think this aged long enough in -proposed - releasing.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ifupdown in Ubuntu.
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/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1701023] Re: (on trusty) version 1.9-3ubuntu10.4 regression blocking boot completion

2018-05-18 Thread Dan Streetman
trusty:

root@lp1701023:~# dpkg -l | grep ifupdown
ii  ifupdown 0.7.47.2ubuntu4.4  
amd64high level tools to configure network interfaces
root@lp1701023:~# dpkg -l | grep vlan
ii  vlan 1.9-3ubuntu10.5
amd64user mode programs to enable VLANs on your ethernet devices
root@lp1701023:~# 

I verified comment 19 tests all passed (ifup -a, reboot, hotplug) as
expected for these pkg versions.

I also verified with the e/n/i config from this bug's description does
cause the hang failure as expected (tested with ifup -a).


root@lp1701023:/etc/network/interfaces.d# dpkg -l | grep ifupdown
ii  ifupdown 0.7.47.2ubuntu4.5  
amd64high level tools to configure network interfaces
root@lp1701023:/etc/network/interfaces.d# dpkg -l | grep vlan
ii  vlan 1.9-3ubuntu10.6
amd64user mode programs to enable VLANs on your ethernet devices


With the updated -proposed pkgs, I verified it passes all comment 19 tests 
(ifup -a, reboot, hotplug).

I also verified that the e/n/i config from this bug's description does
not hang, and properly brings up all configured interfaces with the
right config (for ifup -a, reboot, and hotplug).

** Tags removed: verification-needed verification-needed-trusty
** Tags added: verification-done verification-done-trusty

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ifupdown in Ubuntu.
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,150

[Touch-packages] [Bug 1701023] Re: (on trusty) version 1.9-3ubuntu10.4 regression blocking boot completion

2018-05-17 Thread Dan Streetman
xenial:

root@lp1701023-x:/etc/network/interfaces.d# dpkg -l |grep ifupdown
ii  ifupdown 0.8.10ubuntu1.4
amd64high 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 
amd64user 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.
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/~touch-packages
Post to   

[Touch-packages] [Bug 1701023] Re: (on trusty) version 1.9-3ubuntu10.4 regression blocking boot completion

2018-05-17 Thread Dan Streetman
tested on artful with:

root@lp1701023-a:~# dpkg -l | grep ifupdown
ii  ifupdown   0.8.16ubuntu2.1  
amd64high level tools to configure network interfaces
root@lp1701023-a:~# dpkg -l | grep vlan
ii  vlan   1.9-3.2ubuntu5.17.10.1   
amd64user mode programs to enable VLANs on your ethernet 
devices


all tests from comment 19 work.  as the previous versions also all worked, no 
need to test them again.

** Tags removed: verification-needed-artful
** Tags added: verification-done-artful

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ifupdown in Ubuntu.
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/+subscript

[Touch-packages] [Bug 1701023] Re: (on trusty) version 1.9-3ubuntu10.4 regression blocking boot completion

2018-05-17 Thread Dan Streetman
tested bionic per comment 19 with:

root@lp1701023-b:~# dpkg -l | grep ifupdown
ii  ifupdown 0.8.17ubuntu1 amd64
high level tools to configure network interfaces
root@lp1701023-b:~# dpkg -l | grep vlan
ii  vlan 1.9-3.2ubuntu5amd64
user mode programs to enable VLANs on your ethernet devices

and with:

root@lp1701023-b:~# dpkg -l | grep ifupdown
ii  ifupdown 0.8.17ubuntu1.1   amd64
high level tools to configure network interfaces
root@lp1701023-b:~# dpkg -l | grep vlan
ii  vlan 1.9-3.2ubuntu6amd64
user mode programs to enable VLANs on your ethernet devices


all tests from comment 19 do work with both package versions.

** Tags removed: verification-needed-bionic
** Tags added: verification-done-bionic

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ifupdown in Ubuntu.
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 n

[Touch-packages] [Bug 1701023] Re: (on trusty) version 1.9-3ubuntu10.4 regression blocking boot completion

2018-05-15 Thread Launchpad Bug Tracker
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 Ubuntu
Touch seeded packages, which is subscribed to ifupdown in Ubuntu.
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/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchp

[Touch-packages] [Bug 1701023] Re: (on trusty) version 1.9-3ubuntu10.4 regression blocking boot completion

2018-05-10 Thread Dan Streetman
I sent an email to ubuntu-server list requesting anyone with vlan
ifupdwon config to give these -proposed pkgs a test.

I'll also perform verification for them when I have a chance.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ifupdown in Ubuntu.
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:
  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/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1701023] Re: (on trusty) version 1.9-3ubuntu10.4 regression blocking boot completion

2018-05-10 Thread Łukasz Zemczak
Hello Sven, or anyone else affected,

Accepted ifupdown into trusty-proposed. The package will build now and
be available at
https://launchpad.net/ubuntu/+source/ifupdown/0.7.47.2ubuntu4.5 in a few
hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested and change the tag from
verification-needed-trusty to verification-done-trusty. If it does not
fix the bug for you, please add a comment stating that, and change the
tag to verification-failed-trusty. In either case, without details of
your testing we will not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance!

** Changed in: ifupdown (Ubuntu Trusty)
   Status: In Progress => Fix Committed

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ifupdown in Ubuntu.
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:
  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

[Touch-packages] [Bug 1701023] Re: (on trusty) version 1.9-3ubuntu10.4 regression blocking boot completion

2018-05-10 Thread Łukasz Zemczak
Hello Sven, or anyone else affected,

Accepted ifupdown into artful-proposed. The package will build now and
be available at
https://launchpad.net/ubuntu/+source/ifupdown/0.8.16ubuntu2.1 in a few
hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested and change the tag from
verification-needed-artful to verification-done-artful. If it does not
fix the bug for you, please add a comment stating that, and change the
tag to verification-failed-artful. In either case, without details of
your testing we will not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance!

** Changed in: ifupdown (Ubuntu Artful)
   Status: In Progress => Fix Committed

** Changed in: vlan (Ubuntu Xenial)
   Status: In Progress => Fix Committed

** Tags added: verification-needed-xenial

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ifupdown in Ubuntu.
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:
  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 ine

[Touch-packages] [Bug 1701023] Re: (on trusty) version 1.9-3ubuntu10.4 regression blocking boot completion

2018-05-10 Thread Łukasz Zemczak
Hello Sven, or anyone else affected,

Accepted vlan into artful-proposed. The package will build now and be
available at
https://launchpad.net/ubuntu/+source/vlan/1.9-3.2ubuntu5.17.10.1 in a
few hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested and change the tag from
verification-needed-artful to verification-done-artful. If it does not
fix the bug for you, please add a comment stating that, and change the
tag to verification-failed-artful. In either case, without details of
your testing we will not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance!

** Changed in: vlan (Ubuntu Artful)
   Status: In Progress => Fix Committed

** Tags added: verification-needed-artful

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ifupdown in Ubuntu.
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:
  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

[Touch-packages] [Bug 1701023] Re: (on trusty) version 1.9-3ubuntu10.4 regression blocking boot completion

2018-05-07 Thread Dan Streetman
>  I would feel better if a wider call-for-testing could be done on these 
> packages
> in bionic-proposed

yes i agree; the mailing lists that comes to mind is ubuntu-server, do
you have any other ML suggestion?

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ifupdown in Ubuntu.
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:
  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/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1701023] Re: (on trusty) version 1.9-3ubuntu10.4 regression blocking boot completion

2018-05-07 Thread Łukasz Zemczak
Hello Sven, or anyone else affected,

Accepted vlan into bionic-proposed. The package will build now and be
available at https://launchpad.net/ubuntu/+source/vlan/1.9-3.2ubuntu6 in
a few hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested and change the tag from
verification-needed-bionic to verification-done-bionic. If it does not
fix the bug for you, please add a comment stating that, and change the
tag to verification-failed-bionic. In either case, without details of
your testing we will not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance!

** Changed in: vlan (Ubuntu Bionic)
   Status: In Progress => Fix Committed

** Tags added: verification-needed verification-needed-bionic

** Changed in: ifupdown (Ubuntu Bionic)
   Status: In Progress => Fix Committed

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ifupdown in Ubuntu.
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:
  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 in

[Touch-packages] [Bug 1701023] Re: (on trusty) version 1.9-3ubuntu10.4 regression blocking boot completion

2018-05-07 Thread Łukasz Zemczak
Seeing that the previous change caused regressions, I would feel better
if a wider call-for-testing could be done on these packages in bionic-
proposed, performing tests on various different configurations.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ifupdown in Ubuntu.
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:
  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/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1701023] Re: (on trusty) version 1.9-3ubuntu10.4 regression blocking boot completion

2018-05-07 Thread Dan Streetman
> could we get the SRU template information included in this bug?

doh. sorry, been awfully busy lately.  added.

** Description changed:

+ [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
- 
+   └─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
+   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
+   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
+   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.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ifupdown in Ubuntu.
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:
  [impact]

  in bug 1573272, the vlan pkg was changed to perform a full ifup inside
  its if-pre-up.d/vlan script.  This allowed co

[Touch-packages] [Bug 1701023] Re: (on trusty) version 1.9-3ubuntu10.4 regression blocking boot completion

2018-05-07 Thread Łukasz Zemczak
@ddstreet - could we get the SRU template information included in this
bug?

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ifupdown in Ubuntu.
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/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1701023] Re: (on trusty) version 1.9-3ubuntu10.4 regression blocking boot completion

2018-05-01 Thread Dan Streetman
> Neither issue is fixed by the downgrade

ok, thanks, so those are ifupdown issues unrelated to this vlan
regression - please feel free to open bug(s) for them.  I'll start an
sru for this.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ifupdown in Ubuntu.
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/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1701023] Re: (on trusty) version 1.9-3ubuntu10.4 regression blocking boot completion

2018-05-01 Thread Tom Verdaat
Neither issue is fixed by the downgrade. As said, neither seems to have
to do with vlan but with ifupdown.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ifupdown in Ubuntu.
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/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1701023] Re: (on trusty) version 1.9-3ubuntu10.4 regression blocking boot completion

2018-04-30 Thread Dan Streetman
> We migrated from separate files in /etc/networking/interfaces.d to just 
> declaring
> everything in the single /etc/networking/interfaces file. This overcomes a 
> lot of
> issues with regards to bringing interfaces up in the proper order and "ifup 
> -a"
> now works perfectly again

great.

> (a) to have bonds come up correctly you absolutely have to define slaves 
> before the
> bond master and the primary slave before secondary slaves in the 
> configuration file,
> and (b) to have a vlan come up correctly define its raw device before the 
> vlan device.

yep, I'm pretty sure this is how ifupdown has always behaved.  However,
please do feel free to open a bug, as it should work better and not
require specific ordering like this (I just can't promise it will get
fixed soon).  Also, if it ever worked in the past that you know of, it's
more likely to be fixed, so do note that if you open a new bug.

> bringing bonds up correctly at boot does not

it should - can you please downgrade to the vlan version
1.9-3.2ubuntu1.16.04.1 (assuming you're on Xenial), and if it still
fails there, please open a new bug.  If it doesn't fail there, then let
me know in this bug, as it's a regression from my changes.

You can download the older vlan package from here:
https://launchpad.net/ubuntu/+source/vlan/1.9-3.2ubuntu1.16.04.1

click on the arch you're using under 'Builds' to get to the arch-specific page 
with binary deb links, e.g. for amd64:
http://launchpadlibrarian.net/289303685/vlan_1.9-3.2ubuntu1.16.04.1_amd64.deb

< There is a problem when running a bond on top of vlans

also please test this with above-mentioned vlan package version, and
open a new bug if it fails there as well, or post here if it works with
that older vlan version.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ifupdown in Ubuntu.
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/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1701023] Re: (on trusty) version 1.9-3ubuntu10.4 regression blocking boot completion

2018-04-30 Thread Tom Verdaat
Hi @ddstreet. Completely understand your need to limit the scope of this
bug. Just shared our findings, but feel free to ignore the stuff in #28
under item 2. We did a lot of extensive testing over the weekend with
the latest version of your PPA package and here are our main findings:

1) We migrated from separate files in /etc/networking/interfaces.d to
just declaring everything in the single /etc/networking/interfaces file.
This overcomes a lot of issues with regards to bringing interfaces up in
the proper order and "ifup -a" now works perfectly again. Some lessons
learned for future reference: (a) to have bonds come up correctly you
absolutely have to define slaves before the bond master and the primary
slave before secondary slaves in the configuration file, and (b) to have
a vlan come up correctly define its raw device before the vlan device.

2) Even though "ifup -a" now works again, bringing bonds up correctly at
boot does not. Pretty sure this has to do with the raw interfaces being
detected by the kernel and brought up by systemd in a different order at
boot. As said under (1) the order really really matters. Bringing up a
secondary slave before the primary slave seems to break the bond (looks
like due to using the wrong MAC address) and it looks like this is what
sometimes happens at boot. Our workaround mentioned in #28 under (3)
mitigates this, but it's not very elegant at all.

3) There is a problem when running a bond on top of vlans. Running ifup
with verbose enabled shows run-parts being executed in (what seems like)
alphabetical order, but to enslave a vlan interface, run-part
/etc/network/if-pre-up.d/vlan should be executed before run-part
/etc/network/if-pre-up.d/ifenslave. For now we added "pre-up export
IFACE= IF_VLAN_RAW_DEVICE=; /etc/network/if-pre-
up.d/vlan" to all vlan slaves as a workaround, but it would be better to
fix this in the ifupdown package itself.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ifupdown in Ubuntu.
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/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1701023] Re: (on trusty) version 1.9-3ubuntu10.4 regression blocking boot completion

2018-04-27 Thread Dan Streetman
I updated the ifupdown pkg builds in my test ppa using the upstream
(debian) patch, which is a variation of my previous patch.  Anyone
affected by this regression please test with the latest ifupdown and
vlan pkgs from my ppa.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ifupdown in Ubuntu.
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/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1701023] Re: (on trusty) version 1.9-3ubuntu10.4 regression blocking boot completion

2018-04-26 Thread Dan Streetman
> Unfortunately it turns out this change does not fix the issue of interfaces 
> not
> coming up correctly for a bond with a (static) network configuration

Please keep in mind this bug is *specifically* about the regression
caused by the change from bug 1573272, as described in this bug
description.  My test criteria for the patches for this bug are listed
in comment 17 and comment 18.  This bug is *not* about any issue that
has never worked.  If your configuration worked using (assuming Xenial)
vlan version 1.9-3.2ubuntu1.16.04.1, but does not work now, then please
let me know the details; however if your config doesn't work with
(assuming Xenial) vlan version 1.9-3.2ubuntu1.16.04.1 then it's
unrelated to this bug and you should open a new bug (or un-dup bug
1759573, if appropriate).

> Executing "ifdown -a; ifup -a" shows that ifupdown tries to bring up
the bond BEFORE the slaves

what's your EXACT e/n/i configuration.  single file or multiple files?
ifup -a brings them up in order that they are listed in e/n/i

> bonds relying on slaves having "bond-master"...

this is nothing new and has nothing to do with this bug.  If this is an
issue for you, please open a new bug.  I agree with you in principle
that this should be better, but that's no guarantee it will actually get
fixed.

> bringing a specific interface up automatically brings up it's child
vlans...

this also is nothing new.  this is how things have worked for a long
time, and it has nothing to do with this bug.  If this is a problem for
you, please open a new bug and discuss there.  Note I do not think this
will change without some significant justification (provided in a new
bug, not here please) for why it's a problem.

> a vlan running on top of a bond cannot be brought up directly...

also...nothing new.  unrelated to this bug.  please open a new bug if
this is a problem for you.  Also, doubt this will change without
specific justification (not provided here, please) for why this is a
problem.

I can understand your frustration with the delicate nature of ifupdown;
its configuration is more 'delicate' than most users would like, and
calling ifup directly for specific interfaces doesn't always work the
way you would like, for more complicated configurations.  However, it's
been like this, and for the most part you just have to learn its
limitations and live with them.  Opening bugs for ifupdown limitations
is fine, but some things just won't be changed.

In the future, netplan and/or systemd-networkd take over interface
configuration, and I think you may find them much more reliable and
robust, although maybe more complicated to configure and/or less
"flexible" than ifupdown in some ways.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ifupdown in Ubuntu.
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/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1701023] Re: (on trusty) version 1.9-3ubuntu10.4 regression blocking boot completion

2018-04-26 Thread Tom Verdaat
We've been doing a lot more testing and debugging and I'd like to share
our findings:

1) Unfortunately it turns out this change does not fix the issue of interfaces 
not coming up correctly for a bond with a (static) network configuration. The 
race condition seems to be removed so at least there are no more hangs between 
bonds and their vlan children. All the interfaces also say they are UP both 
when running ifup and after reboot. However:
- Running "ifup " does bring up the bond (and its vlans) in a 
working state.
- Running "ifup -a" or rebooting don't actually work, causing "network not 
available" errors and "Destination Host Unreachable" when pinging other 
machines. Executing "ifdown -a; ifup -a" shows that ifupdown tries to bring up 
the bond BEFORE the slaves in stead of the other way around. Even though after 
the 60s timeout the bond and it's slaves say they are UP, they don't actually 
function.
- We're not seeing any issues with bonds that do not have a network 
configuration of their own

2) The networking script stack / concept seems fundamentally flawed in
three areas:

2.A) bonds relying on slaves having "bond-master" and being started by
bringing up the slaves, but not supporting the master having "bond-
slaves" and being able to start a bond by just bringing up the bond
directly.

2.B) bringing a specific interface up automatically brings up it's child
vlans. This does not make a lot of sense. The other way around does -
e.g. in order to bring up a vlan we need to bring up it's raw device -
but why would the ifupdown scripts assume that I want to bring up all of
it's vlans when I bring up an interface that (also) serves as a raw
device? In that case I would probably run "ifup -a"!

2.C) a vlan running on top of a bond cannot be brought up directly due to 
/sys/class/net// not existing. This results in the following:
>  # ifup bo-adm.2
>  Set name-type for VLAN subsystem. Should be visible in /proc/net/vlan/config
>  cat: /sys/class/net/bo-adm/mtu: No such file or directory
>  Device "bo-adm" does not exist.
>  bo-adm does not exist, unable to create bo-adm.2
>  run-parts: /etc/network/if-pre-up.d/vlan exited with return code 1
>  Failed to bring up bo-adm.2.

3) Our new workaround for boot has become this very intrusive systemd service:
> [Unit]
> Wants=network-online.target
> After=network-online.target
> 
> [Install]
> WantedBy=multi-user.target
> 
> [Service]
> Type=oneshot
> ExecStartPre=/sbin/ifdown bo-adm
> ExecStart=/sbin/ifup enp0s3
> ExecStart=/sbin/ifup enp0s10
> ExecStop=/sbin/ifdown bo-adm
> RemainAfterExit=yes
> TimeoutStartSec=5min

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ifupdown in Ubuntu.
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/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1701023] Re: (on trusty) version 1.9-3ubuntu10.4 regression blocking boot completion

2018-04-25 Thread Dan Streetman
Debian's included a variation of my patch to ifupdown, so I'll update my
ppa to use that patch instead and do some testing, then start sru'ing
both ifupdown and vlan.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ifupdown in Ubuntu.
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/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1701023] Re: (on trusty) version 1.9-3ubuntu10.4 regression blocking boot completion

2018-04-25 Thread Bug Watch Updater
** Changed in: ifupdown (Debian)
   Status: New => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ifupdown in Ubuntu.
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/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1701023] Re: (on trusty) version 1.9-3ubuntu10.4 regression blocking boot completion

2018-04-23 Thread Dan Streetman
> @ddstreet tested with the latest version of ifupdown and vlan from your PPA 
> with
> my 4 testscenario's and can confirm it works as expected. Interfaces come up
> correctly both when doing an "ifup -a" and during boot.

Excellent, thanks.

> One small thing I've noticed is a variation in the number of "Set name-type 
> for
> VLAN subsystem. Should be visible in /proc/net/vlan/config" messages in the
> ifup output depending on the different scenario, even though the number of
> vlans is the same in all 4 tests

That's because in your config tests with vlans on bonds, your call to
ifup -a doesn't actually process the bond or its vlans.  Your ifup -a
starts processing one of the bond slaves, and that causes the bond
interface to by created.  The bond creation is detected by udev, and
udev tells systemd, and systemd then invokes ifup directly on the bond
interface.  By the time your ifup -a has gotten to trying to bring up
the bond (or its vlans), they are already up because of udev detection
which invokes the 'hotplug' ifup that logs to systemd logs, not your
stdout.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ifupdown in Ubuntu.
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:
  New
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/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1701023] Re: (on trusty) version 1.9-3ubuntu10.4 regression blocking boot completion

2018-04-21 Thread Tom Verdaat
@ddstreet tested with the latest version of ifupdown and vlan from your
PPA with my 4 testscenario's and can confirm it works as expected.
Interfaces come up correctly both when doing an "ifup -a" and during
boot.

One small thing I've noticed is a variation in the number of "Set name-
type for VLAN subsystem. Should be visible in /proc/net/vlan/config"
messages in the ifup output depending on the different scenario, even
though the number of vlans is the same in all 4 tests. With 2 vlans, the
2 scenario's with bonding generate 1 message, the ones without bonding
generate 4. It doesn't hurt, just something I noticed. Please check the
attached log for more details on my 4 tests.

** Attachment added: "Test output for 4 different scenario's"
   
https://bugs.launchpad.net/ubuntu/+source/vlan/+bug/1701023/+attachment/5124886/+files/vlan-tests.txt

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ifupdown in Ubuntu.
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:
  New
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/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1701023] Re: (on trusty) version 1.9-3ubuntu10.4 regression blocking boot completion

2018-04-21 Thread Bug Watch Updater
** Changed in: vlan (Debian)
   Status: Unknown => New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ifupdown in Ubuntu.
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:
  New
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/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1701023] Re: (on trusty) version 1.9-3ubuntu10.4 regression blocking boot completion

2018-04-20 Thread Bug Watch Updater
** Changed in: ifupdown (Debian)
   Status: Unknown => New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ifupdown in Ubuntu.
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:
  New
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/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1701023] Re: (on trusty) version 1.9-3ubuntu10.4 regression blocking boot completion

2018-04-20 Thread Dan Streetman
Test pkgs for both ifupdown and vlan available in this ppa:
https://launchpad.net/~ddstreet/+archive/ubuntu/lp1701023

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ifupdown in Ubuntu.
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/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1701023] Re: (on trusty) version 1.9-3ubuntu10.4 regression blocking boot completion

2018-04-20 Thread Dan Streetman
** 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 Ubuntu
Touch seeded packages, which is subscribed to ifupdown in Ubuntu.
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/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1701023] Re: (on trusty) version 1.9-3ubuntu10.4 regression blocking boot completion

2018-04-20 Thread Dan Streetman
** 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 Ubuntu
Touch seeded packages, which is subscribed to ifupdown in Ubuntu.
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/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp