Description of problem: System has three network interfaces: 02:03.0 Ethernet controller: Intel Corporation 82545EM Gigabit Ethernet Controller (Copper) (rev 01) 03:01.0 Ethernet controller: Intel Corporation 82545GM Gigabit Ethernet Controller (rev 04) 04:05.0 Ethernet controller: Intel Corporation 82557/8/9/0/1 Ethernet Pro 100 (rev 10) # cat /etc/udev/rules.d/70-persistent-net.rules # This file was automatically generated by the /lib/udev/write_net_rules # program run by the persistent-net-generator.rules rules file. # # You can modify it, as long as you keep each rule on a single line. # PCI device 0x8086:0x100f (e1000) SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:30:48:27:ef:5c", NAME="eth0" # PCI device 0x8086:0x1026 (e1000) SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:04:23:b9:af:46", NAME="eth1" # PCI device 0x8086:0x1229 (e100) SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:30:48:27:ef:5d", NAME="eth2" Boot error message is something like: cannot rename interface: _rename: file exists. I'm left with: # ifconfig -a | grep HW _rename Link encap:Ethernet HWaddr 00:30:48:27:EF:5D eth0 Link encap:Ethernet HWaddr 00:30:48:27:EF:5C eth2 Link encap:Ethernet HWaddr 00:04:23:B9:AF:46 Version-Release number of selected component (if applicable): udev-145-14.fc12.i686
Ended up removing 70-persistent-net.rules. Seems to have cleared up the problem and it was not re-created. This system has been yum-upgraded since about F9, so I don't know if this was just legacy cruft or what.
The same effect on freshly installed F12 x86_64, but does not show on every boot. After reboot everything goes ok til the next time.... Hardware: (MAC addresses changed) 01:05.0 Ethernet controller: Marvell Technology Group Ltd. 88E8001 Gigabit Ethernet Controller (rev 14) 03:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8052 PCI-E ASF Gigabit Ethernet Controller (rev 21) 70-persistent-net.rules file: (MAC addresses changed by me) # PCI device 0x11ab:0x4320 (skge) (custom name provided by external tool) SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="xx:xx:xx:xx:xx:5b", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0" # PCI device 0x11ab:0x4360 (sky2) (custom name provided by external tool) SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="xx:xx:xx:xx:xx:5a", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1" Error boot message: ( Polish locale is set so polish message beggining ) Uruchamianie udev: udevd-work[509]: error changing netif name eth0 to _rename: File exists Version-RElease: udev-145-14.fc12.x86_64
Ah, indeed, bitten by it on my next kernel install. I made the mistake last time of running with udev in debug mode - which made the machine completely unbootable. What can I do to track this down?
I am having the same problem on a fresh fedora 12 x86_64 install. I am installing on an IBM HS22, and the network interfaces randomly reassign to _rename upon rebooting. But the real disturbance is that when I run ethtool on the interfaces they return that no link is present. I tried kernel updates from updates testing and rawhide, as well as updating the udev system to the latest found on koji, but with no change.
You can force the order in which modules are loaded into the kernel to probe ethernet cards. What you do is edit /lib/modules/`uname -r`/modules.dep and make the first ethernet driver a dependency of the second one, and so on. While there is actually no real dependency, it can alter the timing such that they always enumerate in a known order. This prevents udev having to perform the rename function as long as the 70-persistent-net.rules file is already in the order you desire. Your mileage may vary.
OK, I seem to have (what I believe is) a more viable workaround. I diddn't like editing a file in /lib/modules like that, to I did preety much the same thing is /etc land. First make sure that you are not loading the network modules in the regular kernel sequence by blacklisting them, just add the modules in question to the /etc/modprobe.d/blacklist.conf file Then manually load the modules in the sysconfig modules hook which loads right after udev is started in the rc.sysinit. make the file: /etc/sysconfig/modules/post-net.modules and, line delimited, modprobe the modules in a specific order, aka modprobe bnx2 modprobe bnx2x Then make the file executable. Before rebooting delete the 70-persistent-net.rules file, it will get regenerated properly for you. This is a lousy work around, and this is a serious bug, please fix!
I have 5 ethernet interfaces (one builtin, 4 cards) of 3 different manufacturers and chipsets in my system. I was able to make things consistently (or at least, I think consistently) by making a file called /etc/modprobe.d/force-ether.conf with these contents: install 8139too /sbin/modprobe via_rhine; /bin/sleep 2; /sbin/modprobe --ignore-install 8139too install skge /sbin/modprobe 8139too; /bin/sleep 2; /sbin/modprobe --ignore-install skge This creates dependencies that force the modules to be loaded in the order I want. And to clarify, I wanted them in this order: via_rhine (the motherboard's built in ethernet port) eth0 8139too (3 100Base-T cards) eth1->eth3 skge (my one 1000BaseT card) eth4 Next I had to edit /etc/udev/rules.d/70-persistent-net.rules to also map the appropriate MAC addresses to the appropriate eth* names. This was partly so that when my three cards using the 8139too drivers loaded they ended up with the appropriate numbers.
udev-145-16.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/udev-145-16.fc12
Is this fixed in F13 alpha?
(In reply to comment #9) > Is this fixed in F13 alpha? yes
udev-145-19.fc12 has been pushed to the Fedora 12 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update udev'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/udev-145-19.fc12
udev-145-19.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.