Hi,
after switching from SLES 10 to 11 I saw that I couldn't use
FORCE_PERSISTENT_NAMES=no anymore.
How can we prevent persistent network device names? There are some
problems with this:
1) If 70-persistent-net.rules is removed, it is recreated with totally
strange values. E.g. I have file with
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:1b:21:0e:3e:68", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
Now I remove the file (we have a diskless environment where those files
can get removed due to a local disk change) and call "udevadm trigger".
The new 70-persistent-net.rules now contains:
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:1b:21:0e:3e:68", ATTR{type}=="1", KERNEL=="eth*", NAME="eth_s6_0"
Different on every host, sometimes eth_s1_0 etc.
So on the next reboot I have no network, because our config files
are always ifcfg-eth0 (and additionally sometimes ifcfg-eth1).
2) When a mainboard is exchanged, the MACs change. But on the next boot
I still want the new NICs to be eth0 and eth1, in the order
in which they are recognized by the bios.
It doesn't make sense if those new cards become eth2 and eth3
because the old, non-existing NICs are listed in the rules file with
their MACs.
So how can we prevent this? Why was the FORCE_PERSISTENT_NAMES option removed?
Persistent device names might be nice for laptops with wlan or usb network devices.
For our site with 120 PCs and Servers with it's bad because I can't care about 120
rules file to make sure they all are always ok before the next boot. I just want to
get rid of the feature :-)
cu,
Frank
--
Dipl.-Inform. Frank Steiner Web: http://www.bio.ifi.lmu.de/~steiner/
Lehrstuhl f. Bioinformatik Mail: http://www.bio.ifi.lmu.de/~steiner/m/
LMU, Amalienstr. 17 Phone: +49 89 2180-4049
80333 Muenchen, Germany Fax: +49 89 2180-99-4049
* Rekursion kann man erst verstehen, wenn man Rekursion verstanden hat. *
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
