Control: tag -1 moreinfo I don't see any changes in the kernel bonding driver, or any relevant changes to kernel networking.
On Fri, 2017-05-26 at 00:31 -0400, Jason Cohen wrote: > ** Network interface configuration: [...] > auto bond0 > iface bond0 inet static > address 192.168.1.200 > netmask 255.255.255.0 > network 192.168.1.0 > gateway 192.168.1.1 > iface bond0 inet6 static > address 2001:470:8:1141::2 > netmask 64 > gateway 2001:470:8:1141::1 > slaves eth0 eth1 > bond_mode 802.3ad > bond_miimon 100 > bond_downdelay 200 > bond_updelay 200 > mtu 9000 [...] I'm pretty sure this configuration never worked, and that you just found that out by rebooting after the upgrade. The problem is that ifupdown treats each 'iface' statement as introducing a separate interface configuration, so the above is parsed as: iface bond0 inet static address 192.168.1.200 netmask 255.255.255.0 network 192.168.1.0 gateway 192.168.1.1 iface bond0 inet6 static address 2001:470:8:1141::2 netma sk 64 gateway 2001:470:8:1141::1 slaves eth0 eth1 bond_mode 802.3ad bond_miimon 100 bond_downdelay 200 bond_updelay 200 mtu 9000 I think it will first try to apply the first interface configuration. There are no bonding parameters so the code to create a bonding interface (and load the bonding module) doesn't run. As there is no such interface, the IPv4 configuration can't be applied either. I don't know whether ifupdown tries to process the second interface configuration after this failure, but I would guess not. If you move all the bonding and mtu parameters into the first interface configuration, does the bonding interface start working again? Ben. -- Ben Hutchings The generation of random numbers is too important to be left to chance. - Robert Coveyou
signature.asc
Description: This is a digitally signed message part