Using biosdevname by default?

[Peter M. Petrakis]

On 01/31/2012 09:29 AM, Colin Watson wrote:
> Dell has asked for biosdevname to be enabled by default on new Ubuntu
> installations on Dell PowerEdge servers:
>
>    https://bugs.launchpad.net/ubuntu/+source/biosdevname/+bug/891258
>
> I do not feel that this is a decision I can take on my own, and would
> like to seek guidance from the good folks on these lists.
>
> For those unfamiliar with biosdevname, it's a udev helper intended to
> handle the problem of unstable network device enumeration ordering by
> mapping them into different namespaces according to BIOS-provided naming
> information.  More information can be found here:
>
>    http://linux.dell.com/biosdevname/
>    http://manpages.ubuntu.com/biosdevname
>
> This is supported on an opt-in basis from Ubuntu 11.04 on (modulo a bug
> in 11.04 to the effect that it didn't work with a separate /usr, fixed
> in 11.10) by passing the "biosdevname=1" kernel parameter when starting
> the installer.
>
>
> 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.
>
> However, I have a few concerns about enabling this by default.  Firstly,
> I think it is in general unwise to make this kind of change for a single
> class of machine, at least for Ubuntu itself as opposed to
> vendor-specific builds.  The effect of doing that is to divide our
> testing efforts, so that tests of relevant functionality on one class of
> machine can no longer be presumed to be valid for others.  This usually
> ends up being to the detriment of everyone: Dell servers would no longer
> be able to take advantage of the testing we do on other classes of
> system.
>
> Of course, not many other systems support biosdevname anyway; HP
> ProLiants are explicitly handled in the biosdevname source, but for many
> systems, including at least kvm but many real machines as well,
> biosdevname will just leave the kernel-provided interface names in
> place.  (Even if biosdevname supported no non-Dell systems right now,
> I'd still be of the opinion that we should be as consistent about it as
> we can on the basis that other BIOSes might add support at some point in
> the next five years.)
>
> 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; this will break on many wireless-only systems and
> require manual configuration, but if it's not the sort of thing that you
> use on a laptop, many users might not previously have noticed.  Using
> biosdevname by default would extend these problems to many server-class
> machines out of the box.  While anything like this is certainly a bug
> already, with the new scheme we'd *have* to fix everything like that and
> it'd be easy to miss something.  The question of whether you see this as
> an opportunity to expose existing bugs or as a risk rather depends on
> your point of view. :-)
>
> Still, I'm not typically working in environments where unstable network
> device naming causes me any problems, so I tend to see the downsides
> rather than the upsides.  I'd like to hear from people who do suffer
> from this kind of problem, as well as from the server team who would
> presumably be at the sharp end either way.
>
> Thanks,
>

It concerns me that we would be populating new device names, that depend
on specific bios features, and then modify our network stack in this
example to take advantage of them. In general, distributions have a spotty
record of encouraging vendors to repair bios issues, like S3. Once these
servers are no longer supported, I'm worried that we'll be compelled to
maintain a quirks database for unsupported systems or systems with unresponsive
vendors.

While Dell and HP servers seem to work with biosdevname. How would ARM
servers or appliances go about implementing this feature, or your average
whitebox server? I know it depends on SMBIOS, which ARM firmware really has
no motivation to implement. Are whitebox servers even populating SMBIOS well
enough for biosdevname to function?

Suppose we could enable it by default for only PowerEdge servers. It appears
that the effort to integrate the use of these new names falls to the community,
is that right? As for enabling it by default, a simple packaging change to the Dell
OMSA tools could enable biosdevname.

Peter