Forcing Linux to recognize NICS in BIOS order
Michael ODonnell
michael.odonnell at comcast.net
Tue Aug 15 10:34:01 EDT 2006
A network interface can have any name whatsoever; the default
(dainbramaged) approach is to let the kernel pick the names,
with the result that they end up being of the form ethN where
N is the order of registration (which is roughly equivalent to
the order of HW discovery, which is roughly equivalent to the
order of driver inits) leading to ambiguity problems such as the
ones in question. And, yes - the BIOS is free to discover/init
devices in any order it likes, which is likely to be different
from the kernel's approach, which is likely to be different from
the next kernel you install. PCI discovery/enumeration is
definitely a work in progress.
That 'alias' trick described previously has been known to work,
though I thought I also heard that some versions suffered from a
bug whereby your interface would disappear, having gotten "lost
in the shuffle" as the scripted logic (invoked during the ifup
sequence, IIRC) for managing the aliases was busy re-re-renaming
the various interfaces to temporary names, though that bug may
have only been seen when bonding was in play. And I'm pretty
sure I have personally witnessed failures whereby that alias
logic left an interface with one of those intermediate temp names
like dev09834. Which is not to say "don't use it", just that you
may want to test it thoroughly. We were working with RHEL4 so,
unfortunately, this isn't ancient history...
One approach you might consider is one I implemented for a former
employer that basically involved a script in /etc/hotplug/pci that
would use the ifrename command to rename interfaces as each one
was discovered, using names based on their position in the PCI
topology (of the form pciBB_SS_F for Bus/Slot/Function) something
that was easy to determine using the info under /sys/class/net
and which always resulted in unambiguous names.
More information about the gnhlug-discuss
mailing list