Ubuntu 18.04升级实战：系统级兼容性检查与故障排错指南

1. 这不是“一键升级”，而是系统级手术：为什么 Ubuntu 18.04 升级必须亲手把关

Ubuntu 18.04 Bionic Beaver 是一个典型的 LTS（长期支持）版本，官方支持周期长达 5 年（2018.04–2023.04），其内核、GCC 工具链、systemd 和 Python 生态的组合，在嵌入式开发、ROS 机器人平台、边缘计算节点和遗留服务器环境中至今仍有大量真实部署。我去年在维护一套基于 RK3399 的工业网关时，就遇到过客户坚持用 16.04，但新接入的 Modbus TCP 网关固件只提供 18.04+ 的 .deb 包——这时“升级”不是可选项，而是交付闭环的硬性前提。但很多人误以为 do-release-upgrade 是个黑盒魔法，点一下就完事。实则不然：它本质是一场覆盖内核、initrd、grub 配置、APT 源、systemd 单元、用户空间库 ABI 兼容性的全栈协同演进。我见过太多人跳过预检直接执行，结果卡在 libc6 升级阶段导致 SSH 断连、 apt 崩溃、甚至 /usr/bin/dpkg 二进制被覆盖为损坏版本，最终只能靠 Live USB 进 Rescue 模式手动恢复。这不是危言耸听，而是 Ubuntu 升级机制中一个被严重低估的底层事实： do-release-upgrade 不是安装新系统，而是原地重构整个运行时根基；它不保证向前兼容，只承诺向后兼容——而你的旧服务、自编译模块、第三方驱动，恰恰是“向前”的那部分 。所以本文不讲“怎么点下一步”，而是带你拆开这个升级器的外壳，看清每个齿轮如何咬合、哪里会打滑、哪些螺丝必须提前拧紧。你将真正理解：为什么 sudo apt-get update && sudo apt-get dist-upgrade 必须在升级前跑满两遍？为什么 /etc/apt/sources.list 里的 bionic-security 和 bionic-updates 顺序不能颠倒？为什么 dpkg --configure -a 在升级中途失败时，绝不能简单 apt --fix-broken install ？这些细节，决定了你是顺利切到新内核，还是在 initramfs 里反复重启。

2. 升级前的七道安检：从硬件兼容性到 APT 源指纹校验

升级不是从 do-release-upgrade 命令开始的，而是从你按下 Ctrl+Alt+T 打开终端前的物理检查开始。我经手过的 37 个 Ubuntu 升级项目中，有 11 个在第一关就卡住——不是软件问题，而是硬件或环境准备不足。下面这七步，每一步都对应一个真实踩坑案例，且全部可验证、可量化、可回溯。

2.1 内存与磁盘空间：别让升级器在解压 initrd 时静默死亡

Ubuntu 18.04 升级过程需要至少 2.5GB 可用内存 （非 swap）和 15GB 可用磁盘空间 （/ 分区）。这不是官方文档的保守值，而是我在 VMware Workstation 16.2 + 4GB RAM 虚拟机中实测的临界点。当内存低于 2GB 时， unshare 进程会因 OOM Killer 被杀，导致 apt 子进程异常退出，日志里只显示 E: Sub-process /usr/bin/dpkg returned an error code (1) ，毫无上下文。更隐蔽的是磁盘空间： /var/cache/apt/archives/ 目录在升级过程中会临时存放所有新包（约 1.2GB），而 /boot 分区若小于 500MB，新内核镜像（ vmlinuz-4.15.0-20-generic ）和 initrd（ initrd.img-4.15.0-20-generic ）写入失败会导致 GRUB 启动项缺失。验证方法极简：

# 检查内存（排除 swap）
free -h | awk '/^Mem:/ {print $2}'

# 检查 / 和 /boot 可用空间（单位：GB）
df -h / /boot | awk 'NR==2 {print $4}' | sed 's/G//'

# 检查 /var/cache/apt/archives 是否有足够空间（需 ≥1.5GB）
du -sh /var/cache/apt/archives/ | cut -f1

提示：如果 /boot 空间不足，不要盲目 apt autoremove 。先用 dpkg -l | grep linux-image | awk '{print $2}' | sort -V | tail -n 5 查看最近 5 个内核，再 sudo apt purge linux-image-4.13.0-xx-generic 清理最老的（注意保留当前运行的和上一个稳定版）。

2.2 内核与硬件驱动兼容性：ARM 板卡和 NVIDIA 显卡的双重雷区

Ubuntu 18.04 默认搭载 Linux 4.15 内核，对硬件支持有明确边界。RK3399 开发板若使用主线内核 4.4，升级后可能丢失 GPU 加速（Mali T860 驱动未合并进 4.15）；而 NVIDIA GTX 1080 用户若装的是 nvidia-384 驱动（为 16.04 编译），升级后 nvidia-smi 会报 Failed to initialize NVML: Driver/library version mismatch 。这不是驱动没装，而是 nvidia-kernel-source-384 的 DKMS 模块在 4.15 内核下编译失败， /lib/modules/4.15.0-xx-generic/updates/dkms/ 下无 nvidia.ko 。验证方案分两路：

• ARM 板卡 ：运行 uname -r 确认当前内核，再查 Ubuntu Kernel Support Matrix 确认该内核是否原生支持你的 SoC。RK3399 对应 rockchip 子系统，4.15 内核已包含基础支持，但若你用的是厂商定制 BSP（如 FriendlyElec 的 linux-rockchip-4.4 ），必须提前切换到主线分支。

• NVIDIA 显卡 ：执行 nvidia-smi -q | grep "Driver Version" 获取驱动版本，再查 NVIDIA Driver Support Matrix 确认该驱动是否支持 4.15+ 内核。若不支持，必须在升级前卸载旧驱动： sudo /usr/bin/nvidia-uninstall ，并记录 nvidia-settings --version 输出，以便升级后重装匹配版本。

2.3 APT 源状态与 GPG 密钥指纹： apt-get update 成功≠源可用

sudo apt-get update 返回 0 只代表源列表语法正确、网络可达，不代表所有仓库都健康。Ubuntu 18.04 升级要求 archive.ubuntu.com 和 security.ubuntu.com 的 bionic 源必须 100% 可达且签名有效。我曾在一个企业内网环境发现： apt-get update 成功，但 do-release-upgrade 卡在 Checking for a new Ubuntu release 15 分钟不动。抓包发现 http://changelogs.ubuntu.com/meta-release-lts 返回 404，因为该 URL 在 16.04 时代指向 meta-release ，而 18.04 升级器强制校验 meta-release-lts 。根本原因是内网镜像站未同步该文件。解决方案是绕过远程校验，改用本地元数据：

# 下载官方 meta-release-lts 到本地
sudo wget -O /var/lib/update-manager/meta-release-lts http://changelogs.ubuntu.com/meta-release-lts

# 强制升级器读取本地文件
sudo do-release-upgrade -d -f DistUpgradeViewNonInteractive

更关键的是 GPG 密钥。 /etc/apt/trusted.gpg.d/ubuntu-keyring-2012-cdimage.gpg 若损坏， apt-get update 会报 NO_PUBKEY ，但升级器可能忽略此错误继续。验证命令：

# 检查所有 Ubuntu keyring 是否有效
for f in /etc/apt/trusted.gpg.d/ubuntu*.gpg; do 
  gpg --list-packets "$f" 2>/dev/null | grep -q "keyid" && echo "OK: $f" || echo "BROKEN: $f"
done

若输出 BROKEN ，立即修复： sudo apt install --reinstall ubuntu-keyring 。

2.4 第三方仓库与 PPA 的“断崖式”失效风险

任何启用的第三方仓库（如 deb http://ppa.launchpad.net/webupd8team/java/ubuntu xenial main ）在升级到 18.04 后，若未提供 bionic 支持， apt 会直接报错 E: The repository 'http://ppa.launchpad.net/xxx/ubuntu bionic Release' does not have a Release file. 。这不是警告，而是致命错误，升级器会中止。但更危险的是“静默失效”：某些 PPA（如 ros-shadow-fixed ）虽提供 bionic 源，但其包依赖 libboost1.58-dev ，而 18.04 默认是 libboost1.65-dev ，导致 ros-core 安装失败，进而引发 rosdep 初始化中断。排查方法必须手工执行：

# 列出所有启用的第三方源
grep -r "^deb.*ubuntu.com\|^deb.*launchpad.net" /etc/apt/sources.list*

# 对每个源，构造 bionic URL 并测试 HTTP 状态码
while read line; do 
  if echo "$line" | grep -q "xenial\|artful"; then
    url=$(echo "$line" | sed 's/xenial/bionic/g' | sed 's/artful/bionic/g' | awk '{print $2}')
    echo "Testing: $url"
    curl -I -s -o /dev/null -w "%{http_code}\n" "$url"
  fi
done < <(grep -r "^deb" /etc/apt/sources.list*)

注意：若某 PPA 无 bionic 分支，不要强行修改 sources.list 。正确做法是 sudo add-apt-repository --remove ppa:xxx/yyy 彻底禁用，待升级完成后再评估是否重装。

2.5 systemd 服务与自定义脚本的 ABI 兼容性

Ubuntu 18.04 将 systemd 从 229 升级至 237，带来关键行为变更： RestartSec= 参数现在支持毫秒级精度（如 RestartSec=500ms ），而旧版只接受秒； PrivateTmp=true 默认启用，导致 /tmp 下的 socket 文件路径隔离。如果你的服务脚本（如 /etc/systemd/system/myapp.service ）里写了 ExecStartPre=/bin/bash -c 'touch /tmp/myapp.sock' ，升级后该 socket 将创建在私有命名空间，主进程无法访问。验证方法是检查所有自定义 service 文件：

# 查找所有非 Ubuntu 官方的 service 文件
find /etc/systemd/system/ /lib/systemd/system/ -name "*.service" -not -path "/lib/systemd/system/*.ubuntu*" | while read f; do
  echo "=== $f ==="
  # 检查是否含 PrivateTmp 或 RestartSec=xxxms
  grep -E "(PrivateTmp|RestartSec=.*ms)" "$f" && echo "⚠️  需人工审查"
  # 检查 ExecStartPre/Post 中是否硬编码 /tmp 路径
  grep -E "ExecStart(Pre|Post)=.*\/tmp\/" "$f" && echo "⚠️  /tmp 路径风险"
done

2.6 用户空间库的 ABI 断裂点： libc6 升级的不可逆性

libc6 是 GNU C 库，所有用户程序的基石。16.04 使用 libc6 2.23 ，18.04 升级至 libc6 2.27 。ABI（应用二进制接口）虽保持向后兼容，但存在两个断裂点：一是 getaddrinfo_a 函数在 2.27 中被标记为 deprecated，某些旧版 Go 程序（<1.10）链接时会失败；二是 malloc 实现变更，导致某些用 LD_PRELOAD 注入内存分配器的监控工具（如 jemalloc 4.5）崩溃。验证你的关键程序是否受影响：

# 检查所有 /usr/local/bin/ 下的二进制是否链接 libc6 2.23
for bin in /usr/local/bin/*; do 
  [[ -f "$bin" ]] && ldd "$bin" 2>/dev/null | grep -q "libc.so.6" && echo "$bin: $(ldd "$bin" | grep "libc.so.6" | awk '{print $3}')"
done

# 检查是否使用 jemalloc（常见于 Redis、Nginx 插件）
ldd /usr/bin/nginx | grep jemalloc

若发现 libc.so.6 => /lib/x86_64-linux-gnu/libc-2.23.so ，说明该程序是为 16.04 编译，升级后需重新编译或替换为静态链接版本。

2.7 备份策略：不是拷贝整个 / ，而是锁定三类黄金数据

备份不是 tar -czf backup.tgz / ，那是灾难。Ubuntu 升级后 /etc/ 、 /var/lib/dpkg/ 、 /boot/ 会被深度修改，但你的业务数据（如 /var/www/html/ ）、配置快照（ /etc/ 的 diff）、以及 dpkg 状态数据库（ /var/lib/dpkg/status ）才是黄金备份点。我推荐三级备份法：

1. 业务数据层 ： rsync -av --delete /var/www/ /backup/www/
2. 配置快照层 ： sudo tar -cf /backup/etc-$(date +%Y%m%d).tar /etc/ （注意：不压缩，确保 tar -tf 可快速校验）
3. 包状态层 ： sudo cp /var/lib/dpkg/status /backup/dpkg-status-$(date +%Y%m%d)

关键技巧：备份前执行 sudo dpkg --get-selections > /backup/dpkg-selections-$(date +%Y%m%d) 。这是比 status 文件更轻量、更易读的包状态快照，升级失败后可快速 sudo dpkg --set-selections < selections.txt && sudo apt-get dselect-upgrade 恢复。

3. 升级执行链： do-release-upgrade 的五个阶段与每个阶段的“心跳监测”

do-release-upgrade 不是一个原子命令，而是由 DistUpgradeController 驱动的五阶段流水线。每个阶段都有明确的入口、出口和失败回滚点。理解这些阶段，等于掌握升级器的“心电图”，能在异常时精准定位病灶。

3.1 阶段一：元数据获取与发行版校验（耗时 30–120 秒）

此阶段执行 fetchMetaRelease() ，从 http://changelogs.ubuntu.com/meta-release-lts 下载发行版元数据，解析 JSON 格式的升级路径。关键校验点有三：

• 路径合法性 ：确认 Current 字段为 xenial （16.04）， UpgradeTool 指向 ubuntu-release-upgrader-core 包， Prompt 为 lts 。
• 时间窗口 ： Date 字段必须早于当前日期，否则拒绝升级（防止回滚到旧版）。
• GPG 签名 ：元数据文件附带 .gpg 签名， gpg --verify meta-release-lts.gpg meta-release-lts 必须返回 Good signature 。

若卡在此阶段，90% 是网络或 DNS 问题。诊断命令：

# 手动下载并校验元数据
wget -O /tmp/meta-release-lts http://changelogs.ubuntu.com/meta-release-lts
wget -O /tmp/meta-release-lts.gpg http://changelogs.ubuntu.com/meta-release-lts.gpg
gpg --verify /tmp/meta-release-lts.gpg /tmp/meta-release-lts

若 gpg 报 no valid OpenPGP data found ，说明签名文件损坏，需 sudo apt install --reinstall ubuntu-keyring 。

3.2 阶段二：包依赖图构建与冲突检测（耗时 5–20 分钟）

此阶段调用 apt_pkg.Cache() 构建完整的依赖图，核心是 apt_pkg.DepCache 类的 init() 方法。它会：

• 解析所有 bionic 源中的 Packages.gz ，生成 Package 对象树；
• 计算每个包的 CandidateVersion （候选版本），即 bionic 源中最高可用版本；
• 执行 apt_pkg.DepCache.broken_count 统计冲突数，若 >0 则终止。

最常见的冲突是 python3 相关：16.04 的 python3.5 与 18.04 的 python3.6 共存时， python3-distutils 包会因 Conflicts: python3.5-distutils 报错。此时 do-release-upgrade 会输出：

Could not calculate the upgrade
An unresolvable problem occurred while calculating the upgrade.
Please report this as a bug.

但日志 /var/log/dist-upgrade/main.log 里有真凶：

2023-01-15 10:23:45,123 DEBUG Broken packages: python3-distutils, python3.5-distutils

解决方案不是跳过，而是强制降级冲突包：

sudo apt install python3.5-distutils=3.5.3-1~16.04.1
sudo do-release-upgrade -f DistUpgradeViewNonInteractive

3.3 阶段三：下载与预配置（耗时 15–60 分钟，取决于带宽）

此阶段并行下载所有新包（约 1200+ 个），同时执行 preInstall() 钩子。关键动作：

• 下载队列管理 ： apt_pkg.Acquire 类启动多线程下载，最大并发数由 /etc/apt/apt.conf.d/70debconf 中的 Acquire::http::Max-Threads "20"; 控制；
• 预配置脚本执行 ：对每个包，运行 dpkg --preconfigure ，触发 postinst 脚本的 configure 阶段（如 grub-pc 会弹出交互式配置界面）；
• 磁盘空间预检 ：调用 apt_pkg.GetCache().get_disk_usage() 计算所需空间，若不足则报错 Not enough free disk space 。

若下载中断， /var/cache/apt/archives/partial/ 中的 .deb 文件不会自动清理，下次运行会续传。但若 dpkg --preconfigure 失败（如 grub-pc 配置超时）， /var/lib/dpkg/info/grub-pc.config 会残留，导致后续 dpkg --configure -a 卡死。此时必须：

# 强制清除 grub-pc 的配置状态
sudo dpkg --purge --force-all grub-pc
sudo apt install grub-pc

3.4 阶段四：核心包安装与 dpkg 批处理（耗时 10–30 分钟）

此阶段是真正的“刀锋时刻”，调用 dpkg --install 批量安装新包，并执行 postinst 。关键风险点：

• libc6 安装顺序 ： libc6 必须是第一个安装的包，否则 dpkg 自身会因 ABI 不匹配崩溃。升级器通过 apt_pkg.Cache().get_provides("libc6") 确保其优先级最高。
• init-system-helpers 更新 ：此包更新 /usr/lib/init-system-helpers ，影响所有 systemd 单元。若失败， systemctl daemon-reload 会报 Failed to connect to bus 。
• grub-efi-amd64-signed 安装 ：UEFI 系统必须成功安装此包，否则重启后黑屏。它依赖 sbsign 工具，若 /usr/bin/sbsign 不存在，会静默失败。

监控此阶段的唯一可靠方式是实时跟踪 dpkg 日志：

# 在新终端中实时查看 dpkg 操作
sudo tail -f /var/log/dpkg.log | grep -E "(install|configure|triggered)"

若看到 install libc6:amd64 <none> 后无后续，立即 sudo ps aux | grep dpkg ，若 dpkg 进程僵死，执行 sudo kill -9 $(pgrep dpkg) ，然后 sudo dpkg --configure -a 。

3.5 阶段五：清理与重启准备（耗时 2–5 分钟）

此阶段执行 cleanUp() ，包括：

• apt autoremove 清理旧内核和废弃包；
• update-grub 重建 GRUB 配置；
• update-initramfs -u 更新 initrd；
• systemctl daemon-reload 重载 systemd 单元。

最关键的检查点是 update-grub 输出是否包含 Found linux image: /boot/vmlinuz-4.15.0-20-generic 。若无此行，说明新内核未被 GRUB 识别，需手动 sudo grub-mkconfig -o /boot/grub/grub.cfg 。

实操心得：升级完成后，不要立即 reboot 。先执行 sudo systemctl list-units --state=failed ，确认无失败服务；再 sudo dmesg | grep -i "error\|fail" ，检查内核日志；最后 ls -l /boot/ ，确认 vmlinuz-4.15* 和 initrd.img-4.15* 文件存在且大小 >20MB（小于 10MB 说明 initrd 生成失败）。

4. 升级后的九项必验清单：从内核启动到 Docker 容器运行

升级完成不等于成功，只有通过这九项验证，才能确认系统已真正“活”在 18.04 上。每一项都对应一个真实故障场景，且全部可自动化脚本化。

4.1 内核与启动项验证： uname -r 和 grub-reboot 的双重确认

uname -r 显示 4.15.0-20-generic 仅说明内核已加载，不证明它是默认启动项。必须验证 GRUB 默认项：

# 查看当前默认启动项索引
sudo grep "GRUB_DEFAULT=" /etc/default/grub

# 若为数字（如 GRUB_DEFAULT=0），则检查 /boot/grub/grub.cfg 中第 0 项是否为 4.15
sudo grep -A 5 "menuentry.*4.15" /boot/grub/grub.cfg | head -n 1

# 若为 saved，则检查 saved_entry
sudo grub-editenv list

若 saved_entry 不是 Ubuntu, with Linux 4.15.0-20-generic ，执行：

sudo grub-reboot "Ubuntu, with Linux 4.15.0-20-generic"
sudo reboot

4.2 APT 源自动切换验证： sources.list 的 bionic 替换是否彻底

升级器会自动将 /etc/apt/sources.list 中的 xenial 替换为 bionic ，但常遗漏 security.ubuntu.com 和 updates.ubuntu.com 。验证脚本：

# 检查所有源是否为 bionic
grep -E "(deb|deb-src).*ubuntu.com" /etc/apt/sources.list /etc/apt/sources.list.d/*.list 2>/dev/null | \
  grep -v "bionic" && echo "❌ 发现非 bionic 源！" || echo "✅ 所有源已切换"

# 检查是否启用了 bionic-security（必须存在）
grep -q "bionic-security" /etc/apt/sources.list && echo "✅ security 源已启用" || echo "❌ security 源缺失"

若发现 xenial 残留，手动替换： sudo sed -i 's/xenial/bionic/g' /etc/apt/sources.list 。

4.3 systemd 版本与单元状态： systemctl status 的隐藏陷阱

systemd --version 返回 237 仅说明二进制版本，不保证所有单元正常。必须检查 systemd-journald 和 systemd-logind 是否 active：

# 检查核心守护进程
for svc in systemd-journald systemd-logind systemd-networkd; do
  systemctl is-active --quiet "$svc" && echo "✅ $svc active" || echo "❌ $svc inactive"
done

# 检查是否有 masked 单元（升级器可能因冲突 mask 掉）
systemctl list-unit-files --state=masked | grep -q "mask" && echo "⚠️  存在被 mask 的单元，需审查"

若 systemd-logind inactive，通常因 /etc/pam.d/common-auth 中 pam_systemd.so 行被注释，需取消注释。

4.4 Python 3.6 环境验证： python3 --version 与 pip3 的 ABI 对齐

Ubuntu 18.04 默认 python3 指向 python3.6 ，但 pip3 可能仍为 pip 9.0.1 （16.04 版本），与 python3.6 的 distutils 不兼容。验证：

# 检查 python3 和 pip3 版本
python3 --version  # 应为 3.6.x
pip3 --version     # 应为 18.0+

# 检查 pip3 是否能安装包（关键测试）
pip3 install --upgrade --dry-run setuptools 2>/dev/null && echo "✅ pip3 正常" || echo "❌ pip3 异常"

若 pip3 异常，重装： sudo apt install --reinstall python3-pip 。

4.5 Docker CE 安装验证： sudo apt-get install docker.io 的兼容性补丁

docker.io 包在 18.04 中默认安装 docker-ce=18.06.1~ce~3-0~ubuntu ，但若你之前装过 docker-engine ，其 dockerd 二进制会残留，导致 systemctl start docker 失败。验证：

# 检查 docker 服务状态
sudo systemctl is-active --quiet docker && echo "✅ docker 服务运行" || echo "❌ docker 服务未运行"

# 检查 dockerd 进程是否为 CE 版本
ps aux | grep dockerd | grep -v grep | grep -q "docker-ce" && echo "✅ dockerd 为 CE 版本" || echo "❌ dockerd 非 CE 版本"

# 若失败，强制清理旧引擎
sudo apt purge docker-engine docker.io
sudo rm -rf /var/lib/docker
sudo apt install docker-ce

4.6 ARM 板卡 Mali GPU 验证： glxinfo 与 mali_info 的双指标

RK3399 等 ARM 板卡升级后， glxinfo | grep "OpenGL renderer" 应显示 Mali-T860 ，而非 llvmpipe （软件渲染）。若显示 llvmpipe ，说明 Mali 驱动未加载。验证步骤：

# 检查 Mali 内核模块
lsmod | grep mali && echo "✅ mali 模块已加载" || echo "❌ mali 模块未加载"

# 检查 Mali 用户空间库
ldconfig -p | grep mali && echo "✅ mali 库已注册" || echo "❌ mali 库未注册"

# 若未加载，手动插入（以 RK3399 为例）
sudo modprobe mali_kbase
sudo ldconfig

4.7 NVIDIA 驱动验证： nvidia-smi 与 dkms status 的一致性

nvidia-smi 显示驱动版本， dkms status 显示内核模块编译状态，二者必须一致。验证：

# 获取 nvidia-smi 驱动版本
DRIVER_VER=$(nvidia-smi -q | grep "Driver Version" | awk '{print $4}')

# 获取 dkms 编译的版本
DKMS_VER=$(dkms status | grep nvidia | awk -F', ' '{print $2}' | sed 's/)//')

# 比较
[[ "$DRIVER_VER" == "$DKMS_VER" ]] && echo "✅ 驱动版本一致" || echo "❌ 驱动版本不一致：nvidia-smi=$DRIVER_VER, dkms=$DKMS_VER"

若不一致，重装驱动： sudo apt install --reinstall nvidia-driver-390 （根据实际版本调整）。

4.8 网络配置验证： netplan apply 与 systemd-networkd 的握手协议

Ubuntu 18.04 默认使用 netplan 管理网络，配置文件 /etc/netplan/01-netcfg.yaml 。若升级后网络中断，90% 是 netplan 未生效。验证：

# 检查 netplan 配置语法
sudo netplan generate && echo "✅ netplan 语法正确" || echo "❌ netplan 语法错误"

# 检查 systemd-networkd 是否接管
systemctl is-active --quiet systemd-networkd && echo "✅ systemd-networkd 活跃" || echo "❌ systemd-networkd 未活跃"

# 若未活跃，启用它
sudo systemctl enable systemd-networkd
sudo systemctl start systemd-networkd

4.9 中文输入法验证： fcitx 与 ibus 的 GTK/QT 环境适配

fcitx 在 18.04 中需额外配置 GTK_IM_MODULE 和 QT_IM_MODULE 。验证：

# 检查环境变量
env | grep -E "(GTK_IM_MODULE|QT_IM_MODULE)" | grep fcitx && echo "✅ 输入法环境变量正确" || echo "❌ 输入法环境变量缺失"

# 检查 fcitx 进程
ps aux | grep fcitx | grep -v grep && echo "✅ fcitx 进程运行" || echo "❌ fcitx 进程未运行"

# 若缺失，添加到 ~/.profile
echo 'export GTK_IM_MODULE=fcitx' >> ~/.profile
echo 'export QT_IM_MODULE=fcitx' >> ~/.profile
source ~/.profile

5. 故障现场还原：一次 libc6 升级失败的完整排错链路

去年在为客户升级一台 ROS Melodic 开发机时， do-release-upgrade 卡在 Installing the upgrades 阶段， /var/log/dist-upgrade/main.log 最后一行是：

2023-02-10 14:22:31,889 DEBUG installing libc6:amd64 <none>

SSH 连接随后断开，再次连接后 apt 命令全部报错 E: Could not get lock /var/lib/dpkg/lock-frontend 。这不是锁文件问题，而是 libc6 安装破坏了 dpkg 的运行时环境。以下是完整的、可复现的排错链路，每一步都有明确目的和预期输出。

5.1 第一步：确认 dpkg 二进制是否损坏

dpkg 是用 C 编写的静态链接二进制，依赖 libc6 。若新 libc6 安装失败， dpkg 会因符号解析失败而崩溃。验证：

# 检查 dpkg 二进制是否可执行
file /usr/bin/dpkg | grep "ELF.*x86-64" && echo "✅ dpkg 是有效 ELF" || echo "❌ dpkg 二进制损坏"

# 检查 dpkg 是否能打印版本（不依赖 libc）
/usr/bin/dpkg --version 2>/dev/null && echo "✅ dpkg 可运行" || echo "❌ dpkg 运行失败"

若 dpkg --version 失败，说明 libc6 安装不完整。此时不能 apt install libc6 ，因为 apt 本身依赖 dpkg 。

5.2 第二步：从 Live USB 挂载根分区，提取旧 libc6

必须用 Ubuntu 16.04 Live USB 启动，挂载原系统根分区，复制 libc6 文件：

# 在 Live 环境中
sudo mkdir /mnt/oldroot
sudo mount /dev/sda1 /mnt/oldroot  # 假设根分区是 sda1
sudo cp /mnt/oldroot/lib/x86_64-linux-gnu/libc-2.23.so /tmp/libc-2.23.so
sudo umount /mnt/oldroot

5.3 第三步：在故障系统中强制替换 libc6

重启进入故障系统（单用户模式：GRUB 中按 e ，在 linux 行