Using biosdevname by default?

Stéphane Graber stgraber at ubuntu.com
Tue Jan 31 14:57:55 UTC 2012


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

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,
> 

Hello,

As you know I've spent quite a bit of time looking at and fixing a
bunch of network related packages and hooks lately.

One thing I noticed in quite a few places is the use of wildcard like
"eth*.*|bond*.*|wlan*.*" to match any ethernet network interface on
which to create a VLAN.

Using em* or pci* will break these scripts and possibly much more than
the ones I found with a quick grep on my system.

If we are to do it, this will need extensive testing on systems where
 biosdevname would rename interfaces, including making sure we don't
have any race condition in udev/upstart as we use the udev events to
trigger interface configuration through upstart and through a bunch of
udev hooks (vlan, bridging, ...).

I personally find this change risky for 12.04, I agree the hardcoded
use of eth* and similar are hacks that we should get rid of, but I
doubt we have the resources or time to check and fix the whole archive
in time for 12.04.

It's the kind of change I'd be happy for us to do in early 12.10,
making it clear to all affected teams that this bit changed and to
look for bugs.
I'm quite happy at how stable networking is now in 12.04, it'd be a
shame to break it now by turning on something like biosdevname.

- -- 
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCgAGBQJPKAFyAAoJEMY4l01keS1nb9EP+wWS5nWhYm3DtmORVwx6v1RU
85Spl36dMgrIa9UJOtmrJluyULuMfUGse6gHt6xnR+vk88dlBTQbUBTAzKqXXKI7
abg3H6YiR7nAe85jJCwleV6VOXFjiCkpKfUonagGL12zlfWQoxg+USlml0F9Yk9q
2H3w8c9I3x+FFQn7NGqCxWZfC6f47AGMi+Y1il/Ljdq/Nme0XwMAImdGYoEEK4hd
O38CdoBqjcBGUbV6jN1cJtSUBaVNOvD27OLNf33AuoKmNkux/fnWE1r5fhtDZVs5
Gy4WAo8sHv3OYiz/FWTkrEH2fP4ETdmMjU2r06Jgw8FwfgJJ/O+KjeUegLhA05gC
L6E0qHY/WLGdZPnTY256OYe6t9o/iwiVtmwOLziZr8vqxmXEnR8vYfoQHCscX6ov
EZaQI/Ey5+uXlIYdftll8enJB0CDnla0hlQwEGa4MFXQnH8RlszHRO53xKHQ3T2W
+Cacfm1XnupWSeqgTPF2w3BjY9qGhKffFcdsiHluNkBW3lQaFrGo5mQ8XuHQ96p2
z9+C5NBGB3vjN7jt2mcHZo+wCdJCXG91iPpmXjgK/r0U4De3+EyRoThQOyl/OUXM
I3vL041PPpledgTW8326vBGxwgOELEF/FJdIrPR2TehHjLa9l1InwS1B57VhcA04
5fzGdyUTwhrZwtUV8TjR
=w63r
-----END PGP SIGNATURE-----




More information about the ubuntu-server mailing list