Ubuntu 大版本升级指南：do-release-upgrade 前后检查清单

apt upgrade 只升级当前 Ubuntu 版本的软件包；do-release-upgrade 才是从一个发行版升级到下一个发行版（Release upgrade）。后者会更换软件源、升级大量包、处理配置文件并可能移除旧软件，必须安排停机窗口和可恢复备份。

一、确认当前版本和升级路径

cat /etc/os-release
lsb_release -a
uname -r

长期支持版（Long Term Support，LTS）通常适合服务器。LTS 只能直接升级到下一个连续 LTS，不能跨过中间版本，例如不能从 20.04 一步跳到 24.04。非 LTS 版本支持期较短，需要按受支持的相邻路径升级。

检查是否有新版本：

sudo do-release-upgrade --check-dist-upgrade-only

生产环境不要使用 -d 追踪开发版（Development release）。新 LTS 的升级通道通常会在第一个点版本发布后才向前一个 LTS 普遍开放。

二、升级前必须完成的准备

1. 阅读目标版本发行说明（Release notes）和已知问题。
2. 做应用数据、配置文件和数据库备份，并验证能恢复。
3. 虚拟机可额外创建快照，但快照不能替代独立备份。
4. 确认有控制台或带外管理，避免 SSH 中断后完全失联。
5. 用 df -h 和 df -i 检查空间与 inode。
6. 记录第三方仓库、PPA、自编译软件和特殊驱动。

先把当前系统更新到完整状态：

sudo apt update
sudo apt dist-upgrade -o APT::Get::Always-Include-Phased-Updates=true
sudo apt --fix-broken install
systemctl --failed

如果 /run/reboot-required 存在，先重启并确认当前系统能正常启动，再开始大版本升级。不要带着未配置完成的软件包或失败服务强行升级。

三、远程升级的会话保护

在 ESXi 或 Hyper-V 虚拟机中，最好直接打开虚拟机控制台。只能通过 SSH 时，可先启动 tmux：

sudo apt install tmux
tmux new -s release-upgrade

连接中断后重新登录，执行 tmux attach -t release-upgrade 回到原会话。升级期间不要重启路由器、修改 SSH、防火墙或网络配置。保持第二个管理员窗口用于观察日志，但不要并行运行另一个 APT 进程。

四、启动升级并阅读摘要

sudo do-release-upgrade

升级器先做检查并显示将升级、新装和删除的软件包数量以及下载体积。认真查看移除清单；若出现关键数据库、Web 服务、虚拟化工具或网卡驱动，应先取消并调查。

升级过程可能询问配置文件处理方式，例如保留当前本地版本（Keep the local version currently installed）或安装维护者版本（Install the package maintainer's version）。不知道差异时通常先保留现有配置，并记下产生的 .dpkg-dist、.dpkg-old 文件，升级后再逐项比较。引导程序、网络或 SSH 配置不能机械选择同一个答案。

第三方软件源通常会被临时禁用，这是正常的。升级完成后应逐个确认厂商是否支持新版本，再启用对应源；不要把旧代号的软件源直接打开。

五、处理旧包和完成重启

升级器最后可能询问是否删除过时软件包（Obsolete packages）。先查看详细列表；自己部署的业务如果依赖旧库，可以暂时保留，验证后再清理。

升级结束后按提示重启。系统没有完成重启前，不能算升级真正完成。控制台观察启动过程，然后检查：

cat /etc/os-release
uname -r
systemctl --failed
ip -br address
ss -lntup
journalctl -p err -b --no-pager | tail -n 100

再从另一台电脑验证 SSH、HTTPS、数据库和业务页面。检查 UFW、定时任务、挂载点、时区和时间同步，并核对第三方软件版本。

六、失败时不要尝试“降级”

Ubuntu 没有可靠的一键跨版本降级。升级失败后先保留控制台输出和 /var/log/dist-upgrade/ 日志，判断是软件包、空间、网络还是配置问题。如果系统无法稳定恢复，应使用升级前验证过的备份或虚拟机快照回退，而不是混用两个版本的软件源硬修。

家庭实验机可先克隆一台虚拟机演练；确认应用兼容、升级用时和回退步骤后，再操作正式机器。一次成功升级的关键通常不在最后那条命令，而在开始之前的备份与检查。

七、应用层备份比整机快照更重要

Web 站点至少备份程序目录、上传文件、Web 服务配置和数据库；数据库应使用自身的一致性备份工具，而不是在运行时直接复制数据目录。升级前记录 PHP、MySQL、Python、Docker 等关键组件版本，并确认目标 Ubuntu 是否提供兼容版本。

dpkg --get-selections > package-selections-before-upgrade.txt
systemctl list-unit-files --state=enabled > enabled-services-before-upgrade.txt

这两份清单能辅助对比，但不能直接当作恢复脚本。文件中可能暴露已安装的内部软件名称，应作为运维资料妥善保存。

八、升级后的清理不要过早

先让业务稳定运行一段时间，再检查：

sudo apt update
apt list --upgradable
apt -s autoremove

apt -s autoremove 只模拟待清理内容。确认旧内核、驱动和依赖确实不再需要后，才运行真正的清理。保留至少一个可启动的旧内核通常有助于排查新内核兼容问题。

检查 /etc/apt/sources.list 和 /etc/apt/sources.list.d/，确保没有继续指向旧发行版代号；第三方源必须从厂商处确认新版本支持。不要使用全局文本替换强行把所有源的代号改成新版本。

九、虚拟机环境的额外检查

ESXi 中检查 open-vm-tools、网卡和磁盘控制器；Hyper-V 中检查集成服务（Integration Services）、时间同步和动态内存。确认虚拟机重启后 IP、默认网关和 DNS 没有变化，宿主机快照没有长时间遗留并持续增长。

如果正式服务器需要高可用，升级前应先把流量切到另一节点，而不是依靠 do-release-upgrade 保持业务全程在线。单机家庭服务则提前通知停机时间，升级完成后按端口清单逐项验证，比只看首页能否打开更可靠。

本文为中文学习整理。资料来源：Ubuntu Server 官方文档：How to upgrade your Ubuntu release。