Biosdevname auto enabled on Dell HW

The design decision here several release cycles ago was to require the 'biosdevname=1' boot parameter to use this facility. I still prefer this, and would need a strong rationale for changing it as I believe a change would break a good deal of established behaviour.

Hi Colin,

What Dell is would like here is that this happens automatically for PowerEdge machines. I don't think it matters if they need to put 'biosdevname=1' in the kernel cmdline to make it happen, but then this is just pushed off as an installer bug.

Just so we're clear on the user impact, biosdevname is a technology mostly developed by Dell that puts the cards in a predictable order and fixes the problem of users having the confusing situation of eth0 being the add on card, and eth1 being the on board NIC. Or worse, having eth[13] be one card, and eth[24] be another card, or having it differ from machine model to machine model, etc. Biosdevname cuts down on the confusion for these users, and we would like Ubuntu server users to have a good experience out of the box rather than having to trawl documentation or search the Internet afterward install for a fix. A few other distros are already doing this by default for PowerEdge machines so without this feature request Ubuntu serve rwill fall behind in terms of user experience.

On Thu, Dec 15, 2011 at 10:39:46PM -0000, James M. Leddy wrote:
> What Dell is would like here is that this happens automatically for
> PowerEdge machines. I don't think it matters if they need to put
> 'biosdevname=1' in the kernel cmdline to make it happen, but then this
> is just pushed off as an installer bug.

They should be able to put 'biosdevname=1' in the kernel command line
today (in fact, since natty). Is this not working?

> Just so we're clear on the user impact, biosdevname is a technology
[...]

I know, I uploaded it to Ubuntu :-)

> Biosdevname cuts down on the confusion for these users, and we would
> like Ubuntu server users to have a good experience out of the box
> rather than having to trawl documentation or search the Internet
> afterward install for a fix. A few other distros are already doing
> this by default for PowerEdge machines so without this feature request
> Ubuntu serve rwill fall behind in terms of user experience.

While this is true in some ways, it also means that there's (for
example) never an eth0 interface. I'm not comfortable with doing this
for one class of machine, thus creating testing skew between different
classes of machines that renders it more difficult to do QA on anything
that touches network interfaces in any way, without the explicit consent
and buy-in of the server team; since they will end up debugging and
fixing issues that arise from it.

> I know, I uploaded it to Ubuntu :-)

I know you know what it is, that was for the edification for others reading this bug :-)

> I'm not comfortable with doing this
> for one class of machine, thus creating testing skew between different
> classes of machines that renders it more difficult to do QA on anything
> that touches network interfaces in any way, without the explicit consent
> and buy-in of the server team; since they will end up debugging and
> fixing issues that arise from it.

That's fair. Please let me know what the outcome of those discussions.

Colin,

Is the concern here that there might be installer code where eth0 is hard-coded (which probably needs to be fixed, anyway) and this will cause additional churn?

As mentioned here our other OS partners have already implemented biosdevname=1 by default on Dell hardware only. Yes it did break some things in their installer (eth0 hard-coded) so it was a great opportunity to fix less-than-ideal code.

Two of my colleagues (Jordan Hargrave and Narendra K) can answer specific questions if you have any, not sure if they have Launchpad accounts but will see if I can at least cc them here.

Colin,

Hey any feedback regarding comment #5. My peers are on standby if you have any specific questions.

Thank you.

The Ubuntu Foundations team is currently reviewing the status of this requested change. More information should be available soon.

I've opened this up for wider discussion, as this will affect enough other people that I don't feel that I can take this decision on my own, and added some of my thoughts on the benefits and risks:

  https://lists.ubuntu.com/archives/ubuntu-devel/2012-January/034687.html

(Also copied to the ubuntu-server list.)

Feel free to weigh in on the discussion on those lists, of course; I hope something along the lines of consensus will emerge.

Posted this to the ubuntu-devel mailing list yesterday, but it got moderated for some reason, even though I'm a member.

So biosdevname is something that Dell would like to have working in 12.04, regardless of whether it is enabled by default or not or our systems. So we see solving any hard-coded eth names or race conditions as mandatory for 12.04. That said, we’re willing to take a crack at identifying (and hopefully solving) the potential problems so that this works correctly. We did this last year already with Fedora, so we should have a good idea where to look. We’re also willing to pitch in and help test to verify that this is working as well.

I don’t know the specific cutoff date by when the decision needs to be made as to when this would be enabled/disabled by default in the installer, but upfront testing and bug closure should probably be done before the decision to enable would be made.

If the approach is to enable this on Dell "Poweredge" servers *only*, and we have a way to do that in the installer, I don't see a problem with it. Any users affected would presumably be Dell customers, and thus I expect it would be a shared interest and effort to help them. (my $0.02)

Relevant to this conversation, latest stable release of biosdevname is v0.3.11 (http://linux.dell.com/biosdevname). Oneiric has v0.3.8.

John: ubuntu-devel is typically moderated, but I let your post through a while back.

Jose: Good point - I'll see that it gets updated.

It would be helpful if a Dell engineer could follow up to the question in the ubuntu-devel thread regarding the practice of renaming devices.

I've updated to 0.3.11 now (bug 926926).

This isn't a ubiquity bug (it does not affect the desktop installer), so I've removed that task which was added recently. Depending on the decision taken on ubuntu-devel, I'll add tasks to this bug as necessary; there's no need to do so in advance.

As an aside, if I'm reading it correctly, the logic to make ethX names persistent via /etc/udev/rules.d/70-persistent-net.rules is apparently on its way out from udev:

http://marc.info/?l=linux-hotplug&m=131366602725095&w=2

And from the udev NEWS file, for version 174 ( https://git.kernel.org/?p=linux/hotplug/udev.git;a=blob_plain;f=NEWS;hb=HEAD ):

"The rules to create persistent network interface and cdrom link
rules automatically in /etc/udev/rules.d/ have been disabled by
default. Explicit configuration will be required for these use
cases, udev will no longer try to write any persistent system
configuration from a device hotplug path."

So if not for 12.04, at least somewhat longer-term, enabling biosdevname by default is probably the best way forward, IMHO.

(this would probably be more appropriate for the ubuntu-devel thread, but I'm not subscribed there so I'm being lazy and putting the msg here instead. Sorry.)

Per discussions on the mailing list, this will not be enabled by default for 12.04. We will continue to fix bugs related to use of biosdevname through 12.04, and can evaluate enabling it by default for 12.10.

Taking off the OEM-priority list for now

This bug was fixed in the package biosdevname - 0.4.0-0ubuntu2

---------------
biosdevname (0.4.0-0ubuntu2) quantal; urgency=low

  * Enable biosdevname by default in the installer (LP: #891258). Use the
    biosdevname=0 boot parameter if you need to disable it.
 -- Colin Watson <email address hidden> Mon, 20 Aug 2012 15:11:20 +0100

The mechanism implemented in this bug is being proposed to be changed. Please see https://lists.ubuntu.com/archives/ubuntu-devel/2015-June/038777.html. Feedback appreciated.