Bug 236897 - The primary parameter of BONDING_OPTS is not reflected.
Summary: The primary parameter of BONDING_OPTS is not reflected.
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: initscripts
Version: 5.0
Hardware: All
OS: Linux
Target Milestone: ---
: ---
Assignee: Bill Nottingham
QA Contact: Brock Organ
Keywords: Regression
: 237076 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2007-04-18 11:12 UTC by Jose Plans
Modified: 2018-10-19 23:39 UTC (History)
6 users (show)

Clone Of:
Last Closed: 2007-11-07 19:11:43 UTC

Attachments (Terms of Use)
initscripts-ifup-primary.patch (600 bytes, patch)
2007-04-18 11:12 UTC, Jose Plans
no flags Details | Diff
initscripts.patch (657 bytes, patch)
2007-04-20 18:55 UTC, Andy Gospodarek
no flags Details | Diff
modified ifup-eth patch (1.11 KB, patch)
2007-10-25 08:13 UTC, Andreas Piesk
no flags Details | Diff

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2007:0663 normal SHIPPED_LIVE initscripts and hotplug bug fix update 2007-10-30 15:11:01 UTC

Comment 1 Jose Plans 2007-04-18 11:12:48 UTC
Created attachment 152887 [details]

Comment 2 Bill Nottingham 2007-04-18 18:22:31 UTC
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?

Comment 3 RHEL Product and Program Management 2007-04-18 18:27:30 UTC
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.

Comment 4 Andy Gospodarek 2007-04-18 19:46:07 UTC
This is a kernel issue.  The following upstream patch:

commit 8a8e447b2aa1f9139d0bfc94a2a3426be9c8d40a
Author: Jay Vosburgh <fubar@us.ibm.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@us.ibm.com>
    Signed-off-by: Jeff Garzik <jeff@garzik.org>

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


Comment 5 Bill Nottingham 2007-04-19 17:02:53 UTC
*** Bug 237076 has been marked as a duplicate of this bug. ***

Comment 6 RHEL Product and Program Management 2007-04-19 17:17:47 UTC
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

Comment 7 Andy Gospodarek 2007-04-20 18:55:56 UTC
Created attachment 153203 [details]

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

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.

Comment 9 Bill Nottingham 2007-04-20 19:41:53 UTC
How does it work as a module parameter if it can only be changed after enslavement?

Comment 10 Andy Gospodarek 2007-04-20 19:55:39 UTC
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).

Comment 15 Bill Nottingham 2007-06-22 22:02:43 UTC
Building in 8.45.16.EL-1.

Comment 16 Harald Hoyer 2007-06-29 09:34:09 UTC
Test-RPMS could be downloaded from

Comment 23 Andreas Piesk 2007-10-25 08:12:08 UTC
(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

Comment 24 Andreas Piesk 2007-10-25 08:13:50 UTC
Created attachment 237151 [details]
modified ifup-eth patch

Comment 25 errata-xmlrpc 2007-11-07 19:11:43 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.