1. 问题背景为什么好好的网卡名非要改Ubuntu 20.04装完系统之后网卡名一般是类似enp3s0、ens33、eno1这种名字这是systemd的命名规范自动生成的。这套命名规则本身挺好——它根据网卡的物理位置、接口类型来确定名字保证系统重启之后网卡名不变避免多网卡环境下设备名漂移的问题。但实际工作中我就是遇见过必须把这玩意儿改成eth0的情况。最常见的场景是项目里跑了老旧的业务脚本或者是从别的发行版迁移过来的服务配置文件里写死了eth0这个名称有些网络监控系统、采集探针也是按eth0来采集流量的还有就是一些嵌入式设备、工控机项目客户的技术规范里明确要求网卡名必须是eth0。这种情况下与其去改一堆业务代码不如直接把网卡名改成eth0来得省事。另一个常见需求是把网卡改成有业务语义的名字比如改成wan0、lan1之类的。这里的原理和改eth0完全一样就是udev规则里NAME字段不同而已。这种操作在CentOS那套体系下很成熟毕竟CentOS 6/7的年代默认就叫eth0很多人习惯了。到了Ubuntu 20.04这里默认命名方式变了很多人就不知道怎么下手了。其实不管是哪套体系底层都是udev在管Ubuntu 20.04同样支持通过udev规则来定义网卡名称。这篇文章就是把我实际操作中的完整过程、踩过的坑、以及各种注意事项整理出来给有同样需求的同行做个参考省得再走弯路。2. 动手前的准备认清楚你的网卡再说2.1 查看当前网卡状态与名字改名字之前得先搞清楚这个系统里现在有哪些网卡、谁是物理网卡、谁是虚拟网卡。这一步做不好后面容易出现把网卡名改乱了的情况。ip addr show这是最直接的命令能看到当前所有网络接口的IP地址、状态、MAC地址。我一般还会配合用一下ip link这个命令简洁一点只看接口和它们的MAC地址、状态不显示IP。对于确认物理网卡数量这个更好用。如果你装了net-tools也可以直接ifconfig -a效果类似。以我手上一台测试服务器为例执行ip link之后输出大概是这样的1: lo: LOOPBACK,UP,LOWER_UP mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: enp3s0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000 link/ether 00:1e:06:xx:xx:xx brd ff:ff:ff:ff:ff:ff这里enp3s0就是我们要改的物理网卡后面的00:1e:06:xx:xx:xx是它的MAC地址。lo是回环接口这个东西别动它改了系统就出大事了。2.2 找准网卡的关键标识信息udev规则匹配网卡可以基于两个核心维度一个是通过MAC地址匹配另一个是通过网卡在总线上的物理位置。这两种方式各有优缺点实际使用中我会根据场景来选。MAC地址匹配的逻辑是这个网卡烧录在硬件里的地址是唯一的所以用它来定位网卡最准。但它有个问题——如果这个网卡只是临时插上去的替换了另一块同样型号的网卡MAC地址就变了规则就失效了。不过对服务器主板自带的网卡来说基本不存在换卡的问题MAC匹配是首选。总线位置匹配的逻辑是通过PCI总线地址、端口物理位置来确定网卡身份。比如enp3s0里的3代表PCI总线编号s0代表槽位。这种方式的好处是哪怕你换了同型号的新网卡只要插在同一个物理位置规则依然有效。缺点嘛笔记本、小型机里网卡挂在USB上的位置可能不稳定。那么怎么拿到MAC地址呢上面ip link的输出里已经有了就是link/ether后面那一串。如果你想用十六进制大写形式可以用cat /sys/class/net/enp3s0/address这个命令会纯粹输出一个MAC地址方便复制。如果想看网卡在PCI总线上的位置可以用udevadm info -a /sys/class/net/enp3s0这个输出比较长主要看下面几行looking at device /devices/pci0000:00/0000:00:1c.3/0000:03:00.0/net/enp3s0 ATTR{address} 00:1e:06:xx:xx:xx ATTR{dev_id} 0x0其中ATTR{address}就是MAC地址设备路径里的0000:03:00.0就是PCI总线地址。这些信息后面写udev规则的时候都能用到。还有个更直观的命令是ethtool -P不过它也是打印MAC地址和上面差不多而且必须要root权限。2.3 提前梳理网络配置的影响网卡改名不是光改个名就完事系统的网络配置是跟着名字走的。如果你现在用的是传统的/etc/network/interfaces配置里面写的是enp3s0那改名之后配置文件也得一起改。如果你用的是NetplanUbuntu 20.04默认那要改的是/etc/netplan/*.yaml里对应match的配置。这块一定提前规划好不然改完名网卡起不来远程连接直接断掉那就尴尬了。以Netplan为例默认的配置长这样network: version: 2 ethernets: enp3s0: dhcp4: true它用enp3s0这个名字做了配置块的标识。等网卡改名为eth0之后这个key也得改成eth0Netplan才会去配置它否则eth0就没法被正常拉起。不过这里有一个常见认知误区很多人以为改了udev规则网卡名变了IP配置就会自动跟着变。实际上完全不是这么回事udev只管硬件设备和名字之间的映射IP怎么配是你上层的网络配置工具管的。这两个东西是分开的两层不少新手就是栽在这个上面——改完udev规则、重启、发现网卡名是eth0了但IP没了就以为是udev规则写错了其实只是Netplan没改。3. 核心操作udev规则修改网卡名的完整流程3.1 为什么选udev规则这条路Ubuntu 20.04的网卡命名机制本质上是systemd-udevd在处理设备出现这件事时的默认策略。系统启动的时候udev会根据设备属性PCI位置、MAC地址等生成一个稳定的名字这个规则定义在/lib/udev/rules.d/目录下的各个规则文件里。注意/lib/udev/rules.d/这个目录是系统自带的你直接改里面的文件一是系统升级可能覆盖二是容易破坏系统本身的规则逻辑。正确做法是把自己的自定义规则放到/etc/udev/rules.d/目录。这个目录下的规则文件lexicographically按字母顺序会排在系统规则后面而且/etc目录是用户管理区不会被系统更新覆盖。我在实际中见过不少人在/lib/udev/rules.d/里直接改文件结果一升级系统改的东西全没了。这个做法一定不要学。还有个细节udev规则文件按照命名约定都是以数字开头比如70-persistent-net.rules。数字部分是规则的优先级数字越小越先执行。网卡命名规则一般建议用70-80之间的数字因为系统自带的网卡命名规则数字通常是70或更高你的规则要确保在上面有效。当然official Ubuntu 20.04里/lib/udev/rules.d/下有80-net-setup-link.rules这些文件所以你的自定义规则建议取名为70-persistent-net.rules或者85-custom-netname.rules都可以。我自己习惯用70-persistent-net.rules比较有辨识度一看就知道这是持久化网卡命名规则。3.2 编写基本的udev规则文件直接进入正题。新建一个规则文件sudo vim /etc/udev/rules.d/70-persistent-net.rules里面写这么一行SUBSYSTEMnet, ACTIONadd, ATTR{address}00:1e:06:xx:xx:xx, NAMEeth0我们来拆解一下这一行的语法。SUBSYSTEMnet限定只匹配网络子系统ACTIONadd限定在设备添加时应用ATTR{address}00:1e:06:xx:xx:xx用MAC地址精确定位到目标网卡NAMEeth0就是最终分配给设备的名称。这个匹配方式最保险因为MAC地址唯一不会误伤其他网卡。如果你更愿意用PCI地址来匹配写法可以改成SUBSYSTEMnet, ACTIONadd, KERNELS0000:03:00.0, NAMEeth0KERNELS匹配的是内核设备名就是前面udevadm info看到的PCI设备路径。注意这个KERNELS是带s的匹配的是包括父设备在内的整个内核设备链。不过说实话多数情况下用MAC地址匹配就够了简单不容易出错。还有一种情况如果你是想给所有网卡统一改成eth0编号比如有两块网卡一块叫eth0一块叫eth1那只写一条规则指定其中一块是eth0还不够另一块也需要单独写规则。否则另一块网卡可能被systemd默认规则命名成enxxx命名就不统一了。3.3 规则里可能遗漏的坑DRIVER匹配上面这个最简规则在大多数真实环境里能跑通但有一种情况会出问题某些虚拟网卡、USB网卡它们的MAC地址对应多个网络接口比如有些驱动会在同一块物理网卡上创建多个虚拟接口。这时候name分配可能会应用错。保险起见我通常会在规则里加上DRIVER匹配SUBSYSTEMnet, ACTIONadd, ATTR{address}00:1e:06:xx:xx:xx, DRIVERe1000e, NAMEeth0DRIVER的值怎么查还是用udevadmudevadm info -a /sys/class/net/enp3s0 | grep DRIVER一般能看到driver属性。加上这个匹配规则更严谨。不过你要是觉得麻烦只写MAC匹配也完全可行80%以上的场景够用。我一般建议先在测试机上最小化验证跑通了再逐步加匹配条件免得一次写复杂了排错困难。3.4 应用规则的两种姿势规则文件写好之后应用的方式有两种。第一种是最直接的重启系统。重启之后udev会在设备枚举阶段加载规则网卡名直接就变了。这种方式最省心但代价是服务中断时间长不适合生产环境。第二种是动态重载规则不需要重启sudo udevadm control --reload-rules这个命令让udev重新读取规则文件。但注意这个reload只影响后续发生的事件已经存在的网卡不会被重新命名。那么对于已经存在的网卡要怎么让规则生效呢可以手动触发一个removeadd事件。sudo udevadm trigger --actionadd --subsystem-matchnet实测下来对网卡设备触发add事件udev会重新评估命名规则。但这句话有个前提如果这个网卡接口已经被内核注册并且处于up状态单纯触发事件不一定能成功改掉名字。不少情况下需要先把这个接口down掉甚至有些内核版本直接拒绝rename正在使用的接口。这里给一个我先print down再trigger的脚本方案sudo ip link set enp3s0 down sudo udevadm control --reload-rules sudo udevadm trigger --actionadd --subsystem-matchnet触发完之后再看下ip link的输出确认名字是否变了。如果没变别慌张重启一下系统基本就正常了。3.5 验证改名是否成功验证步骤看起来简单一般就是查看接口状态ip link show eth0如果输出里存在eth0并且状态正常说明改名成功。再顺手检查一下ls -l /sys/class/net/这个目录下列出的应该有一个eth0而且它是一个指向实际设备目录的符号链接。如果这里面同时存在eth0和enp3s0两个说明udev创建了别名关系而不是重命名这就不对了。实际重命名后/sys/class/net/下应该同时存在eth0和enp3s0两个目录其中enp3s0是老名字eth0是新名字。具体关系可以看udevadm info /sys/class/net/eth0输出里应该会提到它对应的设备是原enp3s0的设备路径。出现这种两个名字都能访问的情况是正常的因为内核里接口实际被重命名后老的名字作为别名仍然存在一段时间但系统初始化脚本会以新名字为准。4. 常见问题与排查技巧实录4.1 规则写对了网卡名却没变这是我见过最多的问题。排查路径大概是这样第一步确认规则文件位置和命名无误。/etc/udev/rules.d/下的文件文件名必须以.rules结尾否则udev根本不会读。第二步确认权限。规则文件不需要可执行权限但所有者和组应该是root权限644就够了。有些人不小心写完保存后是root:root 644这是对的。如果因为编辑方式的问题导致文件权限混乱udev可能跳过加载。第三步检查udev有没有实际加载到你的规则。用这个命令udevadm info /sys/class/net/enp3s0输出里有一大堆属性信息如果规则被成功匹配输出中会多出ID_NET_NAME_PATH、ID_NET_NAME_SLOT这些与此同时会有一个ID_NET_NAME或者INTERFACE字段显示你的新名字。如果这些字段空着说明规则根本没匹配上回头检查匹配条件的写法。还有一种情况是规则匹配上了但有一个更高优先级的规则拦截了它。检查一下/etc/udev/rules.d/目录下有没有先于你的文件执行的规则看它的内容里有没有也定义了网卡名。比如有些云厂商镜像自带的规则优先级数字小于你的那你的规则就不生效了。解决办法是把你的规则文件名的数字改小一点比如从70改成60让它在优先级上胜出。4.2 远程连接断掉怎么办这几乎是改网卡名操作里最让人心跳加速的时刻。如果你是通过SSH远程操作这台服务器网卡名一旦改变IP地址可能跟着失效因为网络配置绑定的是旧名字SSH连接立刻断开。遇到这种情况不要慌先冷静想一下这台机器还能不能通过其他方式管理——带外管理面板如iDRAC、iLO、IPMI、KVMoverIP、还是控制台。有带外管理就进去把网络配置改好再重启网络服务。没有带外管理的物理机只能去机房现场接显示器和键盘操作了。所以我自己的实操习惯是改网卡名的操作永远不放在远程会话里做最后一步。而是先把一个crash-safe方案准备好比如写一个systemd服务或者cron任务在重启后若干分钟内如果检测到网络不通就自动回滚规则再把脚本拷贝到本地最后才执行规则修改和重启。生产环境里这一道保险非常值。实际操作层还有一个技巧用screen或tmux跑会话万一ssh断了重新连上去screen会话还活着操作进度不会丢。这个真的救过我一次。4.3 改名后网卡起不来之前提过udev规则只管命名不管IP。如果改名后网卡起不来先别怀疑udev规则问题而是要去看Netplan或者networking服务的配置。Netplan的情况下你原来的/etc/netplan/01-netcfg.yaml里写的是enp3s0。改名后要同步把配置块的key改成eth0。修改后执行sudo netplan apply如果Netplan配置没改eth0会是网卡存在但没有配置的裸状态。执行ip addr show eth0会发现它没有IP、状态为DOWN。还有一种情况如果系统里同时存在NetworkManager它可能也会接管网卡管理。Ubuntu 20.04服务器版默认不带NetworkManager但桌面版会带。NetworkManager的配置里也可能记录了旧网卡名需要手动清理。4.4 两条规则之间的竞争问题有时候你会在/etc/udev/rules.d/文件里放了两个规则都去匹配同一个网卡分别想给它不同的名字。这种情况的结果是先执行的规则生效后面的规则因为设备已经被重命名过udev可能会忽略或者报错。系统启动日志里通过journalctl能看到线索journalctl -u systemd-udevd -f这个命令实时跟踪udev日志。触发网卡reload之后日志里会显示类似network interface eth0 already exists这种报错说明有一个重复命名冲突。处理方式是检查自己写的规则文件保证每块网卡只匹配一次。或者如果确认规则有意覆盖系统的默认命名就保证你的规则文件名优先级数字低于系统默认规则。4.5 网卡被动刷新导致服务挂掉的心理预期管理最后说一个经验层面的东西。生产环境里改网卡名这个动作影响的不仅仅是网络配置一些依赖网卡名的服务也需要同步感知——firewalld的zone绑定、iptables规则的接口匹配、fail2ban的监接口、Nginx/Apache的listen指令、甚至一些写死在配置文件里的监控脚本。改完名一定要全局搜一遍配置文件里出现的旧网卡名grep -r enp3s0 /etc/ 2/dev/null把所有引用都找出来能改的改不能改的在文档里记录下来。这一步做完才算真正把网卡改名这个事完成了而不是改完ip link一显示eth0就万事大吉。5. 高能进阶把规则写成模板批量管理多网卡5.1 多网卡环境的规则设计一台服务器插了多块网卡的情况太常见了。比如一块板载千兆、一块PCIe万兆或者两块做bonding的千兆。如果只写一条MAC匹配规则其余网卡还是会被systemd自动命名结果就是割裂的命名体系eth0和enx00e0... 混着来。我的做法是把每块网卡都写成显式规则统一命名风格。SUBSYSTEMnet, ACTIONadd, ATTR{address}00:1e:06:aa:aa:aa, NAMEeth0 SUBSYSTEMnet, ACTIONadd, ATTR{address}00:1e:06:bb:bb:bb, NAMEeth1如果你有10块网卡那就写10条。虽然看起来有点笨但这套规则在任何机器上都是可预测、可复制的。做运维的都知道可预测比花哨重要一万倍。5.2 用脚本生成规则文件手动写规则很枯燥而且容易写错MAC。我自己习惯用一段小脚本来生成规则文件直接从/sys/class/net/读取所有物理网卡的信息自动生成udev规则。下面这段脚本会在当前目录生成一个netname.rules文件里面包含所有非回环网卡的MAC命名规则#!/bin/bash OUT_FILEnetname.rules : $OUT_FILE for iface in $(ls /sys/class/net/ | grep -v ^lo$); do mac$(cat /sys/class/net/$iface/address) if [ $mac 00:00:00:00:00:00 ]; then continue fi echo SUBSYSTEM\net\, ACTION\add\, ATTR{address}\${mac}\, NAME\rename_${iface}\ $OUT_FILE done cat $OUT_FILE这里我把新名字临时定成rename_当前名避免规则一加载就冲突。你跑完之后再把NAME字段改成你真正想要的名字。实际项目里我还会结合DMIDECODE信息把网卡物理位置比如onboard-1、pci-slot-1一起写进规则的注释里方便后续排查。规则文件支持#注释一定要养成写注释的好习惯半年后你就知道这个有多重要了。5.3 虚拟机与云环境的特殊注意事项在虚拟机VMware、VirtualBox、KVM和公有云环境里有一个非常大的坑很多虚拟网卡的MAC地址不是固定的比如VMware默认是自动分配云主机每次重建可能变化。如果你的udev规则绑定的是MAC一旦MAC变了规则就失配网卡名就回退成默认名。对于这类环境我建议优先使用PCI路径匹配毕竟虚拟机的PCI槽位相对固定。比如VirtualBox的网卡通常在0000:00:03.0这种位置改动频率比MAC低多了。但这又带来另一个问题虚拟机模板复制之后PCI路径可能不变但如果你在多个虚拟机里都用同一个PCI路径改成eth0那是没有任何冲突的因为各虚拟机之间硬件隔离不会串名。5.4 新内核的net naming scheme特性Ubuntu 20.04用的内核是5.4systemd-networkd提供了net.naming-scheme参数你可以通过内核启动参数来调整命名策略。有些发行版直接提供一个预设让命名回到类似eth0的风格比如在GRUB的kernel命令行里加net.ifnames0 biosdevname0加了这两个参数旧内核/旧systemd会直接放弃可预测命名退回到内核自动枚举的名字eth0、eth1这种。但要注意一个实际情况Ubuntu 20.04上仅仅加上net.ifnames0不能像CentOS那样透传生效因为systemd有它自己的策略可能需要配合biosdevname0一起加。实测中这个方案对某些板卡有用对某些就不太行。所以我的建议是如果你要的是确定性结果老老实实写udev规则如果你想快速试一下也可以先加内核参数看看但别指望它在所有硬件上都有效。说回到udev规则方案它和内核参数方案的另一个重要区别是udev规则是软件层面的重命名内核参数是改变命名策略本身两者互不冲突。如果你两个都做了udev规则的优先级通常会更高因为它是最后一步覆盖名字的。6. 实际案例复盘从enp3s0到eth0的完整操作记录这里放一次我真实操作的完整记录环境是Ubuntu 20.04.4 LTS服务器板载Intel I219-V网卡。6.1 操作前状态确认登录系统后我先确认了当前网卡状态$ ip link 1: lo: LOOPBACK,UP,LOWER_UP mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: enp3s0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000 link/ether 00:1e:06:5a:9b:2c brd ff:ff:ff:ff:ff:ff确认只有一块物理网卡enp3s0MAC是00:1e:06:5a:9b:2c。顺便确认了Netplan配置$ cat /etc/netplan/01-netcfg.yaml network: ethernets: enp3s0: dhcp4: true version: 26.2 编写规则并应用我先在/etc/udev/rules.d/目录下创建了规则文件$ sudo tee /etc/udev/rules.d/70-persistent-net.rules EOF # Rename onboard NIC to eth0 SUBSYSTEMnet, ACTIONadd, ATTR{address}00:1e:06:5a:9b:2c, NAMEeth0 EOF然后同步修改Netplan$ sudo tee /etc/netplan/01-netcfg.yaml EOF network: ethernets: eth0: dhcp4: true version: 2 EOF执行netplan apply之后先reload规则测试$ sudo udevadm control --reload-rules $ sudo ip link set enp3s0 down $ sudo udevadm trigger --actionadd --subsystem-matchnet然后查看结果$ ip link 1: lo: ... 2: eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000 link/ether 00:1e:06:5a:9b:2c ...网卡名直接从enp3s0变成了eth0整个过程没有重启系统。6.3 重启验证为了让结果更可靠我随后执行了reboot确认重启之后eth0依然稳定存在。重启后查看$ ip link show eth0 2: eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000 link/ether 00:1e:06:5a:9b:2c brd ff:ff:ff:ff:ff:ff $ ip addr show eth0 2: eth0: ... inet 192.168.1.100/24 ...IP地址也自动配置上来了说明Netplan改动生效。6.4 这个案例中的几个教训这个案例本身很顺利但同一个星期里我同事在另一台机器上出现了reboot后名字恢复成enp3s0的情况。查了半天发现他把规则文件放到了/lib/udev/rules.d/目录下而不是/etc/udev/rules.d/。系统升级后文件被删除或者覆盖了规则自然就丢了。还有个教训我在云主机上做过一次同样的操作但那台云主机的网卡MAC是由云平台动态分配的有一次迁移母机之后MAC变了规则就失配了eth0又变回了ens3。后来我把规则改成了通过PCI地址匹配才算稳定下来。所以——环境不同选型也要跟着变一个方案走天下是要吃药的。7. 与systemd-networkd、NetworkManager的协同问题刚才多次提到了上层网络管理工具这里专门梳理一下因为它们和udev规则的协同直接决定了你改完名之后能不能正常上网。7.1 Ubuntu 20.04下的网络栈体系Ubuntu 20.04默认用Netplan作为网络配置前端Netplan的renderer可以是networkdsystemd-networkd或者NetworkManager。服务器版默认renderer是networkd。Netplan的配置核心是它在/etc/netplan/*.yaml里定义网络结构然后生成对应的systemd-networkd或NetworkManager配置。udev的职责是在硬件层确定哪个接口叫什么名字。也就是说Netplan里写eth0前提是udev已经保证那块物理网卡确实叫eth0。两者是接力关系。所以改动完成的标准流程如下udev规则让物理设备获得稳定的名字eth0Netplan的ethernets块下用eth0作为key定义IP分配策略systemd-networkd根据Netplan生成的配置给eth0配置IP三层关系一层都不能缺。7.2 NetworkManager环境的特殊处理如果你的Ubuntu是桌面版或者你手动装了NetworkManager情况稍微不同。NetworkManager的配置也会记住接口名改名之后旧的连接配置可能失效。最简单的处理方式在NetworkManager里删除旧的连接配置让它重新自动创建sudo nmcli connection show sudo nmcli connection delete old-conn-name sudo systemctl restart NetworkManager重启后NetworkManager会发现新名字的eth0自动给它的有IP地址的接口重新生成连接配置。如果你走的是networking服务/etc/network/interfaces的老路那改动是这样的sudo sed -i s/enp3s0/eth0/g /etc/network/interfaces sudo systemctl restart networking7.3 为什么不建议改GRUB内核参数在讨论网卡改名时几乎总能听到有人推荐加net.ifnames0 biosdevname0这两个内核参数。这里我给一个中肯的评价。这个方案的本质是关闭可预测命名让内核用最原始的eth0、eth1枚举顺序来命名网卡。好处是操作简单只需要改GRUB配置然后重启坏处是——命名顺序取决于驱动的加载顺序和硬件探测顺序多网卡环境下非常不可控。你今天看到eth0是板载网卡明天加装一张PCIe网卡之后可能eth0就变成了新卡原来的板载网卡变成eth1了防火墙策略、监控脚本全部被打乱。udev规则用MAC或PCI地址精确绑定就不会出现这种漂移问题。所以我的态度很明确想快速实验内核参数可以试想要稳定可预测的结果老老实实写udev规则。生产环境我只推荐udev规则方案。8. 最后再分享一个小技巧网卡改名这个事操作本身不难难的是考虑周全。我最后分享一个自己常用的组合拳。改完udev规则和网络配置还没重启之前先做一个预检查脚本把关键信息都打印出来#!/bin/bash echo 网卡列表 ls /sys/class/net/ echo 当前所有接口详细状态 ip link echo udev规则文件 cat /etc/udev/rules.d/70-persistent-net.rules echo Netplan配置 find /etc/netplan -type f | xargs cat echo 当前生效路由 ip route把输出存到日志里。这样哪怕重启后出问题你手里有一份改动前基线可以做对比排错不至于抓瞎。另外改完规则之后我还会顺手跑一下这个命令确保没有语法错误udevadm test /sys/class/net/enp3s0这个命令会在不实际改名的前提下把udev对这个设备的所有匹配规则都跑一遍输出里会显示匹配到的规则文件名和行号。如果这里能看到你的70-persistent-net.rules行被匹配到了那基本就没问题了可以放心重启。我个人在这些操作上踩过的坑确实不少从名字漂移、配置同步遗漏、到远程断连每一样都经历过。现在每次给客户操作我都会坚持规则文件写在/etc、MAC绑定为主、Netplan同步、重启前预检查这四步。这套流程走下来踩坑率接近零。你照这个思路去操作Ubuntu 20.04下改网卡名也就是几分钟的事。
