Bug 104279 - Bond adapters start in wrong order after up2date
Summary: Bond adapters start in wrong order after up2date
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: initscripts
Version: 3.0
Hardware: i686
OS: Linux
high
high
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact: Brock Organ
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-09-11 22:47 UTC by Kevin J. Slonka
Modified: 2014-03-17 02:38 UTC (History)
1 user (show)

Fixed In Version: 7.31.4.EL-1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2003-09-17 23:39:50 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Kevin J. Slonka 2003-09-11 22:47:33 UTC
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,
Kevin

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)

initscripts-7.31.1.EL-1

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 22:52:20 UTC
This *was* fixed in 7.31-1.EL; it was broken in 7.3.1.0-EL. 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
/etc/sysconfig/network-scripts/ifcfg-*?

Comment 2 Kevin J. Slonka 2003-09-11 23:09:59 UTC
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-12 01:30:06 UTC
What changes did you make, exactly?

Comment 4 Kevin J. Slonka 2003-09-17 21:02:45 UTC
interfaces="bond0 eth0 eth1" before start loop
interfaces="eth1 eth0 bond0" before stop loop

Comment 5 Bill Nottingham 2003-09-17 21:06:00 UTC
So, you just hardcoded the order? Hm.

Do you have 'TYPE=Bonding' set in ifcfg-bond0?

Comment 6 Kevin J. Slonka 2003-09-17 21:30:06 UTC
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 21:33:13 UTC
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 21:33:52 UTC
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 21:51:17 UTC
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 21:54:26 UTC
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 22:07:31 UTC
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 22:10:59 UTC
OK, just to clarify:

- what does:

rpm -q initscripts
rpm -V initscripts

say?

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 22:18:38 UTC
[root@firenas-1 ~]# rpm -q initscripts
initscripts-7.31.4.EL-1
[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.
-Kevin

Comment 14 Bill Nottingham 2003-09-17 23:39:50 UTC
No problem. Closing as fixed.


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