Red Hat Bugzilla – Bug 104279
Bond adapters start in wrong order after up2date
Last modified: 2014-03-16 22:38:42 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.
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
Red Hat Enterprise Linux release 2.9.5AS (Taroon)
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
We expected everything to work after the up2date.
Please fix this before the next release :)
This *was* fixed in 7.31-1.EL; it was broken in 184.108.40.206-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
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.
What changes did you make, exactly?
interfaces="bond0 eth0 eth1" before start loop
interfaces="eth1 eth0 bond0" before stop loop
So, you just hardcoded the order? Hm.
Do you have 'TYPE=Bonding' set in ifcfg-bond0?
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...
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.
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.
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.
So, my question is what exact updates did you make from that shipped version;
can you unpack it and run a diff?
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.
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. :)
[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.
No problem. Closing as fixed.