Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 157252 - The activate device when computer starts (onboot) flag is not working
Summary: The activate device when computer starts (onboot) flag is not working
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: initscripts
Version: 3
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact: Brock Organ
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-05-09 20:23 UTC by Christian Lupien
Modified: 2014-03-17 02:53 UTC (History)
3 users (show)

Fixed In Version: 8.11-1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-05-10 19:12:28 UTC


Attachments (Terms of Use)
patch for this issue (deleted)
2005-05-10 16:56 UTC, Bill Nottingham
no flags Details | Diff

Description Christian Lupien 2005-05-09 20:23:10 UTC
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 16:31:00 UTC
When are you seeing the interface brought up - during rc.sysinit? Earlier? Later?

Comment 2 Bill Nottingham 2005-05-10 16:42:55 UTC
Nevermind, reproduced, currently debugging where it's coming from.

Comment 3 Bill Nottingham 2005-05-10 16:56:42 UTC
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 19:12:28 UTC
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 08:54:43 UTC
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 10:42:33 UTC
This should probably be moved to RHEL 5. (at least from #5 on) =:)

Comment 7 Bill Nottingham 2007-10-05 16:04:49 UTC
It's not a bug... it's expected behavior. The mechanism for aliases is different.

Comment 8 Leroy van Logchem 2007-10-08 22:33:15 UTC
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 22:35:22 UTC
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.