Description of problem: On a fully-updated RHEL 5.5 system, interfaces marked with ONBOOT=no are still started when the system is booted. How reproducible: Mark an interface as ONBOOT=no. init 6. Actual results: Interface comes up. Expected results: Interface does *not* come up. Additional info: [root@tsdns network-scripts]# cat ifcfg-eth0* # Intel Corporation 82545EM Gigabit Ethernet Controller (Copper) DEVICE=eth0 BOOTPROTO=static DHCPCLASS= HWADDR=00:50:56:A2:73:8A IPADDR=137.229.5.28 NETMASK=255.255.255.0 ONBOOT=yes # Intel Corporation 82545EM Gigabit Ethernet Controller (Copper) DEVICE=eth0:0 BOOTPROTO=static DHCPCLASS= IPADDR=137.229.5.34 NETMASK=255.255.255.0 ONBOOT=no eth0:0 still comes up on reboot.
Same problem, though my configuration is slightly different: [root@cakeclient ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth0:0 DEVICE=eth0:0 BOOTPROTO=none IPADDR=192.168.154.230 NETMASK=255.255.252.0 ONBOOT=no [root@cakeclient ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth0 DEVICE=eth0 BOOTPROTO=static BROADCAST=192.168.155.255 HWADDR=00:0C:29:04:B5:5A IPADDR=192.168.154.225 NETMASK=255.255.252.0 NETWORK=192.168.152.0 ONBOOT=yes As an aside: the option "static" doesn't exist according to the Deployment Guide for RHEL5 (page 155, apparently the options are only none, bootp and dhcp)...
Ran into this problem today too. This creates a large issue when you are working with clusters and want to put a vip on a servers and manage it through the built in network tools. A bit frustrating that it's over a year old and hasn't been addressed either.
I have a customer encountering this in a slightly different way. In this user's case, they set up two bonded interfaces. One with ONBOOT=yes and one with ONBOOT=no. After a reboot, both bonded interfaces would start, regardless of the ONBOOT=no. Current workaround is modifying the /etc/sysconfig/network-scripts/net.hotplug by modifying the ifup line: From: exec /sbin/ifup $INTERFACE To: exec /sbin/ifup $INTERFACE boot After above modifications, only the desired interface is started at boot. Seems to be reproducible on physical servers, but not VMs.
With the first few examples opened against this BZ, using ONPARENT=no instead of ONBOOT=no has the desired effect of not starting the alias interfaces when the real interface is started. In the case of interface bonding, however, the ONPARENT= has no effect and the modification to the net.hotplug script seems to be the only remedy.
My customer has the issue pointed out by Dylan, with multiple bonding interfaces. Have not confirmed yet if the proposed modification changes the behavior to what's expected.
This is not a kernel issue, reassigning to initscripts.
I think that proper solution to this is setting HOTPLUG=no in ifcfg file.
Can you please try solution mentioned in previous comment?
Confirmed. The HOTPLUG=no does have the desired effect in the ifcfg-bond<n> config file when there are multiple bonded interfaces and only one is desired to start. Customer, myself, and a few others here were all so focused on the ONBOOT. The HOTPLUG section in the Deployment guide does correctly describe this. https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/5/html-single/Deployment_Guide/index.html#s2-networkscripts-interfaces-eth0 (It may be useful to actually add a note to the ONBOOT section of these docs that says the behaviour described for ONBOOT would NOT work for the multiple bonded interface scenario and that the HOTPLUG should be used.) ONBOOT=<answer> where <answer> is one of the following: yes — This device should be activated at boot-time. no — This device should not be activated at boot-time.