systemd 的“可預測的介面名稱”不可預測
我在 Mac Pro 上作為 NAS / VM 主機執行 Debian 測試（核心 5.10.0-2-amd64 / systemd 247.2-5）。今天，我添加了一個 Thunderbolt 3 卡（Gigabyte Titan Ridge） - 並註意到一些奇怪的事情：Mac 的內置乙太網埠（enp9s0 / enp10s0）的網路標識符更改為 enp14s0/enp15s0，具體取決於我的 iMac 是否已連接並打開電源在啟動時通過 Thunderbolt。
這是什麼原因造成的？我認為“新”命名方案優於舊“ethX”的優勢在於設備名稱是可預測的。特別煩人，因為我必須在 GRUB 命令行中對介面名稱進行硬編碼，以便預引導 DHCP 工作，以便我可以解鎖加密的根磁碟，而且我還需要穩定的介面名稱來配置網橋。
（另外：boltctl 和 tbtadm 都不辨識卡或連接的設備，但核心可以辨識，並且網路連接工作正常。為什麼？）
這意味著這台機器上的硬體路由取決於是否有任何東西插入 Thunderbolt 插座。請記住，Thunderbolt 的邏輯介面是 PCIe，因此您實際上是將另一個設備插入電腦的系統匯流排。在你的 Mac 中，你碰巧在系統匯流排的中間插入了一些東西，所以它把所有東西都“推”到了更遠的地方。這就是 Apple 佈置硬體匯流排的方式；他們沒有為每個 Thunderbolt 埠保留一些設備編號池，甚至沒有將每個埠單獨計算為 PCI 匯流排，而是讓這些“埠”在系統中出現或消失，在一些內部列舉中將所有內容轉移到它們之外。
我在PC上也遇到過同樣的問題，網卡設備號取決於內置音效卡的情況：如果在BIOS設置中啟用了音效卡，它需要網卡設備號，然後網卡本身依次接收。這就是硬體在該機器上的佈局方式。向硬體設計人員提問，為什麼他們沒有設置“虛擬插槽中的設備”的切換狀態，並讓插槽本身出現或消失。
Systemd的方案有它的優點，但是它完全依賴於設備路徑，對於PCI來說就是它的設備號和功能；所以，如果設備號發生變化，systemd 認為這是另一張卡。因此，此方案與設備編號可能發生變化的環境無關，因此 USB 和 Thunderbolt 是可能出現故障的特殊地方。