Created attachment 317291 [details] Patch to fix reported problem Description of problem: The ordering in ifup-eth is wrong for bonding interfaces participating in a bridge. A bonding device can't be added to a bridge until it has at least one slaved Ethernet interface added to it. That is exactly what the script tries to do as written. The attached patch just reorders the bonding initialization to be prior to the bridge-related operations. Version-Release number of selected component (if applicable): initscripts-8.45.19 How reproducible: Every time. Steps to Reproduce: 1. Configure interfaces with pertinent as follows: ifcfg-eth0: DEVICE=eth0 SLAVE=yes MASTER=bond0 ifcfg-eth1: DEVICE=eth1 SLAVE=yes MASTER=bond0 ifcfg-bond0: DEVICE=bond0 ONBOOT=yes BONDING_OPTS='mode=1 miimon=100' BRIDGE=brbond0 ifcfg-brbond0: DEVICE=brbond0 TYPE=Bridge IPADDR=192.168.0.1 NETMASK=255.255.255.0 ONBOOT=yes 2. Reboot the system and/or do a fresh start of networking. Note that 'service networking stop' doesn't properly clean up back to a fresh-boot state, so a reboot of the system is the safest approach for testing. Actual results: # service network start Bringing up loopback interface: [ OK ] Bringing up interface bond0: can't add bond0 to bridge brbond0: Invalid argument [ OK ] Bringing up interface brbond0: [ OK ] # brctl show bridge name bridge id STP enabled interfaces brbond0 8000.000000000000 no Expected results: bond0 should be a member of the brbond0 bridge Additional info: Patch to ifup-eth attached which fixes this in my testing. It reorders the operations in ifup-eth to accommodate this scenario.
This time with a proper subject...
*** Bug 458502 has been marked as a duplicate of this bug. ***
Technically, I'd prefer a patch more like the one in bug 449950, as it keeps the hardware specific initialization (MTU, MACADDR, etc.) in order. But more or less correct.
*** Bug 193236 has been marked as a duplicate of this bug. ***
Fair enough. The other nice thing about the order in the other patch is that by placing the bridge membership section after the hardware initialization then we actually can use MTU= to set the MTU of a bridged device. My original patch had the MTU setting section after the bridge section exit 0'd from the script. I discovered the MTU problem after I opened this bug report but my fix was to remove the exit 0. I like the reordering solution much better. I am attaching a new patch in the style of the other one which should apply cleanly to the RHEL initscripts package.
Created attachment 317584 [details] New patch to fix the bridge ordering problem
*** Bug 465794 has been marked as a duplicate of this bug. ***
*** Bug 465801 has been marked as a duplicate of this bug. ***
+1, seeing this here. Patch does indeed correct the issue. Thanks for that.
*** Bug 474645 has been marked as a duplicate of this bug. ***
Please test the erratum candidate: http://people.redhat.com/harald/downloads/initscripts/initscripts-8.45.26.1.el5/
~~ Attention - RHEL 5.4 Beta Released! ~~ RHEL 5.4 Beta has been released! There should be a fix present in the Beta release that addresses this particular request. Please test and report back results here, at your earliest convenience. RHEL 5.4 General Availability release is just around the corner! If you encounter any issues while testing Beta, please describe the issues you have encountered and set the bug into NEED_INFO. If you encounter new issues, please clone this bug to open a new issue and request it be reviewed for inclusion in RHEL 5.4 or a later update, if it is not of urgent severity. Please do not flip the bug status to VERIFIED. Only post your verification results, and if available, update Verified field with the appropriate value. Questions can be posted to this bug or your customer or partner representative.
We finally had a chance to test the initscripts-8.45.26.1.el5 package and it seems to fix the problems we were experiencing. Thanks!
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 therefore 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-2009-1344.html