Using biosdevname by default?
 

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,

--
Colin Watson [cjwatson@ubuntu.com]

--
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Using biosdevname by default?
 

-----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+wWS5nWhYm 3DtmORVwx6v1RU
85Spl36dMgrIa9UJOtmrJluyULuMfUGse6gHt6xnR+vk88dlBT QbUBTAzKqXXKI7
abg3H6YiR7nAe85jJCwleV6VOXFjiCkpKfUonagGL12zlfWQox g+USlml0F9Yk9q
2H3w8c9I3x+FFQn7NGqCxWZfC6f47AGMi+Y1il/Ljdq/Nme0XwMAImdGYoEEK4hd
O38CdoBqjcBGUbV6jN1cJtSUBaVNOvD27OLNf33AuoKmNkux/fnWE1r5fhtDZVs5
Gy4WAo8sHv3OYiz/FWTkrEH2fP4ETdmMjU2r06Jgw8FwfgJJ/O+KjeUegLhA05gC
L6E0qHY/WLGdZPnTY256OYe6t9o/iwiVtmwOLziZr8vqxmXEnR8vYfoQHCscX6ov
EZaQI/Ey5+uXlIYdftll8enJB0CDnla0hlQwEGa4MFXQnH8RlszHRO53 xKHQ3T2W
+Cacfm1XnupWSeqgTPF2w3BjY9qGhKffFcdsiHluNkBW3lQaFr Go5mQ8XuHQ96p2
z9+C5NBGB3vjN7jt2mcHZo+wCdJCXG91iPpmXjgK/r0U4De3+EyRoThQOyl/OUXM
I3vL041PPpledgTW8326vBGxwgOELEF/FJdIrPR2TehHjLa9l1InwS1B57VhcA04
5fzGdyUTwhrZwtUV8TjR
=w63r
-----END PGP SIGNATURE-----

--
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Using biosdevname by default?
 

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

--
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Using biosdevname by default?
 

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.

Thanks,

Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

--
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Using biosdevname by default?
 

?

On Feb 5, 2012 1:52 PM, "Martin Pitt" <martin.pitt@ubuntu.com> wrote:
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.



Thanks,



Martin

--

Martin Pitt * * * * * * * * * * * *| http://www.piware.de

Ubuntu Developer (www.ubuntu.com) *| Debian Developer *(www.debian.org)



--

ubuntu-devel mailing list

ubuntu-devel@lists.ubuntu.com

Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel


--
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Using biosdevname by default?
 

On Tue, Feb 07, 2012 at 01:50:19AM +0000, Colin Watson wrote:
> 2) At UDS, consider defaulting to biosdevname=1 for 12.10. Presumably
> by that point we would have reasonably substantial experience with
> it as a result of 1).

biosdevname is now enabled by default on 12.10 alternate/server
installs. This will cause some machines to use different (and more
stable across reboots) network interface names.

If you see network configuration failures during installation and you're
doing preseeded installations, check whether you've hardcoded the
previous network interface name in your preseed file. If that's the
case, you can try one of the following:

* Use "IPAPPEND 2" in your pxelinux.cfg, and remove any
netcfg/choose_interface preseeding. This will cause pxelinux to pass
a BOOTIF= parameter to the installer corresponding to the interface
used for PXE-booting, which d-i will use to select the same network
interface for use during installation.

* If you are not using pxelinux, or if you need to select a different
interface for use during installation, you may preseed
netcfg/choose_interface to a hardware MAC address in the form
aa:bb:cc:dd:ee:ff to use an interface with that hardware address.

* Find out the biosdevname-generated name for your network interface
(remove the preseeding for netcfg/choose_interface and you should be
shown a list of the available network interfaces; or use 'ip link
show' after biosdevname has done its work) and use that instead.

* As a last resort, pass the "biosdevname=0" boot parameter to return
to the previous scheme for naming network interfaces.

--
Colin Watson [cjwatson@ubuntu.com]

--
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Using biosdevname by default?
 

On Thu, Aug 23, 2012 at 04:23:53PM +0100, Colin Watson wrote:
> On Tue, Feb 07, 2012 at 01:50:19AM +0000, Colin Watson wrote:
> > 2) At UDS, consider defaulting to biosdevname=1 for 12.10. Presumably
> > by that point we would have reasonably substantial experience with
> > it as a result of 1).

> biosdevname is now enabled by default on 12.10 alternate/server
> installs. This will cause some machines to use different (and more
> stable across reboots) network interface names.

Thanks, Colin!

Are we expecting this to be enabled for the desktop image as well, for
consistency?

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
--
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Using biosdevname by default?
 

On Thu, Aug 23, 2012 at 11:17:03AM -0700, Steve Langasek wrote:
> On Thu, Aug 23, 2012 at 04:23:53PM +0100, Colin Watson wrote:
> > On Tue, Feb 07, 2012 at 01:50:19AM +0000, Colin Watson wrote:
> > > 2) At UDS, consider defaulting to biosdevname=1 for 12.10. Presumably
> > > by that point we would have reasonably substantial experience with
> > > it as a result of 1).
>
> > biosdevname is now enabled by default on 12.10 alternate/server
> > installs. This will cause some machines to use different (and more
> > stable across reboots) network interface names.
>
> Thanks, Colin!
>
> Are we expecting this to be enabled for the desktop image as well, for
> consistency?

I'm not sure about this, and would welcome thoughts. On the one hand,
consistency is valuable. On the other hand, I would expect the benefit
on typical desktop systems to be much less, and the change undeniably
has a cost; it's not clear to me that the trade-off makes sense on the
desktop.

--
Colin Watson [cjwatson@ubuntu.com]

--
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam