Bug 874030

Summary:	Bond mode changing through ifcfg changes has no effect.
Product:	Red Hat Enterprise Linux 6	Reporter:	Antoni Segura Puimedon <asegurap>
Component:	initscripts	Assignee:	Lukáš Nykrýn <lnykryn>
Status:	CLOSED ERRATA	QA Contact:	qe-baseos-daemons
Severity:	high	Docs Contact:
Priority:	high
Version:	6.4	CC:	azelinka, bazulay, ddumas, jscotka, lpeer, ovasik, syeghiay
Target Milestone:	rc	Keywords:	Regression
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	initscripts-9.03.33-1	Doc Type:	Bug Fix
Doc Text:	Cause: BONDING_OPTS were not applied during if_up of master. Consequence: BONDING_OPTS were not applied. Fix: Set BONDING_OPTS in ifup for master. Result: BONDING_OPTS are applied.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-02-21 10:26:22 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Antoni Segura Puimedon 2012-11-07 10:34:49 UTC

Description of problem:
initscripts-9.03.32-1.el6 introduce a change in behavior that makes it impossible to change the bonding mode of an existing bond. In the yum changelog of the initscripts package I can see that in Oct. 8th, entry by Lukáš Nykrýn, there is one line that states:
- sets BONDING_OPTS before interface is brougth up and checks if it is not already added

I have not looked at the code, but it might be that the commit that resulted in this message is the cause of the issue.


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1. Create an ifcfg file for a bond with mode 4, e.g., ifcfg-bond10
DEVICE=bond10
BONDING_OPTS="mode=4 miimon=500"
BOOTPROTO=none
ONBOOT=yes
NM_CONTROLLED=no
2. ifup bond10
3. cat /sys/class/net/bond10/bonding/mode to see that mode is effectively 4
4. Change ifcfg-bond10
-BONDING_OPTS="mode=4 miimon=500"
+BONDING_OPTS="mode=2 miimon=500"
5. ifdown bond10
6. ifup bond10
  
Actual results:
cat /sys/class/net/bond10/bonding/mode
will show the mode to be 4.

Expected results:
cat /sys/class/net/bond10/bonding/mode
should show the mode to be 2.

Additional info:

Comment 3 Lukáš Nykrýn 2012-11-07 13:08:10 UTC

Can you please try following patch?


diff --git a/sysconfig/network-scripts/ifup-eth b/sysconfig/network-scripts/ifup-eth
index 5ef3055..7dc9fc6 100755
--- a/sysconfig/network-scripts/ifup-eth
+++ b/sysconfig/network-scripts/ifup-eth
@@ -120,6 +120,7 @@ fi
 if [ "$ISALIAS" = no ] && is_bonding_device ${DEVICE} ; then
     /sbin/ip link set dev ${DEVICE} up
     [ -n "${LINKDELAY}" ] && /bin/sleep ${LINKDELAY}
+    install_bonding_driver ${DEVICE}
     for device in $(LANG=C egrep -l "^[[:space:]]*MASTER=\"?${DEVICE}\"?[[:space:]]*$" /etc/sysconfig/network-scripts/ifcfg-*) ; do
            is_ignored_file "$device" && continue
            /sbin/ifup ${device##*/}

Comment 4 Antoni Segura Puimedon 2012-11-07 13:34:02 UTC

Unfortunately that does not fix it.

Comment 5 Antoni Segura Puimedon 2012-11-07 14:10:11 UTC

Maybe it's nonsense, but if I apply the patch proposed in comment #3 and modify in network-functions method install_bonding_driver to remove the following line:

ethtool -i $1 2>/dev/null | grep -q "driver: bonding" && return 0

Then it works.

This line, in previous versions was in the context of a method that was only creating the bond by echoing +bond to bonding masters, but now it also has the responsibility of setting the options. Since, as far as I can see, the only use it had was to avoid doing the bond creation, but now there is already the following:

if ! grep -sq "$1" /sys/class/net/bonding_masters; then
       echo "+$1" > /sys/class/net/bonding_masters 2>/dev/null
fi

That wasn't there before. I propose to drop the ethtool line.

Comment 12 errata-xmlrpc 2013-02-21 10:26:22 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-0518.html