Am 11.04.2013 12:55, schrieb Reindl Harald: > > > Am 11.04.2013 12:41, schrieb Colin Guthrie: >> 'Twas brillig, and Andrey Borzenkov at 11/04/13 10:25 did gyre and gimble: >>> On Thu, Apr 11, 2013 at 2:50 AM, Reindl Harald <[email protected]> >>> wrote: >>>> /usr/share/doc/systemd/README.Fedora-18 >>>> >>>> - A hacky workaround that allows udev to rename network interfaces into >>>> kernel's ethX namespace has been re-added. This is to support users who >>>> still >>>> rely on udev rules such as 70-persistent-net.rules generated in previous >>>> Fedora releases to name their network interfaces. Note that the >>>> workaround is >>>> only temporary and will go away in a future Fedora release >>>> ______________________________________ >>>> >>>> PLEASE DO NOT remove this mechanism >>>> >>>> well, you are not creating it since a long time, BUT do not >>>> stop use this config file if it is present! >>>> >>> >>> Mmm ... if rules file exists in correct directory it of course will be >>> used. Or do you mean to not remove auto-generation of this file? >> >> Isn't the mechanism used to shuffle around conflictingly named >> interfaces gone from udev these days (it is after all racy and buggy). >> >> If so then things might not work nicely when processing the old rules. >> Users should be strongly encouraged to migrate to the persistent network >> interface names which avoids the design flaws inherent with the >> previously approach. > > that is all nice in theory > in real life there are THOUSANDS of setups with only one ethernet interface > there are THOUSANDS of virtual machines with only one network interface > there are THOUSANDS of virtual machines with only two NICs and no > race-problems
Just add "net.ifnames=0 biosdevname=0" to the kernel command line and you don't need any 70-persistent-net.rules. Udev will not try to rename your interfaces. Only $ rpm -qf /lib/udev/rename_device initscripts-9.45-2.fc19.x86_64 kicks in and renames interfaces according to the ifcfg-* files, if HWADDR is set, and if there are no conflicts. _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
