Forgot your password?
typodupeerror
Networking Red Hat Software Linux

Fedora 15 Changes Network Device Naming Scheme 132

Posted by timothy
from the shock-horror-horror-shock dept.
dkd903 writes "Fedora developer Matt Domsch has announced that Fedora 15 is breaking the conventional ethX naming scheme used for Ethernet devices by adopting a new scheme called Consistent Network Device Naming. The ethX naming scheme works fine as long as the system has only one Ethernet port. However if there are more than one Ethernet ports, the actual problem starts."
This discussion has been archived. No new comments can be posted.

Fedora 15 Changes Network Device Naming Scheme

Comments Filter:
  • False (Score:5, Interesting)

    by Issarlk (1429361) on Wednesday January 26, 2011 @07:04AM (#35006966)
    "However if there are more than one Ethernet ports, a sort of race condition develops at every system boot and the ports may get their names in an arbitrary order"

    Wrong, udev handles this very fine. This is a complicated solution to a non-problem.
  • /dev/disk/by-id/ (Score:3, Interesting)

    by bill_mcgonigle (4333) * on Wednesday January 26, 2011 @08:08AM (#35007388) Homepage Journal

    this is why I don't like the /dev/sd* interfaces in Linux - you have to dig deep into /proc to find out which port SATA and SAS devices are on

    You might appreciate /dev/disk/by-id/:

    $ ls -l /dev/disk/by-id/
    total 0
    lrwxrwxrwx 1 root root 9 Dec 24 10:58 ata-ST3500630AS_9QG32BJ5 -> ../../sdb
    CLIPPED FOR LAMENESS FILTER
    lrwxrwxrwx 1 root root 9 Dec 24 10:58 ata-ST3500641AS_3PM1BA52 -> ../../sda
    CLIPPED FOR LAMENESS FILTER

    The /dev/disk tree can be super useful for, e.g. iSCSI device names in scripts.

  • Re:False (Score:5, Interesting)

    by msauve (701917) on Wednesday January 26, 2011 @09:03AM (#35007942)
    There are multiple issues, some of which have already been solved:

    Persistency: once eth0, always eth0 - this is what most commentators here seem to think this is all about, but it's already taken care of by udev with most modern distributions.

    Enumeration: Lacking previous knowledge, the order in which interfaces are enumerated. I would think this would be deterministic, but you say it's random (what is "semi-random?"). I'll take your word for it. It seems this is the problem they're trying to address. MAC addresses are indeed useless for this, in a general case, since we may be trying to enumerate ports on plug in boards (e.g. there's no guarantee the MAC in slot 1 will be lower than the MAC in slot 2).

    Naming: The article says they're changing the naming. This is what makes no sense. It's not "required." ethx is just fine, as long as the names are enumerated consistently (meaning that on two "identical" boxes, the order is identical based on physical port).
  • by Entrope (68843) on Wednesday January 26, 2011 @09:58AM (#35008662) Homepage

    Debian (and its derivatives, including Ubuntu) have been taking a less disruptive approach to this for years now by assigning persistent ethN device names based on MAC addresses. For example, if the system has no device names assigned and sees 01:23:45:67:89:ab as the first Ethernet device's address, that becomes eth0 from that point forward. The next Ethernet device that gets enumerated is going to be eth1, and so forth. This means it handles the USB device case in the way most users would expect.

    I suppose there is some advantage to using geographic addresses for people with lots of multi-NIC machines to build, and for people who need to hot-swap cards for reliability reasons. I suspect that Debian's udev-based approach could handle the latter either now or with minor tweaks, though.

Whoever dies with the most toys wins.

Working...