Why is my eth0 called eno16777736?

I've seen http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/, which describes the rationale for consistent/predictable device naming, and then the rules by which device names are generated:

 * Two character prefixes based on the type of interface:
 *   en -- ethernet
 *   sl -- serial line IP (slip)
 *   wl -- wlan
 *   ww -- wwan
 *
 * Type of names:
 *   b<number>                             -- BCMA bus core number
 *   ccw<name>                             -- CCW bus group name
 *   o<index>                              -- on-board device index number
 *   s<slot>[f<function>][d<dev_port>]     -- hotplug slot index number
 *   x<MAC>                                -- MAC address
 *   [P<domain>]p<bus>s<slot>[f<function>][d<dev_port>]
 *                                         -- PCI geographical location
 *   [P<domain>]p<bus>s<slot>[f<function>][u<port>][..][c<config>][i<interface>]
 *                                         -- USB port number chain

So let's say I've got device eno16777736: why is it called that? It's an ethernet card, I got that. But how can I back into the rest of this interface's name myself?

I examined /sys/class/net/eno16777736, and saw:

eno16777736 -> ../../devices/pci0000:00/0000:00:11.0/0000:02:01.0/net/eno16777736

Not sure how to interpret this either, or whether I can use this information to get to eno16777736.

Update

So the 16777736 is the device's acpi_index. Per https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-bus-pci:

What:       /sys/bus/pci/devices/.../acpi_index
Date:       July 2010
Contact:    Narendra K <[email protected]>, [email protected]
Description:
        Reading this attribute will provide the firmware
        given instance (ACPI _DSM instance number) of the PCI device.
        The attribute will be created only if the firmware has given
        an instance number to the PCI device. ACPI _DSM instance number
        will be given priority if the system firmware provides SMBIOS
        type 41 device type instance also.

And, indeed:

core@localhost /sys/devices/pci0000:00/0000:00:11.0/0000:02:01.0 $ find . -type f | xargs grep 1677 2> /dev/null
./net/eno16777736/uevent:INTERFACE=eno16777736
./acpi_index:16777736

Further, to reconcile output from ifconfig or ip link and your devices in lspci:

$ ifconfig
eno16777736: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.0.0.37  netmask 255.255.255.0  broadcast 10.0.0.255
        inet6 fe80::20c:29ff:fe70:c039  prefixlen 64  scopeid 0x20<link>
        inet6 2601:a:7c0:66:20c:29ff:fe70:c039  prefixlen 64  scopeid 0x0<global>
        ether 00:0c:29:70:c0:39  txqueuelen 1000  (Ethernet)
        RX packets 326  bytes 37358 (36.4 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 172  bytes 45999 (44.9 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 19  base 0x2000 

Notice the "device interrupt 19". And from lspci -v, which has "IRQ 19":

02:01.0 Ethernet controller: Advanced Micro Devices, Inc. [AMD] 79c970 [PCnet32 LANCE] (rev 10)
        Subsystem: Advanced Micro Devices, Inc. [AMD] PCnet - Fast 79C971
        Physical Slot: 33
        Flags: bus master, medium devsel, latency 64, IRQ 19
        I/O ports at 2000 [size=128]
        [virtual] Expansion ROM at fd500000 [disabled] [size=64K]
        Kernel driver in use: pcnet32

Here you also see "Phyiscal Slot 33", and indeed, sometimes VMWare boots VMs that get ens33 as the interface name. So, it's unclear why other times it chooses eno16777736. But the 16777736 comes from the acpi_index, and the 33 comes from the PCI slot.

Solution 1:

en for Ethernet

o for onboard

16777736 is the index of the device as provided by the firmware (BIOS/EFI). It would have been logical to start the index at 1. Either that, or you either have sensible firmware and over 16 million onboard devices! But more likely, you're seeing the issue raised (but not answered) on VMware Community - it seems that the number comes from a possible negative overflow on acpi_index.

You can view similar info from udev for your system with:

udevadm info --name=/dev/eno16777736 --attribute-walk

Solution 2:

Using VMware?

The Unix Stackexchange site had a question and answer about this. It would appear that information about the NIC is being provided by the BIOS.

If you want to change it to eth0 (or some other name) you can use udev to do so. Here is a handy guide for doing so.