Bug 113937 - bonding config breaks non-bonded interface config on boot
Summary: bonding config breaks non-bonded interface config on boot
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: initscripts (Show other bugs)
(Show other bugs)
Version: 3.0
Hardware: All Linux
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact:
: 115312 (view as bug list)
Depends On:
Blocks: 107563
TreeView+ depends on / blocked
Reported: 2004-01-20 14:30 UTC by John Leach
Modified: 2014-03-17 02:41 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-05-12 04:43:02 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2004:080 normal SHIPPED_LIVE Updated initscripts packages fix bug in bonding support 2004-05-12 04:00:00 UTC

Description John Leach 2004-01-20 14:30:04 UTC
Due to an environment variable not being cleared, ethernet bonding
configuration can prevent other non-bonded ethernet interfaces from
being activated on boot.  It depends on the order that the intfaces
are activated.

Version-Release number: initscripts-7.31.9.EL-1

How reproducible:
Assume bond0 is the master for eth0 and eth1 and that eth2 is a
separate dhcp configured interface.  The ifcfg-eth0 and ifcfg-eth1
files both contain "SLAVE=yes".
Each configured interface is configured by a loop in
/etc/init.d/network.  If the interface is a slave it is skipped.  The
trouble is, the environment variable is not cleared between each
iteration so when it gets to the dhcp interface eth2 "SLAVE" still
contains "yes" (from eth1's config) and is therefore skipped. 
Manually ifupping the interface works fine.

Workaround:  add SLAVE=no to ifcfg-eth2

Comment 1 Bill Nottingham 2004-02-10 17:00:24 UTC
*** Bug 115312 has been marked as a duplicate of this bug. ***

Comment 2 ginnie nuckles 2004-03-31 21:32:08 UTC
My config is a little different .. my bond is between eth2 and 3 .. 
but upon boot I loose eth0 and the only thing that shows active with 
ifconfig is bond0 and lo. I tried placing Slave=no on the eth0 and 1 
interfaces and including the TYPE=bonding on ifcfg-bond0 as was 
suggested in another bug hit ,, but this did not solve  this problem. 
Your solution absolutely sounded like my problem as the VERY FIRST 
time I booted the system with the bond everthing came up 
beautifully,, however ,, the second time I lost eth0 and 1,, it was 
as if the environment variable was stored. Anyhow .. I am terribly 
frustrated. It works perfectly on RH9 ,, but  I have not been able to 
configure a successful bond on EL3 without putting commands 
in /etc/rc.local..... Please help !

Comment 3 Christian Franck 2004-04-16 08:16:07 UTC
Variable unsetting is also omitted for "DEVICE" and "TYPE" in the
iteration in /etc/rc.d/init.d/network:

# bring up all other interfaces configured to come up at boot time
        for i in $interfaces; do
                eval $(LANG=C fgrep "DEVICE=" ifcfg-$i)
                eval $(LANG=C fgrep "TYPE=" ifcfg-$i)
                eval $(LANG=C fgrep "SLAVE=" ifcfg-$i)

So a mixture of xDLS, bonding and single network devices
may also fail. 

Adding an "unset <variable>" before each eval statement helped me.

I did not have to modify the network scripts 
in /etc/sysconfig/network-scripts

Comment 4 Bill Nottingham 2004-04-16 16:42:01 UTC
Christian - what vesion of the scripts are you looking at?

Comment 5 ginnie nuckles 2004-04-19 20:22:06 UTC
sorry to be such a ditz ... but is the unset like this 

unset eth0
eval $(LANG=C fgrep "DEVICE=" ifcfg-$i)
unset eth1
eval $(LANG=C fgrep "DEVICE=" ifcfg-$i

etc .. thanks 

Comment 6 John Flanagan 2004-05-12 04:43:02 UTC
An errata 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.