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