[systemd-devel] Proposal: integrate biosdevname into systemd tree

Alexander E. Patrakov patrakov at gmail.com
Fri Jan 4 01:40:29 PST 2013


2013/1/4 Reindl Harald <h.reindl at thelounge.net>:
> but hopefully /etc/udev/rules.d/70-persistent-net.rules will be recognized
> forever if it exists because there are many servers especially virtual
> ones where you hardly need to control ethernet device names to avoid
> breaking iptables-scripts as example

Yes, the existing rules will continue to be recognized. The bug is
that even they are intrinsically unreliable (as happened with that
rented server), so I think you actually don't want that.

> keep in mind there are MANY setups which do not need nor want
> biosdevname and are bootet with biosdevname=0 on the kernel line

And that's indeed something that we need to think about. The real
problem is that it is hard to explain the whole interface-renumbering
issue and the reasons why he needs persistence to an average sysadmin.
It's too low level. IMHO it is safer to always install biosdevname and
use it even if not strictly required than to rely on the sysadmin to
know about the issue. For me, even with the old solution in place, the
bug surfaced after ~10 reboots. That's more than an average sysadmin
is willing to test before saying "I think it always boots as it
should". Besides, the sysadmin can be wrong about not needing the
persistent names. Again, my position is: better safe than sorry,
especially with remotely-managed servers.

> P.S.: i HATE it to need "ifconfig -a" and hack "70-persistent-net.rules"
> by hand instead as all the years open it and change back the last line
> to "eth0" after probe-restore of a virtual machine to temporary access
> a datarecovery backup from some weeks ago

With biosdevname, the interface names are determined only by PCI bus
slot. I.e., if the replacement card is inserted into the same slot as
the failed one, the name won't change. And in virtual machines
biosdevname deactivates itself automatically.

-- 
Alexander E. Patrakov


More information about the systemd-devel mailing list