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