Description of problem: The naming of the wireless network interface (normally eth1) is unpredictable. In previous releases, the interface would be named either eth1 or devxxxxxx (x=numbers). It seems that problem has been fixed (bugzilla #188955). However, on my system a new problem has developed. The deviced is not intermittently named __tmpxxxxxxxxxx (x=numbers). When the deviced is named __tmpxxxxxxxxxx, NetworkManager is unable to start the device: Oct 1 01:23:15 localhost NetworkManager: <information> DHCP daemon state is now 12 (successfully started) for interface __tmp1804289383 Oct 1 01:23:15 localhost NetworkManager: <information> DHCP daemon state is now 1 (starting) for interface __tmp1804289383 Oct 1 01:23:15 localhost dhclient: Bind socket to interface: No such device When the device is properly named eth1, the network will be activated normally. Version-Release number of selected component (if applicable): udev-095-10 initscripts-8.43-1 NetworkManager-0.6.4-5.fc6 How reproducible: Sometimes. Seems to happen more frequently after a "reboot" command is issued. Steps to Reproduce: 1. Boot system 2. Observe interface name by /sbin/ifconfig 3. Actual results: If device is named __tmpxxxxxxxxxx, NetworkManager will not be able to start the device. Expected results: A predictable interface name and a working NetworkManager. Additional info: If NetworkManager is simply not able to work with this name, it's probably a bug in NetworkManager as well, however, I suspect deeper underlying problems related to the interface naming.
Can you attach your /etc/sysconfig/network-scripts/ifcfg-* files?
Created attachment 137555 [details] ifcfg-eth0
Created attachment 137556 [details] ifcfg-lo
There is no ifcfg-eth1 file.
You need an ifcfg-ethX file for each interface, with the proper HWADDR added - otherwise if the modules are loaded in reverse order, there's no way to know what to name the one that's occupying eth0 when it shouldn't.
Bill, I guess I'd like some clarification on two points: 1) eth0 is always eth0. eth1 is sometimes eth1 and sometimes __tmpxxxxxxxxxx. There is nothing occupying eth1, it just doesn't get named properly. This would imply that there is a reason other than the name being already used for it not getting renamed. However, you are right that creating the ifcfg-eth1 file fixes this problem. 2) Shouldn't /some component/ take care of creating the ifcfg-eth1 automatically since it seems to be integral to having the (wireless) system work correctly? If it requires a RFE, let me know what component to file against.
1) drivers are loaded and initialized in parallel. So what happens is that your eth1 is loaded as eth0 and vice versa. Your eth1 is then renamed to __tmpXXXXXXX so that eth0 can be named properly. Without a config file, __tmpXXXXX isn't renamed to eth1. 2) kudzu on initial device add should write the config file and rename it from __tmpXXXXX. This code was just added recently, though. I suspect this code might have issues with wireless adapters where the first configuration of the device doesn't actually create a ethX device due to no firmware being present.
Thanks for the explanation. I'll follow up on #2 as time permits.