Bug 112926 - /etc/init.d/network does not bring up slave interfaces, only bond0
Summary: /etc/init.d/network does not bring up slave interfaces, only bond0
Alias: None
Product: Red Hat Enterprise Linux 2.1
Classification: Red Hat
Component: initscripts   
(Show other bugs)
Version: 2.1
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact: Brock Organ
Depends On:
Blocks: 107566
TreeView+ depends on / blocked
Reported: 2004-01-06 00:35 UTC by Need Real Name
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-04-22 01:08:03 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:081 normal SHIPPED_LIVE Updated initscripts packages fix bug in bonding support 2004-04-21 04:00:00 UTC

Description Need Real Name 2004-01-06 00:35:43 UTC
Description of problem:
/etc/init.d/network from initscripts-6.47.6-1 does not bring up 
individual eth# interfaces (i.e. eth0, eth2, etc.), only the bond# 
(i.e bond0).  /etc/init.d/network script from initscripts-6.47.2-1.1 
and earlier works properly.

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

How reproducible:
Every time

Steps to Reproduce:
1. setup system with 2+ NIC's and initscripts-6.47.6-1
2. setup bonding with 2 NIC's
3. /etc/init.d/network start (or restart)  

Actual results:
bond0 and lo interfaces start, but none of the slave eth# interfaces 
come online.  I was able to ifup the individual interfaces manually, 
and the bond0 enslaved them properly.  If /etc/init.d/network restart 
is invoked, or system rebooted, the same problem occurs.

Expected results:
bond and all slaves should start during /etc/init.d/network 
restart/start (during boot, as well as manually).

Additional info:
I was initially using the bonding driver provided by HP, as I am 
using HP Proliant server hardware (installed HP Support Pack, which 
installs modified e100/e1000, bcm5700 and bonding drivers).  When I 
initially encountered the problem, I backported to the kernel 
provided, but still had the same problem.

Once I eliminated the drivers as the problem, I started looking at 
the scripting.  Once I backported to the /etc/init.d/network from 
initscripts-6.47.2-1.1, the slaves started normally.

Comment 1 Need Real Name 2004-01-06 00:36:47 UTC
I diffed the 2 network files and this is what I found:

--- network     Fri Sep  5 15:26:02 2003
+++ network.initscripts-6.47.2-1.1      Sat Dec 14 13:51:10 2002
@@ -51,8 +51,7 @@
            LANG=C egrep -v '(~|\.bak)$' | \
            LANG=C egrep -v 'ifcfg-cipcb[0-9]+$' | \
             LANG=C egrep 'ifcfg-[a-z0-9]+$' | \
-            sed 's/^ifcfg-//g' |
-            sed 's/[0-9]/ &/' | LANG=C sort -k 1,1 -k 2n | 
sed 's/ //'`
+            sed 's/^ifcfg-//g'`
 # See how we were called.
 case "$1" in
@@ -88,9 +87,6 @@
                if LANG=C egrep -L "^ONBOOT=\"?[Nn][Oo]\"?" ifcfg-$i 
> /dev/null ; then
-               if LANG=C egrep -L "^SLAVE=\"?[Yy][Ee][Ss]\"?" ifcfg-
$i > /dev/null ; then
-                       continue
-               fi
                # If we're in confirmation mode, get user confirmation
                [ -n "$CONFIRM" ]  && 

My ifcfg-* files:




I'm currently using initscripts-6.47.6-1 with the /etc/init.d/network 
file from initscripts-6.47.2-1.1 until an updated package is made.

On a side note, comparing the HP bonding module to the stock bonding, 
the stock module appears not to have any module parameters.  Is this 
the case?  I was unable to find a bonding.txt in the kernel-source 

Comment 2 Need Real Name 2004-01-06 00:41:02 UTC
using kernel-smp-2.4.9-e.34

Comment 3 Bill Nottingham 2004-01-06 06:05:40 UTC
What happens if you add 'TYPE=Bonding' to your master device file?

Comment 4 Need Real Name 2004-01-06 17:34:01 UTC
Thanks for the fast reply.  Adding that to my ifcfg-bond0 works.  
Looking through the /sbin/ifup script, I now see where it looks for 
$TYPE.  Looking back in the previous ifup scripts, this wasn't 
present before.

Please better document changes like this, especially when the 
behavior of something is changed mid-OS release.  I see "add bond 
devices first (#91399)" listed in the changelog for the current 
initscripts package, but nothing is clearly listed in the changlog of 
what that means, nor is there any other documentation about this 
included in this package.  One more line in the changelog would have 
helped (for me at least):

BONDING USERS: You must add 'TYPE=bonding' to your master device file 
(i.e. bond0)

It wouldn't have prevented running into the problem, as I wasn't 
researching all the updates provided by up2date, but I could have 
ID'd and corrected the problem sooner.  I'll try to make a point of 
researching all the bug reports listed in the various changelogs in 
the future, but people trusting up2date to maintain software on their 
systems may experience inexplicable problems on systems that worked 
fine before...especially considering this kind of update doesn't 
require a reboot (vs one for a kernel or glibc).  It will create a 
time-bomb of sorts, waiting for the next network restart or reboot 
for the problem to manifest.

Comment 5 Bill Nottingham 2004-01-07 19:36:18 UTC
It's a bug, the scripts should have handled it transparently.

If you remove the TYPE= line from your config file, and change
/sbin/ifup line 129 to:

if [ "${TYPE}" = "Bonding" -o "${DEVICETYPE}" = "bond" ] || ethtool ...

does it also work? That's what I'm intending to commit for future updates.

Comment 6 Need Real Name 2004-01-07 20:56:04 UTC
That works.  I'd also request adding some output about bringing up 
the slave interfaces.  It currently does this silently.  I realize it 
is the network script that currently echos what interface is being 
brought up, then forks ifup.  The previous method looped through the 
network script forking to ifup for each interface, so you had some 
indication if your bonded interfaces actually came online.  As it is 
now when viewing this from the system console, you have to ping your 
gateway or check ifconfig to confirm that the interfaces came up.

I read through bug 91399, but it isn't quite clear why TYPE was added 
to the scripting, as the previous bonding initialization appeared to 
be working properly, at least in the most typical bonding configs.

Comment 7 Bill Nottingham 2004-01-07 20:58:31 UTC
The order changing/ifup reorg was done to handle dhcp with bonded
interfaces. As for the TYPE stuff, that's an artifact of RHEL3 and
later releases; in those, you can actually rename your bond interface
to something other than 'bondX', which is why the initial check of
device type was never added.

Comment 8 John Flanagan 2004-04-22 01:08:03 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.


Comment 9 Need Real Name 2004-06-24 08:13:28 UTC
Unfortunately, I don't know, how to REOPEN bug, but this problem 
isn't resolved by initscripts from RHEL2.1 upd4.

Initscripts must work without 'TYPE=bonding' !

Vitaly Karasik, RHCE

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