bond_primary is ignored in /etc/network/interfaces

Status changed to 'Confirmed' because the bug affects multiple users.

I do not see this bug in lucid but I do see it in lucid-updates.

Deric

I would lke to correct my previous comment.
I should have said:
I do not see this bug in the previous lucid-updates (1.1.0-14ubuntu2.1) but I do see it in the current lucid-updates (1.1.0-14ubuntu2.2).

Thanks,
Deric

I've updated bug #482419 to indicate that its fix has caused this bug.

Deric

I'm currently at UDS but will have a look at that next week when I have access to a machine with that setup.

what is the precise /etc/network/interfaces file with which you can reproduce the bug?

With this statement in /etc/network/interfaces eth2 will not be the bond primary

iface bond0 inet static
  bond_slaves eth2 eth0
  bond_primary eth2
  bond_mode 1
  bond_arp_interval 2000
  bond_arp_ip_target 192.168.100.1
  address 192.168.100.50
  netmask 255.255.255.192
  gateway 192.168.100.1

I think you are trying to use a deprecated and unsupported means of bringing up the bonded interface in /etc/network/interfaces. As explained in /usr/share/doc/ifenslave-2.6/README.Debian.gz, the bonding interface needs to be brought up via stanzas for each of the physical interfaces. For example:

iface bond0 inet static
  bond_slaves none
  bond_primary eth2
  bond_mode 1
  bond_arp_interval 2000
  bond_arp_ip_target 192.168.100.1
  address 192.168.100.50
  netmask 255.255.255.192
  gateway 192.168.100.1

auto eth0
iface eth0 inet manual
  bond_primary eth2
  bond_master bond0

auto eth2
iface eth2 inet manual
  bond_primary eth2
  bond_master bond0

If the example you provided was working before as a complete /etc/network/interfaces, I think it did so by chance alone.

Also worth mentioning from that same README:
"""
Previous versions of the package supported specifying the slaves all in the
stanza for the bonding interface, using the "bond_slaves" option. However,
in such a configuration there is a race condition between bringing up the
hardware driver for the ethernet devices and attempting to bring up the
bonded interface; the bonding interface needs to be initiated from the slave
interfaces instead.
"""

As the README indicates a race condition, it could be that the bug was already there and not caused by the SRU.

Could you try updating your configuration to reflect that mentioned in the README and by Steve above and see if that fixes the issue for you?

Regarding comment #9:
Maybe there is some type of race condition that could cause the bug but I have many servers that had never shown this bug. And regardless of any possible race condition, the SRU guarantees that the bug will appear.

Regarding comment #8 and #9:
I tried the config as suggested by Steve and unfortunately it makes things worse.
bond0 doesn't even come up. Since bond0 no longer has an "auto bond0" stanza, I see nothing in if-pre-up.d/ifenslave which would bring up bond0.
Also, the README mentions:
"The master interface will be created and set up at the time the first slave
is set up, according to bond_* options in the *slave* stanza. For this
reason, in order to get consistent results, the values of all the bond_*
options should be identical in the master stanza and in all the possible
slave stanzas."
but your example does not do this (I don't think this has anything to do with the problem but I mention it just in case).

> but your example does not do this (I don't think this has anything to do with
> the problem but I mention it just in case).

Actually, that does prevent your bond_mode, bond_arp_* settings from being applied; unfortunately you do have to reproduce all the options between all the interfaces.

> Since bond0 no longer has an "auto bond0" stanza, I
> see nothing in if-pre-up.d/ifenslave which would bring up bond0.

You didn't show the 'auto bond0' in the original post, so I didn't include it in my counterexample. :) I think adding this back should be enough to fix the problem.

Actually, the original post without the "auto bond0" is from mar_rio. I'm the second person reporting the bug. I assumed that you didn't put "auto bond0" because we've been quoting the README as authoritative and it doesn't have the auto for the bond. To reproduce the original bug I simplified my interfaces file to (only IPs have been changed):

----------------------------------------------
auto lo
iface lo inet loopback

auto bond0
iface bond0 inet static
   bond_slaves eth0 eth1
   bond_mode active-backup
   bond_primary eth1
   bond_miimon 100
   bond_updelay 2000
   address 192.168.1.100
   netmask 255.255.255.0
   broadcast 192.168.1.255
----------------------------------------------

So, if I keep "auto bond0" and change my interfaces file to:
----------------------------------------------
auto lo
iface lo inet loopback

auto bond0
iface bond0 inet static
   bond_slaves none
   bond_mode active-backup
   bond_primary eth0
   bond_miimon 100
   bond_updelay 2000
   address 192.168.1.100
   netmask 255.255.255.0
   broadcast 192.168.1.255

auto eth0
iface eth0 inet manual
   bond_master bond0
   bond_mode active-backup
   bond_primary eth0
   bond_miimon 100
   bond_updelay 2000

auto eth1
iface eth1 inet manual
   bond_master bond0
   bond_mode active-backup
   bond_primary eth0
   bond_miimon 100
   bond_updelay 2000
----------------------------------------------

Then I still have no primary after a reboot. What I think is happening is the following:

If the order that the interfaces come up is bond0, eth0, eth1 then the primary will be set:
        ifup bond0:
                creates bond0 (from add_master());
                no primary is set (from setup_master() with no slaves);
                no slaves are added (from enslave_slaves() with bond_slaves = none);
                bond0 comes UP (but probably not LOWER_UP yet)
        ifup eth0:
                sees that bond0 is already created (from add_master());
                should fail to set mode but continue anyway (from setup_master() with bond0 already up);
                no primary is set (from setup_master() with no slaves);
                eth0 is added as slave (from enslave_slaves() with bond_slaves = eth0);
                eth0 comes UP and LOWER_UP which should cause bond0 to come LOWER_UP;
        ifup eth1:
                sees that bond0 is already created (from add_master());
                should fail to set mode but continue anyway (from setup_master() with bond0 already up);
                primary is set to eth0 (from setup_master() with eth0 as slave);
                eth1 is added as slave (from enslave_slaves() with bond_slaves = eth1);
                eth1 comes UP and LOWER_UP;

If the order that the interfaces come up is bond0, eth1, eth0 then the primary will not be set:
        ifup bond0:
                creates bond0 (from add_master());
                no primary is set (from setup_master() with no slaves);
                no slaves are added (from enslave_slaves() with bond_slaves = none);
                bond0 comes UP (but probably not LOWER_UP yet)
        ifup eth1:
                sees that bond0 is already created (from add_master()...

A new test ifenslave is available in my ppa: https://launchpad.net/~stgraber/+archive/experimental/+packages

The package is built for Precise but I'd expect it to work just as well on Oneiric (without the need for rebuild).

Some other users are testing it now and if I don't get negative feedback, I plan on uploading it to Precise early next week, then look at SRUing it to lucid and above.

And one more version pushed to my PPA.

This one should also fix some race conditions when using the bond interface in a bridge, with vlans or doing dhcp on it.

Marking as fixed because the bug got resolved in Precise.

We won't be SRUing the fix to Lucid as we estimate the risks of regression to be too high but we'll SRU it to 11.10.
I'm going to use bug 889423 to track the SRU.