group.of.nepali.translators team mailing list archive

[Dan Streetman <dan.streetman@xxxxxxxxxxxxx>]

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

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1701023

Title:
  (on trusty) version 1.9-3ubuntu10.4 regression blocking boot
  completion

Status in ifupdown package in Ubuntu:
  Fix Released
Status in vlan package in Ubuntu:
  Fix Released
Status in ifupdown source package in Trusty:
  Fix Released
Status in vlan source package in Trusty:
  Fix Released
Status in ifupdown source package in Xenial:
  Fix Released
Status in vlan source package in Xenial:
  Fix Released
Status in ifupdown source package in Artful:
  Fix Released
Status in vlan source package in Artful:
  Fix Released
Status in ifupdown source package in Bionic:
  Fix Released
Status in vlan source package in Bionic:
  Fix Released
Status in ifupdown package in Debian:
  Fix Released
Status in vlan package in Debian:
  New

Bug description:
  [impact]

  in bug 1573272, the vlan pkg was changed to perform a full ifup inside
  its if-pre-up.d/vlan script.  This allowed correct ordering of ifup
  for a vlan and its raw-device, as previously there was a race
  condition between them (see that bug for details).

  However, this causes hangs during ifup with certain specific configs.
  The reasons are given starting in comment 13.

  The result is a regression for those using the specific ifupdown
  configs; when they try to reboot and/or ifup -a, it will hang trying
  to bring up their network, preventing boot from finishing (or hanging
  before the network is fully configured).

  [test case]

  upgrade to the latest vlan package and configure the system with an
  affected ifupdown config, then reboot.  The reboot will hang while
  trying to bring the network up.

  see the original description below for an example ifupdown config to
  reproduce this, although there are other possible configs that
  will/may trigger this regression.

  [regression potential]

  The fix for this moves the creation of the vlan(s) corresponding to a
  physical raw-device 'hotplug' event out of the udev processing path
  for the raw-device, and into an ifup post script for the raw-device
  ifup.  If this is not done correctly, then any interfaces that are
  hotplugged, and have vlans configured on them, may fail to correctly
  create/configure their vlan(s).

  This change does remove the direct call to ifup from the if-pre-up.d
  (or if-up.d) scripts, so there should not be any regression potential
  for more ifup deadlocks.

  [other info]

  this required both ifupdown and vlan to be patched.  vlan was patched
  to remove the problematic call to ifup from the vlan pre-up script,
  and add a call to create the vlan interface(s) from a new post-up
  script, as well as adding a parameter to vlan-network-interface script
  to handle the call from udev itself differently than a call from
  elsewhere (such as the if-up.d/vlan script).  this works for bootup
  and ifup/ifup -a, but fails for device hotplug because of a bug in
  ifupdown that prevents calling ifquery from an ifup script; that has
  been patched upstream already, and is the only ifupdown change needed
  here.

  
  [original description]

  When upgrading from version 1.9-3ubuntu10.1, a previously working
  machine can't successfully reboot completely.

  ifup is hanging indefinitely, with this process structure (from
  "pstree -a 1299"):

  ifup,1299 -a
    └─run-parts,1501 /etc/network/if-pre-up.d
        └─bridge,1502 /etc/network/if-pre-up.d/bridge
            └─bridge,1508 /etc/network/if-pre-up.d/bridge
                └─vlan,1511 /etc/network/if-pre-up.d/vlan
                    └─ifup,1532 eth0

  <begin content of /etc/network/interfaces>
  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
  <end content of /etc/network/interfaces>

  The underlying interface eth0.1134 is not explicitly defined, but was
  previously auto-created during "ifup -a" execution. This apparently
  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