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
