我尽了最大努力，不寻求帮助就让它工作了。我搞不懂。我有一台有 6 个以太网端口的机器。我希望它们始终命名为 eth0 到 eth5，就像我们在 CentOS 6.5 中所做的那样。
在 CentOS 6.5 中，我们使用以下 udev 规则，使用 PCI 地址来精确指定每个接口分配的名称：
ACTION=="add", SUBSYSTEM=="net", IMPORT{program}="/lib/udev/rename_device"
KERNEL=="eth?", ACTION=="add", SUBSYSTEM=="net", BUS=="pci", ID=="0000:00:19.0", NAME="eth0"
KERNEL=="eth?", ACTION=="add", SUBSYSTEM=="net", BUS=="pci", ID=="0000:08:00.0", NAME="eth1"
KERNEL=="eth?", ACTION=="add", SUBSYSTEM=="net", BUS=="pci", ID=="0000:07:00.0", NAME="eth5"
KERNEL=="eth?", ACTION=="add", SUBSYSTEM=="net", BUS=="pci", ID=="0000:06:00.0", NAME="eth4"
KERNEL=="eth?", ACTION=="add", SUBSYSTEM=="net", BUS=="pci", ID=="0000:05:00.0", NAME="eth3"
KERNEL=="eth?", ACTION=="add", SUBSYSTEM=="net", BUS=="pci", ID=="0000:04:00.0", NAME="eth2"
SUBSYSTEM=="net", RUN+="/etc/sysconfig/network-scripts/net.hotplug"
我现在运行的是 CentOS 7.1，内核版本为 3.10.0-229.20.1.el7.x86_64。Systemd 目前正在此机器上运行。Systemd/udev 对以太网设备使用了一种新的持久且可预测的命名方法。
我已经尝试了该网站提供的所有建议：http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ 这应该是新 systemd/udev 设备命名方案的官方文档。
此页面底部列出了 3 种禁用新 systemd/udev 命名方案的方法：
- 您禁用固定名称的分配，以便再次使用不可预测的内核名称。为此，只需屏蔽 udev 的默认策略规则文件：ln -s /dev/null /etc/udev/rules.d/80-net-setup-link.rules
- 您可以创建自己的手动命名方案，例如，将接口命名为“internet0”、“dmz0”或“lan0”。为此，请在 /etc/systemd/network/ 中创建自己的 .link 文件，为一个、一些或所有接口选择一个明确的名称或更好的命名方案。有关更多信息，请参阅 systemd.link(5)。
- 您在内核命令行上传递 net.ifnames=0
我已尝试所有三种方法但仍然无法使其正常工作。
当我尝试选项 1 时，我仍然得到 enp0s25...enp4 接口名称。
当我尝试选项 2 时，我仍然会得到新的接口名称。
选项 3 让我更接近目标，但仍然不够接近。当我尝试选项 3 时，通过在启动时将 net.ifnames=0 添加到内核命令中，我通过 eth5 接口获得了 eth0。这很好，但它们是由内核自动命名的，并且它忽略了我的 udev 规则；60-net.rules 文件或 70-persistent-net.rules（关于文件应该命名的信息存在冲突）文件位于 /etc/udev/rules.d 中。
我的 60-net.rules 和 70-persistent-net.rules 文件都相同，如下所示：
-bash-4.2# cat 70-persistent-net.rules
ACTION=="add", SUBSYSTEM=="net", IMPORT{program}="/lib/udev/rename_device"
ACTION=="add", SUBSYSTEM=="net", BUS=="pci", ID=="0000:00:19.0", NAME="eth0"
ACTION=="add", SUBSYSTEM=="net", BUS=="pci", ID=="0000:04:00.0", NAME="eth2"
ACTION=="add", SUBSYSTEM=="net", BUS=="pci", ID=="0000:05:00.0", NAME="eth3"
ACTION=="add", SUBSYSTEM=="net", BUS=="pci", ID=="0000:06:00.0", NAME="eth4"
ACTION=="add", SUBSYSTEM=="net", BUS=="pci", ID=="0000:07:00.0", NAME="eth5"
ACTION=="add", SUBSYSTEM=="net", BUS=="pci", ID=="0000:08:00.0", NAME="eth1"
下面是一些输出，显示我的机器是如何组装的：
lspci | grep Ethernet
00:19.0 Ethernet controller: Intel Corporation 82567LM Gigabit Network Connection (rev 03)
04:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection
05:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection
06:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection
07:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection
08:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection
-bash-4.2# dmesg | grep eth
[ 6.978275] e1000e 0000:00:19.0 eth0: (PCI Express:2.5GT/s:Width x1) 00:01:05:0f:2a:a0
[ 6.986168] e1000e 0000:00:19.0 eth0: Intel(R) PRO/1000 Network Connection
[ 6.993044] e1000e 0000:00:19.0 eth0: MAC: 7, PHY: 8, PBA No: FFFFFF-0FF
[ 7.127337] e1000e 0000:04:00.0 ready
[ 478.016884] e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx
[ 478.024566] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 660.262275] e1000e: eth0 NIC Link is Down
[ 660.419098] e1000e: eth1 NIC Link is Down
[ 666.229161] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 666.404529] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
[ 668.474872] e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx
[ 668.482553] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 738.547269] e1000e: eth0 NIC Link is Down
[ 738.704105] e1000e: eth1 NIC Link is Down
[ 749.018153] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 749.195650] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
[ 751.264876] e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx
[ 751.272556] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 1003.295095] e1000e: eth1 NIC Link is Down
[ 1010.842662] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
[ 1555.995276] e1000e: eth0 NIC Link is Down
[ 1556.153100] e1000e: eth1 NIC Link is Down
[ 1562.076158] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 1562.267653] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
[ 1564.817867] e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx
[ 1564.825549] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 2349.926276] e1000e: eth0 NIC Link is Down
[ 2350.083101] e1000e: eth1 NIC Link is Down
[ 2356.570139] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 2356.754645] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
[ 2358.743867] e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx
[ 2358.751548] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 2535.460274] e1000e: eth0 NIC Link is Down
[ 2535.617098] e1000e: eth1 NIC Link is Down
[ 2541.570159] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 2541.756655] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
[ 2544.019877] e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx
[ 2544.027562] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
举个例子，您可以从我的自定义 udev 规则中看到，我希望将 eth1 专门分配给 PCI 地址 0000:08:00.0 处的接口。但在这里，您可以看到它实际上被分配给了 0000:04:00.0 处的接口，输出如下：
-bash-4.2# ethtool -i eth1
driver: e1000e
version: 3.2.4.2-NAPI
firmware-version: 1.6-0
bus-info: 0000:04:00.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: no
这是我的 /etc/udev/rules.d 目录的列表：
-bash-4.2# ls -l
total 12
-rw-r----- 1 root root 633 May 10 00:29 60-net.rules
-rw-r--r-- 1 root root 537 Dec 21 2015 70-persistent-net.rules
lrwxrwxrwx 1 root root 9 May 10 00:44 80-net-setup-link.rules -> /dev/null
-rw-r--r-- 1 root root 701 Dec 21 2015 net.rules.old
如您所见，我还创建了指向 /dev/null 的符号链接，以禁用 systemd/udev 命名方案。但这似乎对我没有任何作用。
我也尝试编辑 /usr/lib/udev/rules.d 中的 60-net.rules 文件，但这也没有任何作用。
在 /etc/sysconfig/network-scripts 中我有 ifcfg-eth0 和 ifcfg-eth1，但我将它们重命名为 ifcfg-ethx 和 ifcfg-ethx1，以确保它们不会妨碍工作。
每当我对任何文件进行更改时，我都会发出以下命令来应用更改：
udevadm control --reload-rules
modprobe e1000e
systemctl stop network
systemctl start network
但这似乎并没有真正起作用或应用我所做的任何更改。
我已经尝试了所有办法，但就是无法解决。我现在很绝望。任何建议都非常有用。
以下是一些其他信息：
-bash-4.2# udevadm info /sys/class/net/eth1
P: /devices/pci0000:00/0000:00:1c.3/0000:02:00.0/0000:03:01.0/0000:04:00.0/net/eth1
E: DEVPATH=/devices/pci0000:00/0000:00:1c.3/0000:02:00.0/0000:03:01.0/0000:04:00.0/net/eth1
E: ID_BUS=pci
E: ID_MODEL_FROM_DATABASE=82574L Gigabit Network Connection
E: ID_MODEL_ID=0x10d3
E: ID_NET_NAME_MAC=enx003059081853
E: ID_NET_NAME_PATH=enp4s0
E: ID_OUI_FROM_DATABASE=KONTRON COMPACT COMPUTERS AG
E: ID_PCI_CLASS_FROM_DATABASE=Network controller
E: ID_PCI_SUBCLASS_FROM_DATABASE=Ethernet controller
E: ID_VENDOR_FROM_DATABASE=Intel Corporation
E: ID_VENDOR_ID=0x8086
E: IFINDEX=5
E: INTERFACE=eth1
E: SUBSYSTEM=net
E: SYSTEMD_ALIAS=/sys/subsystem/net/devices/eth1
E: TAGS=:systemd:
E: USEC_INITIALIZED=27130
E: net.ifnames=0
您可以在此输出中看到，eth1 仍被分配给位于 PCI 地址 0000:04:00.0 的接口，并且 .link 文件也未被使用，因为没有显示 ID_NET_LINK_FILE 属性。
这是我的 10-eth1.link 文件在 /etc/systemd/network 中的示例。
-bash-4.2# cat 10-eth1.link
[Match]
OriginalName=enp4s0
Path=pci-0000:08:00.0-*
Driver=e1000e
[Link]
Name=eth1
答案1
我不是这方面的专家，但也许一些信息总比没有好。
我的理解是，使用标准 udev 基础架构无法实现这一点。Red Hat 的文档位于https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/networking_guide/sec-troubleshooting_network_device_naming似乎同意：
在下列情况下，使用 ethX 名称可以正确工作：
- 系统只有一个网络接口。
- 当用于 Red Hat Enterprise Linux 7 虚拟机客户机中的 virtio NIC 时。[...]
基本上，当您的系统启动时会发生以下情况：
- 内核通过eth分配eth0否接口名称。
- udev 规则稍后用于重命名这些接口，从 ethX为所需名称。
当步骤 2 中的规则尝试重命名到以太坊X名称在哪里X<=否，那么您很可能会因为命名冲突而收到错误。这是我在不同情况下收到的命名冲突错误，其中 BIOS 似乎指示我的两个接口应具有相同的名称：
systemd-udevd: could not rename interface '6' from 'eth0' to 'enp4s0': File exists
我确信，除了 eth0 到 eth，你可以随意调用你的接口否例如，如果您有坚持在接口名称上使用“eth”前缀的工具，除非您有大量的接口，否则“eth100”、“eth101”等应该是安全的。
也许一个解决方法是让 udev 将所有接口重命名为“other_eth0”之类的名称，然后让一个在系统启动时运行的服务重命名所有带有“other_”前缀的接口以删除这些前缀，尽管我脑子里不知道如何在 udev 规则之外进行接口重命名。
我很惊讶您在 CentOS 6 上成功使用了这些规则，因为我在 CentOS 6 上也遇到过类似的问题，无法为接口分配正确的名称，并且会给它们起“rename2”之类的名字。我在 CentOS 6 上使用了“eth100”、“eth101”等解决方案。