添加或删除硬件时，不应更改可预测的网络接口名称。这不是命名方案的全部重点吗？？？

我的无线接口名为wlp3s0。

我在空闲的PCI插槽中安装了ASUS Xonar DX 7.1通道PCI Express x1接口声卡，并且我的无线接口名称更改为wlp5s0。

无线卡与安装声卡之前的插槽位于同一PCI插槽中，那么为什么接口名称会更改？

主板是GIGABYTE GA-970A-UD3，无线网卡是ASUS PCE-N15。系统正在运行带有储备内核的Arch Linux。

我正在寻找一个合理的解释，说明为什么在这种情况下接口名称会更改。如果没有充分的理由更改接口名称，该在哪里提交错误报告/向谁投诉？

没什么大不了的，我唯一需要更改的配置就是我的netctl网络配置文件。我只是认为，如果“可预测的”网络接口名称是不可预测的，那么他们将在工作中完全失败，并且这种命名方案是无用的垃圾！/ rant

添加或删除硬件时，不应更改可预测的网络接口名称。这不是命名方案的全部重点吗？？？

长话短说，这并不新鲜。这是预期/预期的。因此，除非您想让您的PC制造商更好地支持Linux（BIOS）或硬件制造商（驱动程序），否则无需提交bug。如果您想改善热插拔设备的状况和/或返回旧的命名方案，可以使用一些选项：

• 禁用带有net.ifnames=0内核cmdline的网络设备的新命名方案
• 添加biosdevname=1内核命令行以将BIOS提供的索引号合并到名称中
• 创建或编辑udev自定义名称或更改命名方案的规则
• 您禁用固定名称的分配，以便再次使用不可预测的内核名称。为此，只需将udev的.link文件屏蔽为默认策略：ln -s /dev/null /etc/systemd/network/99-default.link

如果您使用systemd和/或udev，则“可预测的命名方案”参数可能与以前有所不同。基于WiFi接口的命名方案，不过，我假设你正在使用系统systemd。

您可以尝试将以下引导参数附加到内核命令行，以使用网络设备的“旧”命名约定。但是，我不确定是否会保留网络设备的命名方案，否则可能会产生其他影响。

net.ifnames=0

将其添加到/etc/default/grub可以促进该参数的持久性和重用；再次，假设您正在使用grub2：

GRUB_CMDLINE_LINUX="net.ifnames=0"

如果udev在确定设备名称时使用设备固件，位置和其他选项，则位置或其他内容可能在内部已更改，具体取决于相关设备之间的交互方式。这似乎无关紧要，因为设备是WiFi适配器和声卡。但是，它可能与基础总线结构有关；看起来确实相关，因为设备都连接到PCI插槽。

来自FedoraDocs的其他信息

8.1。命名方案层次结构

默认情况下，systemd将使用以下策略来命名接口以应用支持的命名方案：

• 方案1：如果固件或BIOS中的信息适用且可用，则应用包含固件或BIOS为板载设备提供的索引号的名称（例如：eno1），否则使用方案2。

• 方案2：如果固件或BIOS中的信息适用且可用，则应用包含固件或BIOS提供的名称的PCI Express热插拔插槽索引号（例如：ens1），否则，返回方案3。

• 方案3：如果适用，则应用包含硬件连接器物理位置的名称（例如：enp2s0），否则在所有其他情况下都直接返回到方案5。

• 方案4：包含接口的MAC地址的名称（例如：enx78e7d1ea46da）在默认情况下不使用，但如果用户选择，则可用。

• 方案5：如果所有其他方法均失败，则使用传统的不可预测的内核命名方案（例如：eth0）。

上面概述的过程是默认策略。如果系统启用了biosdevname，将使用它。请注意，启用biosdevname要求biosdevname=1作为命令行参数传递，但对于Dell系统除外，在Dell系统中，默认情况下，只要已安装biosdevname就会使用它。如果用户添加了udev更改内核设备名称的规则，则这些规则将优先。

其他资源

• 关于AskUbuntu的问答
• 编写udev规则：示例
• ArchWiki：udev
• Systemd：可预测的网络接口名称