http://bugzilla.novell.com/show_bug.cgi?id=594224
http://bugzilla.novell.com/show_bug.cgi?id=594224#c5
Marius Tomaschewski
30 seconds is an eternity ;-)
No, it isn't. This is a minimal timeout already required for systems that require network connection in further scripts (e.g. nfs/smbfs filesystems). Further, it waits in the background, because desktop is started earlier.
The network script needs to deal with this fourth case: - there is no physical _interface_ by that name, such as when the NIC was replaced by a new one (like, swapping mainboard and thus the onboard LAN chip MAC). Because udev renamed this new NIC to eth1, rcnetwork will wait the entire 30 secs for an eth0 that will never appear.
This is not bug: WONTFIX or not optimal default setup in a corner case of a vanished hardware (wrong config in case of e.g. PCMCIA/USB/...). Note, that some NICs need time to initialize (e.g. bnx2 driver; a lot of Dell, ... hardware is using it) and lowering the timeouts, would break scripts that require network. So even in the above scenario of a replaced mainboard, 30 secs wait time is fine. The scripts will not wait when you set STARTMODE=hotplug or wait much shorter in case of STARTMODE=ifplugd (link/cable-connect detection). Please configure accordingly. Stephan, you seem to be the bug owner for LiveCD... In LiveCD case it IMO makes sense to use one of the above start modi instead of "auto" / "onboot". Except the LiveCDs are using NetworkManager anyway -- in this case it is IMO already covered by fate#307610. Should I reassign to you or close as WONTFIX/INVALID? -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.