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 :)
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-*?
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 say? 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 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
No problem. Closing as fixed.