Bug 157252 - The activate device when computer starts (onboot) flag is not working
The activate device when computer starts (onboot) flag is not working
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: initscripts (Show other bugs)
3
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-05-09 16:23 EDT by Christian Lupien
Modified: 2014-03-16 22:53 EDT (History)
3 users (show)

See Also:
Fixed In Version: 8.11-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-05-10 15:12:28 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
patch for this issue (2.19 KB, patch)
2005-05-10 12:56 EDT, Bill Nottingham
no flags Details | Diff

  None (edit)
Description Christian Lupien 2005-05-09 16:23:10 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.7) Gecko/20050416 Fedora/1.0.3-1.3.1 Firefox/1.0.3

Description of problem:
UnSetting the activate device when computer starts flag (ONBOOT=no in ifcfg-eth0 file) has no effect.

The reason is that upon module loading, the hotplug net.agent gets called and it starts ifup eth1. 

My network devices are configured as modules and they are loaded automatically during boot. 

To fix this I added HOTPLUG=no in the ifc-eth0 file.
There should be a way to change this setting in system-config-network.
By default I would make this setting HOTPLUG=no (pcmcia and usb device might prefer HOTPLUG=yes...)

Version-Release number of selected component (if applicable):
system-config-network-1.3.22-1

How reproducible:
Always

Steps to Reproduce:
1.Unset the Onboot flag with system-config-network or by editing ifcfg file
2.Boot the machine
  

Actual Results:  The interface comes up (i.e. ifp eth0 gets called).

Expected Results:  Nothing should happend to the interface (no dhcp probe, no change to ifconfig output...)

Additional info:
Comment 1 Bill Nottingham 2005-05-10 12:31:00 EDT
When are you seeing the interface brought up - during rc.sysinit? Earlier? Later?
Comment 2 Bill Nottingham 2005-05-10 12:42:55 EDT
Nevermind, reproduced, currently debugging where it's coming from.
Comment 3 Bill Nottingham 2005-05-10 12:56:42 EDT
Created attachment 114209 [details]
patch for this issue

Try this. I suppose if I have to fix the same bug in four places, it means I
should generalize this somewhere. :)
Comment 4 Bill Nottingham 2005-05-10 15:12:28 EDT
Fixes for this are in hotplug-2004_09_23-6, initscripts-8.11-1.

(The fix is slightly different than the one posted, in that it's factored out
into one function just called from all four places.)
Comment 5 Leroy van Logchem 2007-10-05 04:54:43 EDT
This type behaviour still exists when using aliased interfaces:

http://bugs.centos.org/view.php?id=2363

--- /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
Comment 6 Ralph Angenendt 2007-10-05 06:42:33 EDT
This should probably be moved to RHEL 5. (at least from #5 on) =:)
Comment 7 Bill Nottingham 2007-10-05 12:04:49 EDT
It's not a bug... it's expected behavior. The mechanism for aliases is different.
Comment 8 Leroy van Logchem 2007-10-08 18:33:15 EDT
Bill, please share the insight you have on this different mechanism. Please
point me to the right directions, thanks.
Comment 9 Leroy van Logchem 2007-10-08 18:35:22 EDT
Discard comment #8, I have read Bug 320211. Thanks again!

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