Bug 1102135

Description of problem:
There are certain HW where the BIOS is questionable and reports the same index for ethernet interfaces. In those cases udev tries to rename the interaces and it fails. In diskless systems this can cause a node which booted just fine in RHEL6 to fail to boot. 

Here are two examples:
https://bugzilla.redhat.com/show_bug.cgi?id=1086931#c13
https://bugzilla.redhat.com/show_bug.cgi?id=1093485#c21

Affected HW will look something like this.
[root@fox sys]# grep . /sys/class/net/*/device/{index,acpi_index}
/sys/class/net/eth0/device/index:1
/sys/class/net/eth1/device/index:1
grep: /sys/class/net/*/device/acpi_index: No such file or directory

When booting one of these systems diskless it will drop you into the dracut shell and you will be able to find a line like: 
[   67.741492] localhost systemd-udevd[869]: error changing net interface name eth0 to eno1: File exists
in the rdsos

A workaround for now is to add "net.ifnames=0" to the kernel command line

Version-Release number of selected component (if applicable):
systemd-207.7.el7

How reproducible:
hardware specific

Additional info:
The BIOS vendor, in this case Intel, has been contacted. However, BIOS updates are tricky to get. There is also a possibility that we are simply misinterpreting the interface's index. Either way, systemd's udev should be able to handle the failing case more gracefully allowing dracut to find its sysroot and continue.

This does make hardware/BIOS combinations that was perfectly fine under RHEL6 and likely RHEL5 unbootable without a largely undocumented workaround therefore seems very much like a regression.