Bug 236897

Created attachment 152887 [details]
initscripts-ifup-primary.patch

Moving to 5.1, adding devel ack. Configurations that could be accomplished in
RHEL4 now require manual intervention, ergo is likely categorized as a
regression. Note that configurations will still need modifed for this.

If setting of primary does not work until devices are enslaved, how does it work
as a module parameter?

This bugzilla has Keywords: Regression.  

Since no regressions are allowed between releases, 
it is also being proposed as a blocker for this release.  

Please resolve ASAP.

This is a kernel issue.  The following upstream patch:

commit 8a8e447b2aa1f9139d0bfc94a2a3426be9c8d40a
Author: Jay Vosburgh <fubar.com>
Date:   Fri Sep 22 21:56:15 2006 -0700

    [PATCH] bonding: Fix primary selection error at enslavement time

        At enslavement time, the primary slave might not be activated if
    there is already an active slave and the new slave is the primary.
    Replaced complicated logic with a call to bond_select_active_slave(),
    which does the right thing.

        Fixes http://bugzilla.kernel.org/show_bug.cgi?id=6378

    Signed-off-by: Jay Vosburgh <fubar.com>
    Signed-off-by: Jeff Garzik <jeff>

resolves this issue.  I already have this patch in my test kernels that will
take care of this.  Please test them and verify.  Thanks!

http://people.redhat.com/agospoda/#rhel5

*** Bug 237076 has been marked as a duplicate of this bug. ***

This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

Created attachment 153203 [details]
initscripts.patch

Crap. crap, crap.  Looks like this is an initscripts problem after all.  The
kernel patch should help out, but maybe not in the scenario the customer
describes.  Basically the primary field needs to be populated after
enslavement.

Jose, did you test that patch?	I didn't think the variable ${PRIMARY} would be
set?   Here's another patch to try that should work.

How does it work as a module parameter if it can only be changed after enslavement?

The parameter expects a value that is a netdevice, so it won't consider it valid
until the device is enslaved as a member of the bond.

I suppose we could change the kernel's bonding code to allow this, but the code
as it stands right now makes a reasonable amount of sense (even if it is a PITA
for initscripts).

Building in 8.45.16.EL-1.

Test-RPMS could be downloaded from
http://people.redhat.com/harald/downloads/initscripts/initscripts-8.45.16.EL-1/

(In reply to comment #15)
> 
> I suppose we could change the kernel's bonding code to allow this, but the code
> as it stands right now makes a reasonable amount of sense (even if it is a PITA
> for initscripts).

seems to work, but i would change the patch a little bit. in the loop i would
set all parameters except primary. the value for primary is stored in a variable
instead and set after the device is up. see patch
initscripts-bondingprimaryslaves.patch.

Created attachment 237151 [details]
modified ifup-eth patch

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2007-0663.html