I've been away from Linux for a few years, mainly due to work, and and am now coming back. I've run into a really bizarre issue with udev 208 as implemented in Linux From Scratch 7.5. I built the LFS system from a Debian 7.2?? host I made in VMWare workstation 10.

@7.2.1 in the LFS book asks you to look at /etc/udev/rules.d/70-persistent-net.rules. The note says they file may not be created in a virtual environment because it randomizes MAC addresses. This is absolutely true of my VMWare Workstation 10. It then explains to go on to the next section if that happens.

I did exactly that, created the eth0 profile for a static address. My first kernel build was missing the driver and I sorted that out. During the first boot with the driver...

Adding IPv4 address xxx to the eth0 interface... Cannot find device "eth0" [FAIL]

I checked dmesg and the device was initially set to eth0 and then renamed by udev to enoxxxx.

So, I started looking for guides and found several. I read them, discarded the older ones and started working on a rule. I checked dmesg and noted it was renaming the devices to enoXXXXXX. But, as noted above this won't persist across clones due to the MAC changing. So I perused /sys/class/net/enoXXX/device and found a unique value that would survive cloning, I picked up the ENV name from udevadm. It seems that udev pulls some CIMv2 (Component Information Model) information that tracks back to VMWare's workstation configuration file. /sys/class/net/<udevAdapterName>/device/label == VMWare's config file ID ethernetXX.

I created /etc/udev/rules.d/79-custom-net-config.rules:

ACTION=="add", SUBSYSTEM=="net", ENV{ID_NET_LABEL_ONBOARD}=="Ethernet0", NAME="eth0"

Note that "Ethernet0" was capitalized in the label file of sysfs. I also checked this rule with udevadm test and it parsed without error.

I rebooted and initd still can't find eth0. So, I looked a little further and found this: http://unix.stackexchange.com/questi...work-interface

That must be it, it's not parsing the custom rule because the default was never created. I issues a touch /etc/udev/rules.d/80-net-name-slot.rules and rebooted.

Voila! eth0 comes up. It's fixed, or so I thought... Here's where things get weird. I checked dmesg and it's not being renamed from enoxxx back to eth0, it's never renamed from the initial eth0 at all. So, I renamed my custom rule and rebooted. It still comes up eth0. Finally, I renamed the 80-net-name-slot.rules and it goes back to enoxxxx.

WTF? What, where, and how is causing the renaming of this device. I've read dozens of guides and spent more than 3 days pulling my hair out on this. The behavior of udev isn't making sense.

empty 80-net-name-slot.rules == no change from kernel eth0, no rules files == rename based on who knows??

What that boils down to is that I still have no control over how the device is being named. What's going to happen if I throw this on an ESX server? I don't know, and that concerns me.

Can someone please tell me what I am missing?


EDIT:
(author snip)Last bit was irrelevant to the problem

The issue doesn't exist in the current SVN of LFS, so I abandoned the 7.5 Release.

Your system probably has a second rules.d directory somewhere (check /lib/udev). The idea seems to be that the rules in /etc/udev/rules.d override the defaults in that other directory (wherever it may be on any given distribution).

(I believe the implementation of a new, complex naming standard for network interfaces belongs in the category "functionality in systemd nobody could possibly have wanted or asked for".)

Yep, I had checked those already, thanks though. I can clearly the the behavior in the dmesg log just by putting an empty net.rules file in there and, like a double-slit experiment, the name rename magically appears and disappears. I tried udevadm test or whatever piped into less so I could see the whole rules list, but apparently it doesn't do stdio.

Apparently this is some sort of bug in udev. I built a new system from the current LFS SVN, which uses udev instead, and this behavior could not be replicated. I have no idea what causes it, but if I boot both systems side by side, LFS 7.5 release does this and LFS SVN20140307 does not, so I'm chalking it up to a narrow issue in systemd-included version of udev.