新增或刪除硬體時，不應變更可預測的網路介面名稱。這不是命名方案的全部意義嗎？
我的無線介面名為 wlp3s0。
我在空閒 PCI 插槽中安裝了 ASUS Xonar DX 7.1 通道 PCI Express x1 介面音效卡，並將無線介面名稱變更為 wlp5s0。
無線網路卡與安裝音效卡之前位於同一個 PCI 插槽中，那麼為什麼介面名稱會改變？
主機板是技嘉GA-970A-UD3，無線網路卡是華碩PCE-N15。該系統正在運行具有原生核心的 Arch Linux。
我正在尋找一個合理的解釋來解釋為什麼介面名稱會在這種情況下發生變化。如果沒有充分的理由更改介面名稱，我應該在哪裡提交錯誤報告/向誰投訴？
這不是什麼大問題，我需要更改的唯一配置是 netctl 的網路設定檔。我只是認為，如果「可預測」的網路介面名稱不可預測，那麼他們的工作就完全失敗了，而這個命名方案就是無用的垃圾！ /咆哮
答案1
新增或刪除硬體時，不應變更可預測的網路介面名稱。這不是命名方案的全部意義嗎？
長話短說，這並不是什麼新鮮事。這是預期的/有意的。因此，您不需要提交錯誤，除非您想要求您的 PC 製造商更好地支援 Linux (BIOS) 或硬體製造商（驅動程式）。如果您想改善熱插拔設備的情況和/或返回舊的命名方案，可以選擇一些選項：
net.ifnames=0使用內核命令列禁用網路設備的新命名方案- 新增
biosdevname=1核心命令列以將 BIOS 提供的索引號合併到名稱中 - 建立或編輯
udev自訂名稱或變更的命名方案的規則 - 您停用固定名稱的分配，以便再次使用不可預測的核心名稱。為此，只需為預設策略封鎖 udev 的 .link 檔案：
ln -s /dev/null /etc/systemd/network/99-default.link
如果您使用systemdand/or udev，「可預測命名方案」參數可能與先前不同。不過，根據 WiFi 介面的命名方案，我假設您是使用帶有systemd.
您可以嘗試將以下引導參數附加到核心命令列以使用網路裝置的「舊」命名約定。但是，我並不完全確定除了保留網路設備的命名方案之外，這可能還會產生什麼（如果有的話）額外影響。
net.ifnames=0
添加進去/etc/default/grub可以方便這個參數的持久化和重複使用；再次假設您正在使用grub2：
GRUB_CMDLINE_LINUX="net.ifnames=0"
如果udev在確定裝置名稱時使用裝置韌體、位置和其他選項，則位置或其他內容可能會在內部發生變化，具體取決於相關裝置如何相互互動。這裡似乎不太相關，因為這些設備是 WiFi 適配器和音效卡。不過，可能與底層匯流排結構有關；這看起來確實相關，因為這兩個裝置都連接到 PCI 插槽。
附加資訊來自Fedora文檔
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系統中除外，只要安裝了biosdevname，就會預設使用biosdevname。如果使用者新增了udev更改核心設備名稱的規則，則這些規則將優先。