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=<name> IF_VLAN_RAW_DEVICE=<raw device name>; /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

  
  <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

-- 
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

Reply via email to