根本原因是Netplan默认使用systemd-networkd作为渲染器，导致NetworkManager被绕过；需将Netplan配置中的renderer改为NetworkManager并重启服务。
nmcli device show 显示 unmanaged 怎么办
这是 Ubuntu 22.04+ 最常见的静态 IP 配置失败现象：你用 nmcli 配了地址，nmcli device show 却显示所有接口状态为 unmanaged，改完也重启不生效。
根本原因不是 NetworkManager 没装或没启，而是 Netplan 默认把控制权交给了 systemd-networkd，直接绕过了 NetworkManager。它甚至不读 /etc/NetworkManager/system-connections/ 下的任何配置。
- 先确认当前 renderer：
cat /etc/netplan/*.yaml | grep renderer—— 如果输出是renderer: networkd，那就对上了 - 检查实际运行的服务：
systemctl is-active systemd-networkd和systemctl is-active NetworkManager，通常前者 active，后者虽然 running 但被“静音” - 临时验证：运行
sudo systemctl stop systemd-networkd && sudo systemctl start NetworkManager，再看nmcli d是否变 managed（但重启后会回退）
netplan 配静态 IP 必须写的三个字段
Netplan 的 YAML 看似简单，但漏掉任意一个关键字段，netplan apply 就会静默失败或只配一半——比如地址生效但网关/ DNS 不走。
以有线接口 eth0 配 192.168.1.100/24 为例，最小可用配置必须包含：
-
addresses：必须带 CIDR，写成[192.168.1.100/24]，不能只写192.168.1.100 -
gateway4：IPv4 默认网关，不能写进routes里替代（旧文档容易误导） -
nameservers：必须显式声明，即使只配一个 DNS，也要写成addresses: [8.8.8.8]
完整示例片段：
network:
version: 2
renderer: networkd
ethernets:
eth0:
dhcp4: false
addresses: [192.168.1.100/24]
gateway4: 192.168.1.1
nameservers:
addresses: [8.8.8.8, 114.114.114.114]
想用 nmcli 就别碰 renderer: networkd
如果你明确要交互式管理网络（比如临时开热点、切 WiFi、改 VLAN），就别让 Netplan 把 renderer 设成 networkd。这不是功能限制，是设计冲突——systemd-networkd 是无状态、只读配置的守护进程，它不响应 D-Bus 请求，也不维护连接生命周期。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
正确做法是把 Netplan 改为驱动 NetworkManager：
- 编辑
/etc/netplan/*.yaml，把renderer: networkd改成renderer: NetworkManager - 删掉或注释掉
gateway4和nameservers字段（它们由 NM 自己处理更可靠） - 运行
sudo netplan apply，然后sudo systemctl restart NetworkManager - 之后所有操作交给
nmcli：比如nmcli connection modify "Wired connection 1" ipv4.addresses "192.168.1.100/24"
注意：renderer: NetworkManager 后，/etc/netplan/ 只起初始声明作用；后续修改必须用 nmcli，否则下次 netplan apply 会覆盖 NM 的运行时配置。
netplan try 为什么有时不回滚
netplan try 的本意是防止配错导致失联，但它依赖一个前提：你没动过底层服务状态。一旦你手动 systemctl restart systemd-networkd 或 nmcli connection down 过，netplan try 的超时检测就可能失效。
典型失效场景：
- 在 SSH 会话里执行
netplan try，但配置错误导致新连接无法建立，而旧连接因 TCP keepalive 超时断开 → 回滚触发前已失联 - 配置中混用了
dhcp4: true和addresses，netplan 语法校验通过，但systemd-networkd启动失败，try认为“没变化”，不回滚 - 使用
renderer: NetworkManager时，netplan try实际调用的是 NM 的临时连接，但 NM 本身没实现原子回滚，只能靠超时关闭临时连接
所以真要试配置，优先用本地终端或带 Console 的云平台；远程操作时，建议先 screen 或 tmux 套一层，再加 sleep 30 && sudo netplan apply 保底。
