Using biosdevname by default?

Martin Pitt martin.pitt at
Sun Feb 5 13:26:08 UTC 2012

Colin Watson [2012-01-31 14:29 +0000]:
> There are certainly some advantages to enabling biosdevname by default.
> On systems that support it, it makes it somewhat easier to write scripts
> that predictably apply to a certain interface without having to mess
> around with looking up interfaces by MAC address.

I agree that in many situations where you work with multiple
interfaces, stable names would be much preferrable.

> [...]
> Secondly, while as I said above I agree that enabling biosdevname solves
> some problems, it seems likely that this change will cause problems of
> its own.  For example, any software that needs to know about network
> interfaces (let's say it listens on a particular interface) might well
> default to eth0

Stephane confirmed that this is an actual problem in his reply.

This situation has a striking similarity with stable names for block,
sound, and input devices. There was a time when the "classic" names
like hda/sda went away entirely, but this situation never lasted very
long because of pretty much exactly this problem: too much software
making hardcoded assumptions about device names.

That's why the current policy eventually distilled itself: it is
actively wrong, and now even unsupported by udev to rename devices, so
schemas like "sd[a-z][0-9]"  or input/event* will always continue to
work. Instead, the only thing you can and should do is to create
aliases in the form of symlinks (/dev/disks/by-uuid/,
/dev/input/by-id/, etc.)

Now, unfortunately network devices have always been special in that
they are not proper character devices, so symlinks don't work.  But as
the kernel supports renaming devices, is there any way of providing
the same devices under two names, i. e. adding aliases instead of
ifrename? interfaces(5) already supports mappings and renames, so from
my naive POV it seems this shouldn't be too hard to get a concept of
aliases? Perhaps even the Dell folks would be interested in this, as
it would remove the main blocker for adoption?

If we can get this to work, then I see no reason to not introduce
biosdevname, as it would not break any existing setup, local
configuration, or hardcoded assumption.


Martin Pitt                        |
Ubuntu Developer (  | Debian Developer  (

More information about the ubuntu-server mailing list