CentOS 7 (dracut) 發現不一致的網路設備名稱導致 kickstart 出現問題

我使用引導選項biosdevname=1 net.ifnames=1以獲得一致、可預測的設備名稱。我開始注意到一個問題，在某些情況下，網路設備名稱不一致。例如，如果我進入 dracut 調試 shell 並查看 rdsosreport.txt 的輸出，我會看到：

+ ip addr
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
      valid_lft forever preferred_lft forever
   inet6 ::1/128 scope host
      valid_lft forever preferred_lft forever
2: p3p1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
   link/ether a8:b4:56:50:97:08 brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
   link/ether a8:b4:56:50:97:09 brd ff:ff:ff:ff:ff:ff

請注意，混合了一致 (p3p1) 和傳統風格 (eth1) 命名。但是，如果我查看 dracut 調試 shell 中的介面，我會看到：

initqueue:/run/initramfs# ip addr
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
      valid_lft forever preferred_lft forever
   inet6 ::1/128 scope host
      valid_lft forever preferred_lft forever
2: p3p1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
   link/ether a8:b4:56:50:97:08 brd ff:ff:ff:ff:ff:ff
3: p3p2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
   link/ether a8:b4:56:50:97:09 brd ff:ff:ff:ff:ff:ff

p3p1/p3p2 是正確的預期名稱。出於某種原因，在 initrd 序列的早期，它們以混合格式出現。我的假設是這裡正在進行某種比賽，並且給了更多時間，它（udev？）進入正確的狀態，但我不確定它到底在哪裡。不幸的是，這給我們的一些自動化伺服器建構帶來了問題，因為伺服器在（安裝後）首次啟動之後出現，並試圖eth1在真正的介面名稱為p3p2.

我一直在探勘 dracut 模組，試圖找出問題所在，但還不能最終確定，所以尋找建議。

此外，這種行為並非一直發生。相同的伺服器，啟動相同的映像有時可以正常工作，而有時會出現這種混合命名行為。這也告訴我這是某種比賽——有時比賽贏了，有時輸了。

在這裡回答我自己的問題。事實證明，這個問題（部分）是自己造成的。

我們無法控制的部分：

使用引導選項biosdevname=1有可能在介面重命名階段引起競爭。如果你可以沒有它，那麼簡單地使用net.ifnames=1 biosdevname=0可能會更可取，即使結果名稱“不太漂亮”。

我們可以控制的部分：

我們的網站使用自定義修改的 dracut40network模組。我們的版本所做的主要事情之一是它探索/sys/class/net/尋找可行介面以自動添加到綁定的內容。（我們並不總是事先知道設備名稱，這就是模組需要一些邏輯來自行辨識它們的原因）。上面提到的競爭可能會導致/sys/class/net/. 解決方案很簡單：在探測之前向腳本添加 5 秒睡眠/sys/class/net/。這給了biosdevname（希望綽綽有餘）時間來完成重命名設備。到目前為止的測試似乎 A-OK。

引用自：https://serverfault.com/questions/1068736