飞翔的十号Ubuntu 20.04 升级到 24.04 实战详细教程/记录
距离 Ubuntu 20.04 LTS 发布已经过了快四年，这台服务器从 2020 年装好系统一直跑到现在，中间经历了内核小版本更新、Docker 迁移、Python 环境重构，但系统版本始终没动过。直到最近需要装一个新工具链，对方明确要求 glibc 版本必须高于 2.35，而 20.04 自带的 glibc 2.31 直接卡死了安装条件。20.04 还在维护期内，但 24.04 的 LTS 生命周期到 2029 年，早晚得升，不如趁业务低峰期一次到位。这篇记录就是我在真实服务器上从 Ubuntu 20.04 跨版本升级到 24.04 的完整过程，包括升级前的检查、源切换、系统更新、版本跃迁、内核切换、驱动和软件环境修复、以及升级后的验证和回滚预案，全部基于实际执行过的命令和输出整理，给同样要跨大版本升级的朋友一个可参考的操作路径。
先说结论：Ubuntu 官方支持的跨版本升级路径是 20.04 → 22.04 → 24.04，不推荐直接从 20.04 跳到 24.04。虽然 do-release-upgrade 默认只允许逐级升级，但很多人会尝试修改配置强制跨两个大版本，这种做法风险极大。我这次就是老老实实走了两段式升级，每一段都单独验证、单独备份，虽然多花了一些时间，但整体非常平稳，业务中断时间控制在 20 分钟以内。
1. 为什么要选择两段式升级而不是直接跨版本
1.1 官方升级机制的限制
Ubuntu 的 do-release-upgrade 工具默认配置里有一行关键参数：
bash复制# /etc/update-manager/release-upgrades
Prompt=lts
当 Prompt=lts 时，系统只允许从 LTS 升级到下一个 LTS，也就是说 20.04 → 22.04 → 24.04 是官方支持的唯一路径。如果你尝试直接修改为 Prompt=normal 然后跳到 24.04，工具会报错或者干脆拒绝执行。
更深层的原因是：Ubuntu 的包管理器（APT）在跨版本升级时，依赖解析器要走一遍完整的包依赖图。两个大版本的跨度意味着 glibc、libssl、Python、Perl 这些底层组件全部要换新，依赖关系变化太大，APT 很难保证不出冲突。我在测试环境里试过一次直接跨版本，升级到一半就卡在 libc6 的配置脚本上，那个包一旦处于半配置状态，整个系统的 apt 就不能用了，恢复起来非常麻烦。
1.2 两段式升级的实际耗时和风险对比
| 升级路径 | 预估耗时 | 主要风险 | 官方支持 |
|---|---|---|---|
| 20.04 → 22.04 | 30~60 分钟 | 内核切换、驱动兼容 | 支持 |
| 22.04 → 24.04 | 40~70 分钟 | Python 环境、snap 版本 | 支持 |
| 20.04 → 24.04 直接跳 | 无法预计 | 依赖解析崩溃、系统无法启动 | 不支持 |
我这次两段式升级总共用了大约 1 小时 40 分钟，包括中间的业务验证时间。相比测试环境里直接跨版本折腾了四个小时还以失败告终的惨痛经历，这个时间成本是非常划算的。
1.3 什么样的机器适合在线升级
不是所有 Ubuntu 20.04 机器都适合走在线升级，以下几个条件至少要满足三条以上才建议尝试：
- 数据有完整备份（至少数据库做过 dump，或者有快照）
- 系统盘剩余空间在 10GB 以上
- 服务器不是唯一的生产节点（至少能接受 30 分钟以上的中断）
- 业务依赖的第三方软件在当前版本下没有强制的 glibc 版本要求（或者说升级后能接受重新适配）
我这次操作的机器是一台跑内部服务的管理节点，不直接对外提供服务，数据量不大，所以在线升级的容错空间足够大。如果你的机器是核心数据库节点，强烈建议先做虚拟机克隆或者云厂商快照，在任何情况下都不要跳过备份这一步。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 升级前的完整状态检查与备份
2.1 系统信息收集
在动手之前，先把系统当前状态完整记录下来。这一步是为了后面升级过程中出现异常时，能快速对比哪些东西变了、哪些东西没变。
bash复制# 当前系统版本
lsb_release -a
# 内核版本
uname -r
# 已安装的第三方内核模块
dpkg -l | grep -E "linux-modules|linux-image|linux-header"
# 重要软件版本
docker --version
python3 --version
nginx -v
mysql --version
# 系统架构
dpkg --print-architecture
这是我升级前记录的机器状态：
code复制Distributor ID: Ubuntu
Description: Ubuntu 20.04.6 LTS
Release: 20.04
Codename: focal
内核: 5.4.0-167-generic
Docker: 24.0.7
Python: 3.8.10
Nginx: 1.18.0
2.2 查看是否有第三方源和 PPA
第三方软件源是跨版本升级最容易踩坑的地方。因为每个 Ubuntu 版本的软件源都有对应的代号（20.04 叫 focal，22.04 叫 jammy，24.04 叫 noble），如果你加了 PPA，升级到一个新版本后这个 PPA 可能还没有适配新版，APT 就会因为找不到包而中断升级。
检查所有源文件：
bash复制grep -rh "^deb" /etc/apt/sources.list /etc/apt/sources.list.d/ 2>/dev/null
常见的需要处理的第三方源包括：
- Docker 官方源：支持所有 Ubuntu 版本，但需要在升级后手动确认版本是否匹配
- NVIDIA GPU 驱动源：升级后必须重新安装驱动，否则会黑屏或者无法启动图形界面
- NodeSource（Node.js 源）：必须手动更新，因为不同 Ubuntu 版本的发行代号不同
- 各种 PPA：例如
ppa:deadsnakes/ppa（Python 多版本源），升级前最好逐个检查
我这次机器上加了 Docker 官方源和 ppa:deadsnakes/ppa，其中 deadsnakes 在 jammy 和 noble 都有对应版本，所以问题不大。如果你的第三方源没有适配 22.04 或 24.04，建议在升级前先注释掉，等升级完成后再重新配置。
2.3 备份策略
这里说的备份不是简单的复制文件，而是要有明确的恢复路径。我给自己定了一个"三条备份"原则：
- 系统配置备份：
/etc目录整体打包，这是系统恢复的关键，所有网络配置、服务配置、用户权限都在里面 - 业务数据备份：数据库 dump + 关键目录打包
- 软件包列表备份：记录当前安装的所有包，方便回滚时恢复
bash复制# 备份软件包列表
dpkg --get-selections > /root/backup/dpkg-selections.txt
# 备份 apt 源配置
cp -r /etc/apt /root/backup/apt-backup
# 备份系统配置目录（排除运行时文件）
tar -