Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 104279 - Bond adapters start in wrong order after up2date
Bond adapters start in wrong order after up2date
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: initscripts (Show other bugs)
i686 Linux
high Severity high
: ---
: ---
Assigned To: Bill Nottingham
Brock Organ
Depends On:
  Show dependency treegraph
Reported: 2003-09-11 18:47 EDT by Kevin J. Slonka
Modified: 2014-03-16 22:38 EDT (History)
1 user (show)

See Also:
Fixed In Version: 7.31.4.EL-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-09-17 19:39:50 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Kevin J. Slonka 2003-09-11 18:47:33 EDT
Description of problem:
After running up2date on Thursday, the rpm initscripts-7.31.1.EL-1 was installed
(05:03:51 PM EDT).  This brought up the network in the wrong order (eth0, eth1,
bond0).  Since the bond interface had not been started yet, eth0 and eth1 were
not properly enslaved, thus making the network foo.  This sucked very badly
because this computer is a headless NAS box without a video card, so network
access was the only way of access.  One of my co-workers frankensteined it with
video and was able to undo the stupid changes and make the bond interface start
first.  Hopefully this can be fixed in the next release of the initscripts so
this does not happen again.

Thank you,

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

Linux firenas-1 2.4.21-1.1931.2.423.ent #1 Fri Sep 5 14:15:24 EDT 2003 i686 i686
i386 GNU/Linux

Red Hat Enterprise Linux release 2.9.5AS (Taroon)


How reproducible:
We don't want to break this again, so we don't know.

Steps to Reproduce:
1. Install the beta OS
2. Configure bond with two eth adapters
3. Run up2date and watch as it never gets back on the network
Actual results:
No network

Expected results:
We expected everything to work after the up2date.

Additional info:
Please fix this before the next release :)
Comment 1 Bill Nottingham 2003-09-11 18:52:20 EDT
This *was* fixed in 7.31-1.EL; it was broken in Bond devices are
brought up partway, then their slaves are brought up, then the bringing up of
the bonded device is finished.

So, this isn't working for you at all. Can you attach your
Comment 2 Kevin J. Slonka 2003-09-11 19:09:59 EDT
Ok.  It is working since we made the changes.  I just double checked and saw 
that the version of initscripts I have was installed today (not last 
Thursday).  Thank you for your time.
Comment 3 Bill Nottingham 2003-09-11 21:30:06 EDT
What changes did you make, exactly?
Comment 4 Kevin J. Slonka 2003-09-17 17:02:45 EDT
interfaces="bond0 eth0 eth1" before start loop
interfaces="eth1 eth0 bond0" before stop loop
Comment 5 Bill Nottingham 2003-09-17 17:06:00 EDT
So, you just hardcoded the order? Hm.

Do you have 'TYPE=Bonding' set in ifcfg-bond0?
Comment 6 Kevin J. Slonka 2003-09-17 17:30:06 EDT
No, the type is not specified in /etc/sysconfig/network-scripts/ifcfg-bond0.  
What will the effects of this be since I have hardcoded the order?  Since this 
is a headless NAS box, I don't want to screw up the network...
Comment 7 Bill Nottingham 2003-09-17 17:33:13 EDT
Well, if you hardcoded the order, it won't affect anything. However, you
shouldn't need to hardcode the order at all, and that RPM works in testing here
without any tweaking.
Comment 8 Bill Nottingham 2003-09-17 17:33:52 EDT
TYPE=Bonding gives the initscripts a hint that it's a bonding device, as devices
don't necessarily have to be named 'bond0'; it's used to determine when a device
is  a master bonding device.
Comment 9 Kevin J. Slonka 2003-09-17 17:51:17 EDT
Well, it's not hardcoded now, because of the updates I've done since then.  I 
did, however, add the type into the bond0 script just to be on the safe side.
Comment 10 Bill Nottingham 2003-09-17 17:54:26 EDT
So, my question is what exact updates did you make from that shipped version;
can you unpack it and run a diff?
Comment 11 Kevin J. Slonka 2003-09-17 18:07:31 EDT
Well, since I first installed RedHat, I've run an up2date at least 3 times a 
week (I have once today already).  The only thing we changed by hand was what I 
sent you, we did this right after the version before initscripts7.31.1 (when 
the network failed).  After that, the up2date's didn't hurt the network anymore.
Comment 12 Bill Nottingham 2003-09-17 18:10:59 EDT
OK, just to clarify:

- what does:

rpm -q initscripts
rpm -V initscripts


If you're on the current version, and it verifies clean, and it's working for
you, we can close this out. :)
Comment 13 Kevin J. Slonka 2003-09-17 18:18:38 EDT
[root@firenas-1 ~]# rpm -q initscripts
[root@firenas-1 ~]# rpm -V initscripts
S.5....T c /etc/inittab

Everything is in proper working order now.  I placed the help request just 
incase no one noticed the error in that particular version of initscripts that 
killed bonding.  But, obviously, that was fixed in the next version.

Thank you very much for your help and assistance.
Comment 14 Bill Nottingham 2003-09-17 19:39:50 EDT
No problem. Closing as fixed.

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