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): initscripts-6.47.6-1 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.
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 continue fi - 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: ifcfg-bond0: DEVICE=bond0 IPADDR=192.168.0.25 NETMASK=255.255.255.0 BOOTPROTO=none ONBOOT=yes ifcfg-eth2: DEVICE=eth2 MASTER=bond0 SLAVE=yes BOOTPROTO=none ONBOOT=yes ifcfg-eth4: DEVICE=eth4 MASTER=bond0 SLAVE=yes BOOTPROTO=none ONBOOT=yes 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 package.
using kernel-smp-2.4.9-e.34
What happens if you add 'TYPE=Bonding' to your master device file?
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.
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.
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.
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.
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. http://rhn.redhat.com/errata/RHBA-2004-081.html
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' ! 10x, Vitaly Karasik, RHCE