I'm running Fedora 11 Preview on my laptop. I am *not* using NetworkManager: $ /sbin/chkconfig | grep -i network NetworkManager 0:off 1:off 2:off 3:off 4:off 5:off 6:off network 0:off 1:off 2:on 3:on 4:on 5:on 6:off Only the loopback is configured to be active on boot: $ grep ONBOOT /etc/sysconfig/network-scripts/ifcfg-* /etc/sysconfig/network-scripts/ifcfg-eth0:ONBOOT=no /etc/sysconfig/network-scripts/ifcfg-lo:ONBOOT=yes /etc/sysconfig/network-scripts/ifcfg-wlan0:ONBOOT=no But when I suspend my laptop, and then resume it, udev attempts to bring up the wlan0 interface: $ ps fax ... 218 ? S<s 0:00 /sbin/udevd -d 7785 ? S< 0:00 \_ /sbin/udevd -d 7795 ? S< 0:00 \_ /bin/bash /etc/sysconfig/network-scripts/ifup-eth ifcfg-wlan0 7893 ? S< 0:00 \_ /sbin/dhclient -1 -q -lf /var/lib/dhclient/dhclient-wlan0.leases -pf /var/run/dhclient-wlan0.pid wlan0 The only udev rule that mentions udev is the persistent naming rule that anaconda added: SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:11:22:33:44:55", ATTR{type}=="1", KERNEL=="wlan*", NAME="wlan0" As far as I can tell, this shouldn't happen; udev should not be attempting to bring up wlan0 on suspend from resume...
anything in /lib/udev/rules.d which could trigger that?
/lib/udev/rules.d/60-net.rules (from initscripts-8.95-1) contains: ACTION=="add", SUBSYSTEM=="net", DEVPATH=="/devices/virtual/net/lo", RUN+="/sbin/ifup $env{INTERFACE}" ACTION=="add", SUBSYSTEM=="net", PROGRAM="/lib/udev/rename_device", RESULT=="?*", ENV{INTERFACE_NAME}="$result" SUBSYSTEM=="net", RUN+="/etc/sysconfig/network-scripts/net.hotplug" ...but I don't see how that would bring up wlan0. Since from your response this doesn't seem to be a known issue, I'll put udevd in debug mode, slog through the suspend/resume output, and see if I can figure out what rule (or combination of rules) is causing this...
/etc/sysconfig/network-scripts/net.hotplug would, if the interface is deregistered and regestired again after resume. do you have scripts installed which remove the wireless drivers before suspend?
Ah, that's it, then: $ cat /etc/pm/config.d/unload_modules # # $ date; ./quirk-checker.sh # # Wed May 21 10:55:50 EDT 2008 # # Checking your system... # # WARNING: iwl3945 is usually okay for suspend - but it might be worth trying # unloading it. # # WARNING: KVM will not suspend in kernels less than 2.6.23, but should work # okay in later kernels. # # Suggestions: # # Add 'SUSPEND_MODULES="kvm_intel kvm iwl3945"' to # /etc/pm/config.d/unload_modules! # SUSPEND_MODULES="iwl3945" Now, I could see if the iwl3945 driver behaves properly if I leave it loaded across suspend/resumes. But what if it doesn't? In the general case, how do we solve the problem of a driver that needs to be unloaded before suspending, but one whose corresponding device shouldn't be activated when the driver is loaded after resume?
Add 'HOTPLUG=no' to the ifcfg file. In any case, closing this as the init scripts are behaving correctly.