Bug 874030 - Bond mode changing through ifcfg changes has no effect.
Bond mode changing through ifcfg changes has no effect.
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: initscripts (Show other bugs)
6.4
Unspecified Unspecified
high Severity high
: rc
: ---
Assigned To: Lukáš Nykrýn
qe-baseos-daemons
: Regression
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-11-07 05:34 EST by Antoni Segura Puimedon
Modified: 2016-11-25 08:08 EST (History)
7 users (show)

See Also:
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 05:26:22 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Antoni Segura Puimedon 2012-11-07 05:34:49 EST
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 08:08:10 EST
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 08:34:02 EST
Unfortunately that does not fix it.
Comment 5 Antoni Segura Puimedon 2012-11-07 09:10:11 EST
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 05:26:22 EST
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

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