http://bugzilla.novell.com/show_bug.cgi?id=911562 --- Comment #28 from Pawel Wieczorkiewicz --- (In reply to Tom Burkart from comment #27)

(In reply to Pawel Wieczorkiewicz from comment #26)

...

But before please ensure you have tried information provided in comment#4 and comment#12 of this bug with wicked 0.6.18.

Turning on nanny does "fix" the problem. But why is this required for a "static IP" setup? The reality is that in this case nanny needs to be enabled by default on systems where there is any possibility of loss of link during boot. This covers >80% of systems. To me that is a serious flaw.

Have you used LINK_READY_WAIT variable with your ifcfg config? Have you set this variable to the value smaller than value of WAIT_FOR_INTERFACES from /etc/sysconfig/network/config file? If you haven't, the standalone wicked client call will timeout after $WAIT_FOR_INTERFACES seconds waiting for the link to come up. Thus nanny needs to be used, which is a client daemon dealing with hotplug scenarios like yours. See this excerpt from ifcfg(5): LINK_READY_WAIT This variable configures how long to wait for the link detection (by the kernel / network card driver) in seconds. Default is 0, causing to not wait at all if link is not required or wait infinitely when link is required, so nanny can continue with the setup when the cable gets connected to the network card after a while. Otherwise wicked will wait until the specified number of seconds and continue with further steps if link is not required or fail and stop further steps if nanny is not used (see use-nanny in wicked-config(5)). Note, that an ifup call has it's own, independent timeout, which is limiting the maximal time ifup waits before it has to report (see global network/config WAIT_FOR_INTERFACES variable). -- You are receiving this mail because: You are on the CC list for the bug.