印度机房用 apt 升级内核，重启后网卡名从 eth0 变成 eno1

印度孟买机房的几台老 HP 服务器，Ubuntu 18.04 升到 20.04，顺手把内核从 4.15 带到 5.4。升级完不重启一切正常，ip a 还是 eth0、eth1，脚本里写死的网卡名也跑得好好的。等到周末维护窗口统一 reboot，两台机器直接失联，带外 console 进去一看，网卡变成了 eno1、eno2，配置文件里的 eth0 找不到，网络没起来。

做的事不复杂，先把 console 里能用的那块网卡临时拉起来：

ip link set eno1 up
ip addr add 10.x.x.21/24 dev eno1
ip route add default via 10.x.x.1
echo "nameserver 8.8.8.8" > /etc/resolv.conf

能 SSH 进去之后，先确认新名字和 MAC 的对应关系，别凭感觉改：

ip -o link show | awk '{print $2, $17}'
cat /etc/udev/rules.d/70-persistent-net.rules 2>/dev/null

然后改 netplan，把 eth0 换成 eno1，顺手把 renderer 写成 networkd，避免和老的 ifupdown 打架：

network:
  version: 2
  renderer: networkd
  ethernets:
    eno1:
      dhcp4: no
      addresses: [10.x.x.21/24]
      gateway4: 10.x.x.1
      nameservers:
        addresses: [8.8.8.8]

netplan apply 之后能通，再把脚本、监控、防火墙规则里所有 eth0 的引用一起替换掉，最后才 reboot 验证。

机制上，这是 systemd 的 predictable network interface names 在 5.x 内核加新版 udev 里默认生效，命名依据是固件里的 PCI 槽位和板载索引，所以同一块网卡在老内核下叫 eth0，新内核下叫 eno1。代价是机器上任何写死网卡名的地方都会在同一时刻一起失效，而且失效发生在重启之后，升级当时测不出来。

会失效的情况：一是只改了 netplan 没改 iptables/监控脚本里的 eth0，网络通了但规则没挂上；二是有机器 BIOS 里网卡顺序本来就不稳定，换槽位后 eno1、eno2 会互换，这种只能按 MAC 绑定，别按名字绑；三是容器或 KVM 里虚拟网卡不受这套命名影响，别拿物理机的经验去套。我自己就踩过第二条，两台同型号机器互换过 eno1 和 eno2，远程改完全部失联。

你们那边的老机器升级内核时，是直接关掉 predictable names 保持 eth0，还是把配置全部迁到新名字？关掉的话，后面加网卡会不会又遇到顺序问题？