Description of problem: initscripts ignore ONBOOT=no at system boot, when further network specific variables are defined. Version-Release number of selected component (if applicable): initscripts-7.93.11.EL-1 How reproducible: Everytime, see below. Steps to Reproduce: 1. /etc/sysconfig/network-scripts/ifcfg-eth0 should contain: --- snipp --- DEVICE=eth0 BOOTPROTO=static BROADCAST=192.168.31.255 HWADDR=00:00:1A:19:65:C6 IPADDR=192.168.24.194 NETMASK=255.255.248.0 NETWORK=192.168.24.0 ONBOOT=no TYPE=Ethernet --- snapp --- 2. /etc/sysconfig/network-scripts/ifcfg-eth1 should contain: --- snipp --- DEVICE=eth1 BOOTPROTO=static HWADDR=00:00:1A:19:65:C5 TYPE=Ethernet ONBOOT=yes IPADDR=10.208.225.47 NETMASK=255.255.225.0 NETWORK=10.208.225.0 BROADCAST=10.208.225.255 GATEWAY=10.208.225.3 --- snapp --- 3. Do a "service network restart" and review the result using "ip addr show"; everything is okay, eth1 is set up. 4. Reboot the system and review it again, eth0 _and_ eth1 are set up (and this is simply wrong)! 5. Do a further "service network restart" and review again - everything okay, as expected. 6. Replace the content of /etc/sysconfig/network-scripts/ifcfg-eth0 with (same as at point 1 with some comments): --- snipp --- DEVICE=eth0 BOOTPROTO=static #BROADCAST=192.168.31.255 HWADDR=00:00:1A:19:65:C6 #IPADDR=192.168.24.194 #NETMASK=255.255.248.0 #NETWORK=192.168.24.0 ONBOOT=no TYPE=Ethernet --- snapp --- 7. Reboot the system again and see, that everything is as expected (eth1 up). 8. Ask the question, why ONBOOT=no seems to be completely ignored, if network specific values are set. Actual results: initscripts ignore ONBOOT=no at system boot, when further network specific variables are defined. Expected results: The initscripts shouldn't ignore ONBOOT=no, even if the configuration files are set up like (1) and (2). Could we please get a working update for our customers and us? Additional info: This problem maybe also applies to Fedora Core Development.
What sorts of devices are these?
device: eth0 driver: tg3 desc: "Broadcom Corporation NetXtreme BCM5704 Gigabit Ethernet" network.hwaddr: 00:00:1A:19:65:C6 vendorId: 14e4 deviceId: 1648 subVendorId: 1022 subDeviceId: 36c0 device: eth1 driver: tg3 desc: "Broadcom Corporation NetXtreme BCM5704 Gigabit Ethernet" network.hwaddr: 00:00:1A:19:65:C5 vendorId: 14e4 deviceId: 1648 subVendorId: 1022 subDeviceId: 36c0
Before any interfaces are brought up, if you load the module, is ...:C6 eth1, and ...:C5 eth0?
The system is a Red Hat Enterprise Linux 4 default installation. From /etc/modprobe.conf: alias eth0 tg3 alias eth1 tg3 [...]
Yes, I'm just curious if you turn off hotplug, bring down the network, unload the module, and reload it, if the interfaces are reversed.
Bill for comment #3: eth0 is ...:C6 and eth1 is ...:C5 further on and they don't switch. BTW, tell me what you like to see for "turn off hotplug", maybe I made something wrong. But testing this I got another way to reproduce my problem, maybe this helps you: 1. /etc/sysconfig/network-scripts/ifcfg-eth0 should contain: --- snipp --- DEVICE=eth0 BOOTPROTO=static BROADCAST=192.168.31.255 HWADDR=00:00:1A:19:65:C6 IPADDR=192.168.24.194 NETMASK=255.255.248.0 NETWORK=192.168.24.0 ONBOOT=no TYPE=Ethernet --- snapp --- 2. /etc/sysconfig/network-scripts/ifcfg-eth1 should contain: --- snipp --- DEVICE=eth1 BOOTPROTO=static HWADDR=00:00:1A:19:65:C5 TYPE=Ethernet ONBOOT=yes IPADDR=10.208.225.47 NETMASK=255.255.225.0 NETWORK=10.208.225.0 BROADCAST=10.208.225.255 GATEWAY=10.208.225.3 --- snapp --- 3. Do a "service network restart" and review the result using "ip addr show"; everything is okay, eth1 is set up. 4. Do "rmmod tg3" and after that a "modprobe tg3"; review it again, eth0 and eth1 are set up. 5. Do a further "service network restart" and review again - everything okay, as expected.
The interface being brought up on module re-load is due to hotplug. The network script disables hotplug (echo /bin/true > /proc/sys/kernel/hotplug) while it's running.
Yes, I saw the difference between enabled and disabled hotplug. But ...:C6 always was eth0 and ...:C5 was eth1 - they didn't change at any time.
I am having what I believe is the same problem, where ONBOOT=no is ignored on my eth0:x aliases. If I have ifcfg-eth0 and ifcfg-eth0:0, where ifcfg-eth0:0 has ONBOOT=no set, eth0:0 is brought up anyway at boot. This is with initscripts-7.31.18.EL-1.
That's not the same issue... aliases use ONPARENT=(yes|no).
I opened a new bug and reported it there instead. (bug 155497)
Bill: I do not have a problem with onboot, but I wanted to report what I see using the "turn off hotplug & reload module" test you described. I have two bugs open currently. Bug 155522 describes problems that appear to be related most closely to system-config-network-tui. Bug 156402 describes a weird ethernet device name, and the results of my test of the "hotplug off & reload" test. As most directly relates to the present bug, the results of the "hotplug off & reload" test were that eth0 got the first MAC and eth1 got the second MAC. Previously, eth0 got the second MAC and eth1 (misnamed, not "eth1") got the first MAC. So maybe the devices are getting misordered when hotplug is involved? I also saw misordering on another RHEL4 machine, but I was able to fix it manually (editing the relevant files).
Created attachment 114210 [details] patch for this issue Try this. What I believe is happening is that the fix for token-ring (#90602, #127984) causes link addresses to be found for more interface types. When the sit0 interface initializes, it triggers a hotplug event, where it finds a hwaddr of '0'; since that matches the beginning of the hwaddr for one of your ethernet devices, that is brought up.
Thank you Bill, this patch works for us. Is it now possible to get an official update of initscripts (maybe together with other fixes) or is RHEL4 U1 coming very soon?
This is currently scheduled for U2.
Fixed in 7.31.24.EL-1 for RHEL 3.
Fixed in 7.93.14.EL-1 for RHEL-4.
*** Bug 163073 has been marked as a duplicate of this bug. ***
An advisory 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-2005-606.html
An advisory 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-2005-607.html
This type of behaviour still exists when using aliased interfaces: http://bugs.centos.org/view.php?id=2363 Fix: --- /etc/sysconfig/network-scripts/ifup-aliases.bug 2007-09-27 11:29:40.000000000 +0200 +++ /etc/sysconfig/network-scripts/ifup-aliases 2007-09-27 11:30:23.000000000 +0200 @@ -321,6 +321,7 @@ for FILE in ifcfg-${parent_device}:* ; d is_ignored_file "$FILE" && continue ini_env; . $FILE; + [ "${ONBOOT}" = "no" -o "${ONBOOT}" = "NO" ] && continue [ -z "$DEVICE" ] && DEVICE=${FILE##ifcfg-} [ "$ONPARENT" != "no" -a "$ONPARENT" != "NO" ] && new_interface; unset DEVICE