Debian buster 升级将所有接口重命名为 renameX

Debian buster 升级将所有接口重命名为 renameX

升级之前,它们的命名如下:

iface ens2f0
iface ens2f1

从原始安装。现在他们就像:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
2: rename2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 00:1e:67:7c:84:2b brd ff:ff:ff:ff:ff:ff
3: eno0: <BROADCAST,MULTICAST> mtu 1500 qdisc mq state DOWN group default qlen 1000
link/ether 00:1e:67:7c:84:2c brd ff:ff:ff:ff:ff:ff
4: rename4: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 00:1e:67:7c:84:2d brd ff:ff:ff:ff:ff:ff
5: rename5: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 00:1e:67:7c:84:2e brd ff:ff:ff:ff:ff:ff

它们是英特尔千兆 I350 适配器,因此从 lshw 我有:

           *-network:0 DISABLED
            description: Ethernet interface
            product: I350 Gigabit Network Connection
            vendor: Intel Corporation
            physical id: 0
            bus info: pci@0000:02:00.0
            logical name: rename2
            version: 01
            serial: 00:1e:67:7c:84:2b
            size: 1Gbit/s
            capacity: 1Gbit/s
            width: 32 bits
            clock: 33MHz
            capabilities: pm msi msix pciexpress vpd bus_master cap_list ethernet physical tp 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation
            configuration: autonegotiation=on broadcast=yes driver=igb driverversion=5.4.0-k duplex=full firmware=1.48, 0x800006e7 latency=0 link=no multicast=yes port=twisted pair speed=1Gbit/s
            resources: irq:26 memory:d0960000-d097ffff ioport:2060(size=32) memory:d09b0000-d09b3fff memory:d0aa0000-d0abffff memory:d0a80000-d0a9ffff
       *-network:1 DISABLED
            description: Ethernet interface
            product: I350 Gigabit Network Connection
            vendor: Intel Corporation
            physical id: 0.1
            bus info: pci@0000:02:00.1
            logical name: eno0
            version: 01
            serial: 00:1e:67:7c:84:2c
            size: 1Gbit/s
            capacity: 1Gbit/s
            width: 32 bits
            clock: 33MHz
            capabilities: pm msi msix pciexpress vpd bus_master cap_list ethernet physical tp 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation
            configuration: autonegotiation=on broadcast=yes driver=igb driverversion=5.4.0-k duplex=full firmware=1.48, 0x800006e7 latency=0 link=no multicast=yes port=twisted pair speed=1Gbit/s
            resources: irq:39 memory:d0940000-d095ffff ioport:2040(size=32) memory:d09a0000-d09a3fff memory:d0a60000-d0a7ffff memory:d0a40000-d0a5ffff
       *-network:2 DISABLED
            ...

我已经安装了firmware-linux-nonfree,以防出现固件问题,但它在 Debian Stretch 上运行良好。我不明白逻辑名称是/应该如何在这里创建的。我想我可以将 int rename2 配置为静态 IP 并使用它?为什么现在叫eno0?所有四个接口在 lshw 中均显示为已禁用。

编辑:添加更多细节

我也问过 udevadmin 的想法:

udevadm test-builtin net_id /sys/class/net/eno0 2>/dev/null
ID_NET_NAMING_SCHEME=v240
ID_NET_NAME_MAC=enx001e677c842c
ID_OUI_FROM_DATABASE=Intel Corporate
ID_NET_NAME_ONBOARD=eno0
ID_NET_LABEL_ONBOARD=enPowerVille
ID_NET_NAME_PATH=enp2s0f1
ID_NET_NAME_SLOT=ens2f1

那么为什么 Debian 没有将该接口视为 ens2f1 而不是 eno0 呢?

编辑 2:添加来自 @telcoM 的解决方案

vi /etc/systemd/network/20-builtins.link 
 [Match]
 Path=pci-0000:02:*

 [Link]
 NamePolicy=slot

然后重新启动,我得到:

kernel: [  107.897834] igb 0000:02:00.1 ens2f1: igb: ens2f1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX
Mar 30 11:56:45 host1 kernel: [  107.897978] br1: port 1(ens2f1) entered blocking state
Mar 30 11:56:45 host1 kernel: [  107.897981] br1: port 1(ens2f1) entered forwarding state
Mar 30 11:56:45 host1 kernel: [  107.898129] IPv6: ADDRCONF(NETDEV_CHANGE): br1: link becomes ready
Mar 30 11:56:46 host1 kernel: [  108.093815] igb 0000:02:00.0 ens2f0: igb: ens2f0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX
Mar 30 11:56:46 host1 kernel: [  108.093957] br0: port 1(ens2f0) entered blocking state
Mar 30 11:56:46 host1 kernel: [  108.093960] br0: port 1(ens2f0) entered forwarding state

我在启动网络时仍然遇到错误,无法在系统日志中找到特定错误,但我的接口和网桥现在已启动!非常感谢@telcoM

答案1

当从生产版本转移到 9 的 Beta 测试版本时,我在 Red Hat EL 上看到了同样的行为。看起来行为差异取决于所使用的 systemd 版本。

问题实际上是为什么旧版本使用 enp2f0 这样的名称而不是 eno0。如果没有看到系统上 PCI 插槽的 SMBIOS 记录的输出,dmidecode -t 9我无法解释为什么原始海报看到像 ens2f0 这样的名称,这意味着 SMBIOS 显示板载设备也有物理插槽号。

我找出了为什么eno0在旧版本的 中没有返回该名称的原因systemd,就像我习惯的那样。该函数dev_pci_onboard正在检查值 <= 0 并返回错误。较新的版本在这里有更复杂的逻辑,systemd 250 确实接受 SMBIOS 返回的实例号 0。因此,为了回答最初的问题,我想它已经enp从更新后返回样式名称切换为systemd现在接受来自固件的数据。

这是我昨天回复的更新。

eno当 SMBIOS (DMI) 或 ACPI 返回显示设备是板载 NIC 的信息时,将使用样式名称。我从未深入研究过 ACPI 情况,但对于 SMBIOS 情况,类型 41 记录取代了旧的类型 10 记录。请参阅下面的示例。

对于旧版本的systemd函数dev_pci_onboardudev/udev-builtin-net_id.c检查返回的索引号,<= 0然后返回错误,因此,如果您执行 admidecode -t 41并看到Type Instance0,那么这些旧版本的 systemd 会忽略 SMBIOS,因此会使用ensenp样式名称PCI 插槽或地址。对于 systemd 250,函数中的逻辑更加复杂,但这意味着它可以接受数量为 0 的 SMBIOS 设备实例。

下面是我昨天在发现这一切之前写的帖子,但它显示了数据的来源,并对 SMBIOS 实例编号进行了一般性评论。

我在 Red Hat 上看到了同样的行为,我很想知道为什么设备的固件实例编号应该从 1 开始。样式名称的编号eno可以来自 SMBIOS (DMI) 类型 41记录。

[root@ml110c ~]# dmidecode -t 41
# dmidecode 3.2

Getting SMBIOS data from sysfs.
SMBIOS 2.6 present.

Handle 0x2900, DMI type 41, 11 bytes
Onboard Device
        Reference Designation: NIC Port 1
        Type: Ethernet
        Status: Enabled
        Type Instance: 0
        Bus Address: 0000:02:00.0

Handle 0x2901, DMI type 41, 11 bytes
Onboard Device
        Reference Designation: NIC Port 2
        Type: Ethernet
        Status: Enabled
        Type Instance: 1
        Bus Address: 0000:03:00.0

[root@ml110c ~]#

在此系统上,HP ProLiant ml110 g7 NIC 端口的实例编号为 0 和 1。NIC 端口 2 的实例编号为 1,并被分配“可预测名称” eno1。但实例号为 0 的设备最终会被调用,enp2s0因为该 PCI 地址没有类型 9 记录。

[root@ml110c ~]# ethtool -i enp2s0
driver: e1000e
version: 3.2.6-k
firmware-version: 2.1-2
expansion-rom-version:
bus-info: 0000:02:00.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: no
[root@ml110c ~]#

记下 PCI 地址,这是由第一个类型 41 记录标识的设备。

在具有 10G NIC 的 HP gen9 服务器上,板载设备实例编号从 49 而不是 1 开始,各种在线帖子表明某些戴尔服务器也是如此。在 HP 机器上,我可以访问这些 NIC,这些 NIC 显示为“可预测名称” eno49eno50...我不确定如何能够预测这些名称。较新的 gen10 HPE 服务器不执行此操作,它们从 开始eno1

答案2

类似的网络接口名称rename2表明系统正在重命名接口,但不知何故遇到了冲突。

检查/etc/udev/rules.d旧的 Stretch 时代 udev 的 NIC 命名规则,并将其注释掉或在可能的情况下完全删除它们。另请检查是否有任何适用的/etc/systemd/network/*.link文件:这些文件将是为 NIC 分配名称的最新方法。

诸如此类的名称eno0基于固件信息(也许是 DMI 数据?),该信息标识了内置网络接口的“物理”编号:显然,您的系统固件表示具有 PCI 路径的 NIC0000:02:00.1在您的系统板上标记为“0th”。

我知道enoX命名应该从那里开始eno1,数字应该从那里开始。eno0可能是固件定义错误:也许您当前的系统固件说网络接口是内置的,但接口的数量未定义。如果两个或多个 NIC 上的情况相同,则系统将尝试命名多个接口,但这eno0是行不通的。

/etc/systemd/network/20-builtins.link您可以通过创建包含以下内容的文件来覆盖命名方案:

[Match]
Path=pci-0000:02:*

[Link]
NamePolicy=slot

如果其他两个接口的 PCI 路径不是0000:02:*.*,那么您可能需要调整该Path=行,使其与所有接口匹配。这应该告诉系统停止尝试分配en0样式“内置 NIC”名称,并使用之前使用过的插槽样式名称。

相关内容