I’ve been struggling for a while trying to get udev to maintain device names for vmxnet devices when running in a vmware virtual machine. The 75-persistent-net-generator.rules script was making rules that looked like: SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:0c:29:0b:02:d2", NAME="eth0" These seemed to be silently ignored. The vmxnet devices would just show up as eth0, eth1, and eth2. After an emerge --sync; emerge -u world last night, the vmware devices started getting IDs following the highest-numbered eth device mentioned in 70-persistent-net.rules. These rules would be added to 70-persistent-net.rules, and on the next boot the devices would move up even higher, causing all network device config settings to be ignored. I noticed that the new rules added to 70-persistent-net.rules were of the form: SUBSYSTEM=="net", DRIVERS=="?*", ATTR{address}=="00:0c:29:0b:02:d2", NAME="eth0" (ATTRS was replaced with ATTR), which just means the match is done on the specific node rather than checking all of the parents, so that's OK (in fact, it's more OK than the old way). After a lot hair-pulling, I finally found the problem. Apparently the DRIVERS key is unset at this point for the vmxnet driver. I removed that test, so that I have: SUBSYSTEM=="net", ATTR{address}=="00:0c:29:0b:02:d2", NAME="eth0" which now works. I'm sure the blame lies more on the vmxnet driver than anything, but the runaway device naming was quite annoying. Why is the DEVICES="?*" check there? Reproducible: Always Steps to Reproduce:
Which udev version is this about?
Sorry I didn't include this initially, I was a bit rushed writing the report. $ uname -a Linux vmg.szczerba.net 2.6.19-gentoo-r5 #4 SMP Sun Apr 15 19:46:30 EDT 2007 i686 Intel(R) Core(TM)2 CPU T5500 @ 1.66GHz GenuineIntel GNU/Linux $ equery l udev [ Searching for package 'udev' in all categories among: ] * installed packages [I--] [ ] sys-fs/udev-114 (0) Let me know if you need anything else.
Well, that DRIVERS=="?*" is there to stop udev from catching all kinds of virtual interfaces docked on the normal ones - like briders, vlan interfaces ... Maybe vmxnet requires special handling. Best is to cry on hotplug-ML. I can forward this issue for you, if you want.
Sure, that (forwarding to the proper list) wouldn't hurt. I guess checking the MAC address doesn't protect against getting VLANs and stuff, right? When I was debugging this I used udevcontrol to set the log level to debug, then repeatedly used modprobe/rmmod to insert and remove the module. Would those traces be useful? If I look in /sys/class/net/eth0, there is no device symlink like I get with a real device. Correspondingly, "udevinfo -a -p /sys/class/net/eth0" shows info for only one node, it never walks up to the vmxnet device. It seems this is the reason there is no DRIVER value (another system running on real hardware shows the driver, 8139too, at the second node up from eth0). I don't want to waste a lot of anyone's time on this if it turns out to just be a VMWare issue, I have a work around that does the job for me at the moment, but I'm sure someone else out there is having this issue too. Perhaps more important than the fact the the generated rule doesn't work (which has been the case for quite a while, which used to make the device stay at eth0 or whatever) is that the new ruleset seems to get to a point where it determines that the device hasn't been renamed (the NAME attribute is not set in any udev rule), so it apparently scans all the rules, finds the highest numbered eth device in any rule, and assigns the new device one higher & adds a rule for that. If that added rule does not match the next time the device is seen (as it will not for vmxnet), the process is repeated, so the device number increments on every system boot. This is not happening in a udev rule that I can find, rather it seems to be in write_net_rules (in find_next_available()). Hmmm... looking deeper into /lib/udev/write_net_rules, it looks like find_next_available is called if interface_name_taken is true, which happens when there is a rule in 70-persistent-net.rules that uses the same device name, which is always the case at least the second time the device is seen (if I don't have an eth0 rule, and I add a new device that defaults to eth0, it will use that the first time, then write_net_rules will add a rule for that device. The next time I add the device the rule will be seen and the device ID will be bumped). Maybe interface_name_taken needs to check if the detected rule uses the same MAC address or something?
Actually, now that I think about it, the old generated rule (before I updated) has # PCI device 0x1022:0x2000 (vmxnet) As a comment, which implies the device link used to be in the sysfs entry. My old udev version was sys-fs/udev-104-r13.
I ran into this problem running the same version of udev on my PlayStation3. I'm not nearly as adept at this as other people, so i can't tell you if the cause is the same as with vmware ethernet drivers... but it drove me nuts at first cause it didn't just rename the ethernet adapter, it dissapeared from the /dev/ directory completely. removing the reference to the driver fixed the problem in my situation too. -- some version info for you. localhost rules.d # equery l udev [ Searching for package 'udev' in all categories among: ] * installed packages [I--] [ ] sys-fs/udev-114 (0) localhost rules.d # uname -a Linux localhost 2.6.16-ps3 #1 SMP Sun Jun 10 16:28:08 UTC 2007 ppc64 Cell Broadband Engine, altivec supported PS3PF GNU/Linux
are there any news here? As a workaround, using udev-133 there now is a switch to stop persistent-net from creating new rules.
What is the status of this bug now? udev-141 is stable on most archs, and there had been some upstream changes to persistent-net.
