Bug 544357 - udev fails to rename network interface - _rename file exists
udev fails to rename network interface - _rename file exists
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: udev (Show other bugs)
12
All Linux
low Severity medium
: ---
: ---
Assigned To: Harald Hoyer
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-12-04 12:33 EST by Orion Poplawski
Modified: 2010-03-25 18:35 EDT (History)
9 users (show)

See Also:
Fixed In Version: udev-145-19.fc12
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-03-25 18:35:43 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Orion Poplawski 2009-12-04 12:33:54 EST
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
Comment 1 Orion Poplawski 2009-12-05 12:44:43 EST
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.
Comment 2 Marcin 2009-12-07 04:12:14 EST
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
Comment 3 Orion Poplawski 2009-12-15 14:00:44 EST
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?
Comment 4 Thomas S Hatch 2009-12-18 16:59:09 EST
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.
Comment 5 Kelvin J. Hill 2009-12-20 05:30:08 EST
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.
Comment 6 Thomas S Hatch 2009-12-21 18:15:13 EST
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!
Comment 7 Eric Hopper 2010-03-01 20:34:40 EST
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.
Comment 8 Fedora Update System 2010-03-19 07:13:46 EDT
udev-145-16.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/udev-145-16.fc12
Comment 9 Jonathan Kamens 2010-03-22 10:50:57 EDT
Is this fixed in F13 alpha?
Comment 10 Harald Hoyer 2010-03-22 10:56:18 EDT
(In reply to comment #9)
> Is this fixed in F13 alpha?    

yes
Comment 11 Fedora Update System 2010-03-23 19:39:21 EDT
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
Comment 12 Fedora Update System 2010-03-25 18:34:45 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.