Re: [systemd-devel] eth2: Failed to rename network interface 6 from 'eth2' to 'eno1': File exists
Am Mi., 5. Jan. 2022 um 13:50 Uhr schrieb Mantas Mikulėnas : > It does, yes, but note this part: > > Jan 03 11:30:14 nasl002b.example.com kernel: igb :02:00.2 eth4: renamed > from eth2 > Jan 03 11:30:14 nasl002b.example.com kernel: igb :02:00.3 eth5: renamed > from eth3 > > Here the kernel-assigned names (eth2, eth3) are being renamed to custom names > (eth4, eth5). That's not something systemd or udev does by default. It > suggests that you likely have old "70-persistent-net" udev rules (or > something similar) that assign custom eth* names separately from the > slot-based "predictable" naming – perhaps a leftover from Debian 7. > > These interfaces aren't being skipped due to an earlier conflict – they are > intentionally skipped by 80-net-setup-link.rules because they already have a > custom 'NAME=' assigned by an earlier rule, so the "predictable" name is not > applied to avoid breaking existing configuration. Yes, please check if you have a leftover file /etc/udev/rules.d/70-persistent-net.rules See also the relevant NEWS entry in /usr/share/doc/udev/NEWS.Debian.gz systemd (220-7) unstable; urgency=medium The mechanism for providing stable network interface names changed. Previously they were kept in /etc/udev/rules.d/70-persistent-net.rules which mapped device MAC addresses to the (arbitrary) name they got when they first appeared (i. e. mostly at the time of installation). As this had several problems and is not supported any more, this is deprecated in favor of the "net.ifnames" mechanism. With this most of your network interfaces will get location-based names. If you have ifupdown, firewall, or other configuration that relies on the old names, you need to update these by Debian 10/Ubuntu 18.04 LTS, and then remove /etc/udev/rules.d/70-persistent-net.rules. Please see /usr/share/doc/udev/README.Debian.gz for details about this. -- Martin Pitt Mon, 15 Jun 2015 15:30:29 +0200
Re: [systemd-devel] eth2: Failed to rename network interface 6 from 'eth2' to 'eno1': File exists
On 2022-01-05 13:50:29, Mantas Mikulėnas wrote: On Wed, Jan 5, 2022 at 9:46 AM Harald Dunkel AFAICS the kernel of today still assigns the "legacy" interface names, which are renamed by udev later. I would suggest to improve conflict It does, yes, but note this part: Jan 03 11:30:14 nasl002b.example.com kernel: igb :02:00.2 eth4: renamed from eth2 Jan 03 11:30:14 nasl002b.example.com kernel: igb :02:00.3 eth5: renamed from eth3 BTW: # lspci 00:00.0 Host bridge: Intel Corporation Xeon E3-1200 Processor Family DRAM Controller (rev 09) 00:01.0 PCI bridge: Intel Corporation Xeon E3-1200/2nd Generation Core Processor Family PCI Express Root Port (rev 09) 00:01.1 PCI bridge: Intel Corporation Xeon E3-1200/2nd Generation Core Processor Family PCI Express Root Port (rev 09) 00:19.0 Ethernet controller: Intel Corporation 82579LM Gigabit Network Connection (Lewisville) (rev 05) 00:1a.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #2 (rev 05) 00:1c.0 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 1 (rev b5) 00:1c.4 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 5 (rev b5) 00:1c.5 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 6 (rev b5) 00:1d.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #1 (rev 05) 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev a5) 00:1f.0 ISA bridge: Intel Corporation C204 Chipset LPC Controller (rev 05) 00:1f.2 SATA controller: Intel Corporation 6 Series/C200 Series Chipset Family 6 port Desktop SATA AHCI Controller (rev 05) 00:1f.3 SMBus: Intel Corporation 6 Series/C200 Series Chipset Family SMBus Controller (rev 05) 02:00.0 Ethernet controller: Intel Corporation I350 Gigabit Network Connection (rev 01) 02:00.1 Ethernet controller: Intel Corporation I350 Gigabit Network Connection (rev 01) 02:00.2 Ethernet controller: Intel Corporation I350 Gigabit Network Connection (rev 01) 02:00.3 Ethernet controller: Intel Corporation I350 Gigabit Network Connection (rev 01) 04:00.0 RAID bus controller: 3ware Inc 9750 SAS2/SATA-II RAID PCIe (rev 05) 05:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection 06:00.0 VGA compatible controller: Matrox Electronics Systems Ltd. MGA G200e [Pilot] ServerEngines (SEP1) (rev 04) Sorry, I should have included this list right from the start. Regards Harri
Re: [systemd-devel] eth2: Failed to rename network interface 6 from 'eth2' to 'eno1': File exists
On 2022-01-05 11:17:20, Martin Wilck wrote: This is default behavior. To disable it, you need to use "net.ifnames=0". If you see the same value multiple times for either "acpi_index" or "index", it'd be a firmware problem. I suppose it can happen that one device has acpi_index==1 and another one has index==1 (IIRC the first is derived from ACPI _DSM, the second from SMBIOS / DMI type 41). I wonder where I can find these acpi_index and index attributes? Regards Harri
Re: [systemd-devel] eth2: Failed to rename network interface 6 from 'eth2' to 'eno1': File exists
On Wed, Jan 5, 2022 at 9:46 AM Harald Dunkel wrote: > On 2022-01-04 16:14:16, Andrei Borzenkov wrote: > > > > You have two interfaces which export the same onboard interface index. > > There is not much udev can do here; the only option is to disable > > onboard interface name policy. The attributes that are used by udev > > are "acpi_index" and "index". Check values of these attributes for > > all interfaces. > > > > I will check, but please note that I didn't enable this. AFAIU Debian > uses the settings according to the guidelines of upstream. > > > > > As is obvious from the log you provided, they did not "keep" their > > names but were renamed. Whether this is correct depends on rules your > > distribution is using. > > > > AFAICS the kernel of today still assigns the "legacy" interface names, > which are renamed by udev later. I would suggest to improve conflict > It does, yes, but note this part: Jan 03 11:30:14 nasl002b.example.com kernel: igb :02:00.2 eth4: renamed from eth2 Jan 03 11:30:14 nasl002b.example.com kernel: igb :02:00.3 eth5: renamed from eth3 Here the kernel-assigned names (eth2, eth3) are being renamed to custom names (eth4, eth5). That's not something systemd or udev does by default. It suggests that you likely have old "70-persistent-net" udev rules (or something similar) that assign custom eth* names separately from the slot-based "predictable" naming – perhaps a leftover from Debian 7. These interfaces aren't being skipped due to an earlier conflict – they are intentionally skipped by 80-net-setup-link.rules because they already have a custom 'NAME=' assigned by an earlier rule, so the "predictable" name is not applied to avoid breaking existing configuration. It also makes me wonder whether one of your interfaces might actually have the "eno1" name assigned manually (through another udev rule) and not really through the "predictable" naming. -- Mantas Mikulėnas
Re: [systemd-devel] eth2: Failed to rename network interface 6 from 'eth2' to 'eno1': File exists
On Wed, 2022-01-05 at 08:39 +0100, Harald Dunkel wrote: > On 2022-01-04 16:14:16, Andrei Borzenkov wrote: > > > > You have two interfaces which export the same onboard interface > > index. > > There is not much udev can do here; the only option is to disable > > onboard interface name policy. The attributes that are used by udev > > are "acpi_index" and "index". Check values of these attributes for > > all interfaces. > > > > I will check, but please note that I didn't enable this. AFAIU Debian > uses the settings according to the guidelines of upstream. This is default behavior. To disable it, you need to use "net.ifnames=0". If you see the same value multiple times for either "acpi_index" or "index", it'd be a firmware problem. I suppose it can happen that one device has acpi_index==1 and another one has index==1 (IIRC the first is derived from ACPI _DSM, the second from SMBIOS / DMI type 41). Martin
