Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1518628 - On-board network devices on a clean install enumerated starting with eno2 (not eno1)
Summary: On-board network devices on a clean install enumerated starting with eno2 (no...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: udev
Version: 7.4
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Michal Sekletar
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-11-29 11:14 UTC by Radosław Piliszek
Modified: 2017-11-30 10:10 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-11-30 10:10:05 UTC


Attachments (Terms of Use)

Description Radosław Piliszek 2017-11-29 11:14:31 UTC
Description of problem:

On-board network devices on a clean install are enumerated starting with eno2 (not eno1).

How reproducible:
Always.

Steps to Reproduce:
1. Leave default consistent device naming scheme on.
2. Observe device names.

Actual results:
eno2, eno3, ... (no eno1)

Expected results:
eno1, eno2, ...

Additional info:

The platform is Fujitsu RX350 S8.

Relevant dmidecode dump:

Handle 0x0061, DMI type 41, 11 bytes
Onboard Device
        Reference Designation: Intel I350
        Type: Ethernet
        Status: Enabled
        Type Instance: 1
        Bus Address: 0000:07:00.0

Handle 0x0062, DMI type 41, 11 bytes
Onboard Device
        Reference Designation: Intel I350
        Type: Ethernet
        Status: Enabled
        Type Instance: 2
        Bus Address: 0000:07:00.1

Relevant lspci dump:

07:00.0 Ethernet controller [0200]: Intel Corporation I350 Gigabit Network Connection [8086:1521] (rev 01)
07:00.1 Ethernet controller [0200]: Intel Corporation I350 Gigabit Network Connection [8086:1521] (rev 01)

Relevant ip link dump:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT qlen 1
2: eno2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT qlen 1000
3: eno3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT qlen 1000

Relevant biosdevname dump:

# biosdevname -i eno2
em1
# biosdevname -i eno3
em2

Comment 2 Harald Hoyer 2017-11-29 12:19:57 UTC
This is a firmware/kernel bug. Udev just takes the value of /sys.

What is the output of:
$ egrep . /sys/class/net/*/{,device/}*index

Comment 3 Radosław Piliszek 2017-11-29 12:39:00 UTC
# egrep . /sys/class/net/*/{,device/}*index
/sys/class/net/eno2/ifindex:2
/sys/class/net/eno3/ifindex:3
/sys/class/net/ib0/ifindex:4
/sys/class/net/lo/ifindex:1
/sys/class/net/eno2/device/acpi_index:2
/sys/class/net/eno3/device/acpi_index:3

Comment 4 Radosław Piliszek 2017-11-29 13:07:56 UTC
And also:

# egrep . $(find /sys -name acpi_index)
/sys/devices/pci0000:00/0000:00:01.0/acpi_index:5
/sys/devices/pci0000:00/0000:00:02.0/acpi_index:8
/sys/devices/pci0000:00/0000:00:02.2/acpi_index:9
/sys/devices/pci0000:00/0000:00:03.0/acpi_index:6
/sys/devices/pci0000:00/0000:00:03.2/acpi_index:7
/sys/devices/pci0000:00/0000:00:1c.0/0000:07:00.0/acpi_index:2
/sys/devices/pci0000:00/0000:00:1c.0/0000:07:00.1/acpi_index:3
/sys/devices/pci0000:00/0000:00:1c.7/0000:09:00.0/acpi_index:4
/sys/devices/pci0000:80/0000:80:00.0/acpi_index:10
/sys/devices/pci0000:80/0000:80:01.0/acpi_index:14
/sys/devices/pci0000:80/0000:80:01.1/acpi_index:12
/sys/devices/pci0000:80/0000:80:02.0/acpi_index:11
/sys/devices/pci0000:80/0000:80:03.0/acpi_index:13

Comment 5 Harald Hoyer 2017-11-29 14:59:07 UTC
So the ACPI reports

/sys/class/net/eno2/device/acpi_index:2
/sys/class/net/eno3/device/acpi_index:3

which is used by udev for a persistent name.

Comment 6 Radosław Piliszek 2017-11-29 16:42:59 UTC
Yeah, I see. This number comes straight from ACPI? Then I guess this could be considered platform's fault... Still, since biosdevname is able to give a better ordering (it starts with 1), why not use its numbering scheme (SMBIOS)? These ACPI indices seem to go from 2 to 14 for the different ACPI-enabled PCI(-e) devices. I guess there could be a platform where the Ethernet devices might actually get numbers like 12 and 13 because why not (and is not it what happened to interfaces under VMware which got big numbers like eno3518213?). This is just some ACPI-enabled PCI device id.

From the docs:
Scheme 1: Names incorporating Firmware or BIOS provided index numbers for on-board devices (example: eno1), are applied if that information from the firmware or BIOS is applicable and available, else falling back to scheme 2. 

Then I believe SMBIOS information should be more important than ACPI one (as non-NIC devices also get ACPI id and SMBIOS is clear about different device types - it actually makes me wonder why use ACPI id at all).

PS: I'm not insisting on it being udev's problem. I just selected udev because it is what finally gives interfaces their names.

Comment 7 Lukáš Nykrýn 2017-11-30 10:10:05 UTC
Anyway, there is nothing we should do about this in rhel. Even if the naming would not be ideal, any change could be highly disruptive.


Note You need to log in before you can comment on or make changes to this bug.