Ubuntu 20.04升级24.04实战：两步走避坑全指南

最近我把一台服役了三年半的Ubuntu 20.04服务器正式升级到了24.04 LTS，整个升级过程加上中途排错，前前后后折腾了两天。遇到过SSH断连、软件源失效、PHP服务直接挂掉这类经典问题，所以专门写一篇实战记录。如果你手头也有正在服役的20.04系统，这篇文章能帮你少走不少弯路，尤其是从20.04先升到22.04、再升到24.04这个隐藏环节，官方文档基本不会提。

这篇记录适合几类人：一是服务器上跑着业务、想平滑升级但又怕出问题的运维；二是桌面用户想尝鲜24.04但担心显卡驱动和软件兼容性；三是刚接触Ubuntu、想搞清楚LTS版本升级机制的新手。我会把升级前准备、两步升级操作、升级后清理、应用层兼容性排查、常见问题五块全部讲透，能直接照着抄。

1. 升级前的准备：别急着敲命令，先把家底盘清楚

1.1 为什么必须从20.04升级上来

Ubuntu 20.04（Focal Fossa）的 standard support 在2025年4月就到期了，如果你不买ESM扩展支持，之后的安全更新和补丁就断了。服务器暴露在公网还不打补丁，这基本等于裸奔。24.04 LTS（Noble Numbat）的支持周期到2029年4月，算上ESM能撑到2034年，中间还多了很多新特性。我的看法是，20.04虽然稳，但到了生命周期末端，手头的重要机器该升级就得升级，别拖到EOL之后才动。

升级的核心收益不只是“版本号变新”。对比一下主要的系统组件你就明白了：

OpenSSL 1.1.1 其实已经停止维护了，这一点很多不看新闻的人没意识到。Web服务、数据库、邮件系统全都依赖OpenSSL，一直停在旧版本就是给攻击者留后门。另外老内核对新硬件和新的文件系统特性支持也不好，比如你后续想上Cgroup v2的一些新特性、或者新的NVMe SSD优化，老内核根本用不上。

1.2 硬件与磁盘空间评估

升级之前先盘一下机器还够不够用。24.04对硬件的要求比20.04略高，但也没高到离谱。服务器上建议内存不少于2GB，磁盘空闲空间最好在20GB以上。关键是/var分区和/boot分区要留够空间，因为apt缓存、内核镜像都会占用大量空间。

检查命令很简单：

bash复制lsb_release -a
uname -a
df -h
free -h

我在实际操作中遇到过一次最尴尬的情况：/boot分区只剩80MB，升级到一半内核装不进去，报错说“not enough free disk space”。虽然最后通过apt autoremove --purge清出了空间，但升级流程已经半个身子卡住了，很被动。所以你升级前一定要用df -h看清楚，特别是独立挂载/boot的机器，至少留出1GB余量。

1.3 备份策略是底线，别当赌狗

升级Ubuntu大版本本质上是一次大规模的系统迁移，涉及超过上千个软件包替换。无论升级工具做得再成熟，都有失败风险。我见过太多人因为没备份，升级失败后只能含着泪重装系统，数据全没。这玩意儿不是闹着玩的。

我这次的备份方案分三层：

第一层，配置文件全量备份。直接把/etc目录整体打包，这个目录是系统的配置文件核心，什么网络配置、SSH配置、服务配置全在里面。打包命令：

bash复制sudo tar -czf /backup/etc-$(date +%Y%m%d).tar.gz /etc

第二层，业务数据备份。数据库单独导出，Web目录单独打包。如果你是MySQL，用mysqldump导出所有库；PostgreSQL用pg_dumpall。我的服务器上是MySQL，命令大概是这样：

bash复制mysqldump -u root -p --all-databases > /backup/all-databases.sql
tar -czf /backup/www-$(date +%Y%m%d).tar.gz /var/www

第三层，软件包清单备份。这一步很多人会忽略，但后面排错很有用。把当前系统所有已安装的软件包列表导出来，万一某个软件升级后没了或者出问题，你知道当初装的是什么：

bash复制dpkg --get-selections > /backup/packages-$(date +%Y%m%d).txt

备份完成后，强烈建议你顺手验证一下备份文件能正常解压、数据库备份能正常导入。备份了但恢复不了，等于没备份。我一般会把备份文件拷到另一台机器或者对象存储上，防止本机磁盘故障把备份一起带走。

另外还有一个小细节：升级大版本前，确认你在SSH会话里挂了tmux或screen。我第一次升级就是没挂tmux，升级到一半办公室网络抽风，SSH断了，升级进程没被正确地守护，差点把系统弄成半死不活的状态。后面会细说这个坑。

2. 升级实战：从20.04到22.04再到24.04

2.1 为什么分两步走，不能一步跳到底

这是整个升级流程里最重要的一个认知。很多第一次升级的朋友以为像手机OTA一样，20.04可以直接升到24.04。实际上Ubuntu官方的do-release-upgrade工具默认只支持升级到“下一个LTS版本”，20.04的下一个LTS是22.04，22.04的才是24.04。所以你要从20.04到24.04，正规路线必须是两条腿走路：先升22.04，重启，再升24.04。

有人会问，那我改/etc/update-manager/release-upgrades的Prompt为normal，能不能直接跨大版本升？理论上确实可以尝试，Ubuntu的升级器在跨多个版本时会拉取所有中间版本的依赖变化，但实际执行中带来的依赖冲突概率高得离谱。我同事在一台测试机上试过直接从20.04跳24.04，最后系统里同时存在新旧两套Python库，很多服务直接跑不起来，排查到崩溃。你别赌这个，一步一步走最稳。

2.2 第一跳：20.04 → 22.04 的具体操作

第一步，先把当前系统的所有软件包升级到最新。这是个大前提，旧包不升干净直接跑do-release-upgrade，很容易因为依赖关系不满足而中断。

bash复制sudo apt update
sudo apt upgrade -y
sudo apt full-upgrade -y
sudo apt autoremove

第二步，确认升级工具是最新的。20.04自带的ubuntu-release-upgrader有可能不认识22.04，需要手动更新一下：

bash复制sudo apt install update-manager-core

第三步，设置升级策略。编辑/etc/update-manager/release-upgrades，确保这一行是：

text复制Prompt=lts

注意不要设成never，否则系统永远不会检查新版本。设成normal的话，它会尝试升级到最新的非LTS版本，不符合我们的需求。设成lts之后，它只会在有新的LTS版本时提示你。

第四步，检查一下第三方软件源。如果你之前加过PPA或者其他第三方源，升级时大概率会报错或弹出提示。我这台机器之前装过一些开发工具，带了三四个PPA，升级时有的PPA已经不兼容22.04，会被升级器自动禁用。禁用后对应软件可能被保留老版本或直接移除，后面我会讲怎么清理。

第五步，正式开始升级。这一步建议你在tmux里跑，避免SSH断线。tmux的用法不多说，一句话：

bash复制tmux new -s upgrade

然后执行：

bash复制sudo do-release-upgrade

升级过程中会问你一些配置文件替换的问题。核心原则是：如果你不确定，就选保留现有配置（通常选项是N或“keep the local version currently installed”）。特别要注意/etc/ssh/sshd_config这种文件，如果选错了被替换成新默认配置，你可能连SSH都进不来。我自己遇到sshd_config的时候选的是保留，之后手动对比新版本再做调整。

升级过程会下载大量软件包，20.04到22.04大约需要下载2GB左右，耗时取决于网络。我的服务器在机房，内网镜像源，大概跑了40分钟。下载完后它会自动更新系统包、清理旧包，最后提示你重启。重启前它会问你是否移除过时的软件包，我建议选“是”，后面再单独按需装回来。

第六步，重启并验证：

bash复制sudo reboot

等机器重新起来后，登录进去确认版本：

bash复制lsb_release -a

这时候你应该看到22.04 LTS。然后顺手做一轮系统更新和清理：

bash复制sudo apt update && sudo apt upgrade -y
sudo apt autoremove --purge

2.3 第二跳：22.04 → 24.04 关键注意事项

升到22.04之后，不要急着庆祝。把系统放到这个中间状态跑一下，确认所有服务都正常，再考虑升24.04。我这次就是先在22.04上跑了半天，检查了Nginx、MySQL、PHP这些服务日志都没问题，才继续下一步。

第二跳的操作流程几乎和第一跳一样，先更新软件包，再执行：

bash复制sudo apt update && sudo apt upgrade -y
sudo do-release-upgrade

但是有几件事和第二跳强相关，我重点说。

第一，22.04到24.04的升级包更大，大约3.5GB，整个升级过程需要更久。我这次跑了接近一个小时，全程不敢离开电脑，中间还遇到一次网络抖动。所以tmux一定要挂上，万一断了还能重新连回去看进度。

第二，24.04对第三方软件源的兼容性更严格。很多22.04的PPA虽然能用，但24.04下可能直接404。升级时看到这种报错别慌，它们是提示你源失效了，找对应PPA维护者确认新版本的地址即可。

第三，升级到24.04前，确认一下你的机器是否有特殊内核模块或DKMS驱动。如果你装过NVIDIA显卡驱动、特定的网卡驱动、虚拟化模块，升级到6.8内核后这些驱动大概率需要重新编译。桌面用户尤其注意，后面专门讲。

第二跳结束后照例重启，验证：

bash复制lsb_release -a

看到24.04 LTS，恭喜你，系统层面的升级已经完成了。但只做系统升级不清理不排查，等于埋雷。接下来看升级后的体检和清理。

2.4 升级过程中的观察记录与时间线

我这次两台机器的升级时间线记录如下，仅供参考：

• 20.04 → 22.04：下载约2GB，耗时约40分钟，重启后服务恢复检查约10分钟。
• 22.04 → 24.04：下载约3.5GB，耗时约55分钟，重启后配置修正约30分钟。
• 总计从开始准备到全部收尾，大约6小时，包含中间等待、排查和吃饭时间。

多次升级中我发现一个规律：升级时间主要卡在网络下载和软件包解压安装阶段，CPU核数多、磁盘是SSD的话会快很多。如果你的机器是机械硬盘，建议预留更长的窗口时间，不要安排在业务高峰期操作。另外，升级过程中CPU和I/O占用会非常高，如果机器上有线上业务，务必提前切换流量或安排维护窗口。

3. 升级后的系统级更新与清理：别以为重启完就万事大吉

3.1 系统版本与内核验证

重启进入24.04后，先做一轮基础验证。除了lsb_release -a确认版本，还要检查内核版本和系统启动状态：

bash复制uname -r
systemctl status systemd-journald

内核应该显示6.8.x系列。如果你的内核还是5.4或5.15，说明启动的时候默认选的是旧内核。这种情况通常是因为/boot/grub/grub.cfg没有更新，或者旧内核包还在引导菜单里。执行一下sudo update-grub，然后重启。

网络是另一个重点检查项。24.04的网络管理工具依然是netplan，但upgrade过程有可能会改变接口名。查看一下IP：

bash复制ip a

对比一下升级前的IP是否还在。如果发现网卡名变了，比如从enp0s3变成了enp1s0，大概率是/etc/netplan/*.yaml里的配置和实际接口对不上。修改netplan配置文件后执行sudo netplan apply即可。这个我在5.3节还会细说。

SSH服务也要重点验证。升级后OpenSSH版本从8.2升到9.6，有些旧配置指令在新版本里被标记为不推荐或直接移除。比如RSAAuthentication这类老参数在新版本已经失效了。先测试配置文件是否正确：

bash复制sudo sshd -t

如果有报错，它会明确提示哪一行配置有问题。修完再sudo systemctl restart ssh。特别注意，如果升级时你选择了替换sshd_config，那么你自定义的端口、密钥登录设置、禁止root登录的规则全都会变成默认值。这就是为什么前面说升级时要谨慎选配置文件替换选项。

3.2 清理旧内核、旧依赖、残留配置

升级后的系统里通常残留大量旧内核、旧版本的软件包和孤儿依赖，占用磁盘空间最多能到几个GB。清理命令：

bash复制sudo apt autoremove --purge
sudo apt clean

执行完再检查磁盘空间：

bash复制df -h

我看到有朋友升级后/boot分区直接塞满了，就是因为旧内核没自动清。autoremove --purge之后旧内核一般会被删掉。如果没删干净，可以手动查看已安装的内核：

bash复制dpkg --list | grep linux-image

只留当前最新的一两个版本，其余用apt purge删除。注意别手滑把正在用的内核删了，先看uname -r再对比列表。

清理完了再做一次依赖检查：

bash复制sudo apt --fix-broken install

这一步会把升级过程中遗留的broken依赖修复掉。如果有包被标记为“deinstall pending”，说明升级时被移除了但没清干净，一并处理掉。

3.3 软件源与第三方仓库处理

升级完第一件事就是更新软件源信息，让apt知道从哪拉包：

bash复制sudo apt update

如果出现类似Failed to fetch ... 404 Not Found的报错，基本就是第三方源失效了。看报错里给出的具体源文件路径，比如/etc/apt/sources.list.d/某ppa.list，确认这个PPA确实不维护了，就直接把对应list文件注释或删掉。删除后重新apt update。

这里特别提一下国内镜像源。如果你原来用的是archive.ubuntu.com官方源，升级后建议切换成国内镜像，比如阿里云、清华或中科大，速度快很多。24.04的源格式跟20.04不一样了，官方用上了新的deb822格式，但传统的/etc/apt/sources.list格式依然兼容。你可以在清华Ubuntu镜像帮助页找到对应的24.04源配置，直接替换即可。注意别把20.04的源用在24.04上，里面的软件包版本对不上，跑一遍apt update全是404。

3.4 服务状态全面体检

升级后最怕的不是系统没起来，而是某个服务悄悄挂了。先看失败的服务：

bash复制systemctl --failed

如果列表为空，说明所有系统服务都正常。有失败的话，逐个检查日志：

bash复制journalctl -u 服务名 -b --no-pager

再看防火墙：

bash复制sudo ufw status

防火墙规则一般会保留，但升级后如果网络配置变了，防火墙规则里的接口名可能对不上，导致某些端口意外放行或拦截。我这次升级后ufw规则还在，但Docker的端口映射规则和ufw的交互出现了一点小问题，后面花了一点时间重新调整。

最后检查定时任务：

bash复制crontab -l
sudo ls /etc/cron.d/

有时候升级会改变某些命令的路径，导致cron里写的/usr/bin/php找不到了。我在这台机器上就遇到一个定时备份脚本报错，因为PHP从7.4升到8.3后路径虽然没变，但扩展名不一致导致命令行执行失败。后面会细说。

4. 应用层兼容性排查：这是一场“软件生态碰碰车”

4.1 PHP/Nginx/MySQL 全家桶的升级影响

如果你服务器上跑了LNMP（Linux + Nginx + MySQL + PHP），升级到24.04后最大的变化就是PHP版本。20.04默认PHP 7.4，22.04默认PHP 8.1，24.04默认PHP 8.3。这中间跨了好几个大版本，PHP的语法、函数弃用情况变化很大，老代码直接跑在8.3上保不齐就报错。

我这次遇到的是最典型的php-fpm问题。升级后apt把PHP 7.4的包标记为obsolete，系统里装上了PHP 8.3的包，但Nginx的配置还指向旧的fpm socket。检查Nginx错误日志时看到：

text复制connect() to unix:/run/php/php7.4-fpm.sock failed (2: No such file or directory)

因为新版php-fpm的socket路径是/run/php/php8.3-fpm.sock，路径都对不上，请求自然全部502。解决办法是修改Nginx站点配置文件里的fastcgi_pass：

nginx复制fastcgi_pass unix:/run/php/php8.3-fpm.sock;

改完重启Nginx和php-fpm：

bash复制sudo systemctl restart nginx
sudo systemctl restart php8.3-fpm

如果你用了多个PHP版本并存，还得检查/etc/nginx/snippets/fastcgi-php.conf里引用的socket路径是否匹配。

MySQL这块相对温和，20.04默认MySQL 8.0，24.04默认MySQL 8.0的更新版本，配置变化不大。但如果你用的是MariaDB，升级后版本可能从10.x跳到10.11或11.x，某些不兼容的字段类型和SQL模式需要额外测试。我建议升级后对线上库做一轮查询回归测试，重点看排序规则和JSON函数。

4.2 Python 3.8 → 3.12 与虚拟环境

Python的变化是另一个大坑。20.04系统默认是Python 3.8，24.04默认Python 3.12。如果系统里有直接用python3命令服务的脚本，升级后行为可能完全不同。3.12对C扩展模块的ABI兼容性有破坏性变化，之前用pip装的一些带有C扩展的包，比如cryptography、pydantic这些，需要重新编译安装。

我建议所有Python虚拟环境升级后一律重建：

bash复制python3 -m venv /path/to/venv
source /path/to/venv/bin/activate
pip install -r requirements.txt

不要试图把旧venv里的包原样迁移到新环境。我这里吃过亏，旧venv指向的是3.8解释器，升级后解释器路径不变但系统库版本已经变了，跑起来各种段错误。重建虽然麻烦，但最干净。

如果你用pyenv管理Python版本，升级后可能需要重新编译你固定的Python版本，因为旧二进制链接的glibc可能不兼容新系统。简单说，一切Python相关的东西都当成“需要重新安装”来处理，能省你大量时间。

4.3 Docker、Node、Java 等生态的适配

Docker这块要重点关注。20.04时代很多服务器装的是旧版Docker，比如19.x或20.10。旧版Docker跟24.04的新内核（6.8）和新systemd可能有兼容性问题，常见表现是容器启动报iptables failed或者cgroup相关错误。

解决办法是升级Docker Engine到最新稳定版，推荐使用官方仓库重新安装。先卸载旧版：

bash复制sudo apt remove docker docker-engine docker.io containerd runc

再添加Docker官方源安装：

bash复制curl -fsSL https://get.docker.com | bash

装完验证：

bash复制docker --version
docker run hello-world

如果你用docker-compose，记得确认它的版本，新版Docker都推荐用docker compose插件而不是独立的docker-compose二进制。

Node.js如果用的是nvm管理，升级后建议重新安装你需要的Node版本：

bash复制nvm install 18
nvm use 18

因为旧Node二进制链接的系统库可能和新版本不完全兼容。Java程序相对稳定，但如果是自编译的JRE镜像，建议重新生成。

4.4 显卡驱动（桌面用户重点）

桌面用户升级到24.04后最容易遇到的问题就是图形界面起不来，黑屏或者卡在登录界面。原因99%是显卡驱动和新内核不兼容。20.04默认内核5.4，如果你之前用的NVIDIA驱动是470甚至390系列，这些老驱动不支持6.8内核，模块编译都编译不出来。

解决方案是在24.04上安装适配新版的驱动。Ubuntu 24.04仓库里提供的最稳定的NVIDIA驱动是nvidia-driver-550，可以直接安装：

bash复制sudo apt install nvidia-driver-550

如果你不确定自己显卡需要哪个版本，先看硬件型号：

bash复制lspci | grep -i nvidia

然后安装后重启：

bash复制sudo reboot

重启后验证：

bash复制nvidia-smi

这里提醒一句：如果你之前是用NVIDIA官网的.run安装包装的驱动，升级后旧驱动百分百失效，需要重新跑安装脚本，而且官方.run安装包在装到新内核时可能要加--no-opengl-files参数避免覆盖系统OpenGL库。更省心的做法是先彻底卸载旧的.run驱动，再走apt安装。用apt install装的驱动配合DKMS，每次内核更新都会自动重新编译，省事太多。

5. 常见问题与排查技巧实录

5.1 “No new release found” 的排查

这是升级时最高频的报错，提示找不到新版本。原因通常是三类：

第一，/etc/update-manager/release-upgrades里的Prompt不是lts，被设成never，系统当然不会去检查新版本。改成lts即可。

第二，ubuntu-release-upgrader工具版本太老，不认识新版发布信息。执行上面的sudo apt install update-manager-core更新工具后重试。

第三，网络能通但访问不到版本元数据文件。可以手动检查：

bash复制curl -s https://changelogs.ubuntu.com/meta-release

如果输出异常，说明你访问不了官方升级服务器，需要检查网络或者配置代理。解决后再运行：

bash复制sudo do-release-upgrade -c

-c参数只检查不执行，适合先验证能不能找到新版本。

5.2 SSH 中途断线怎么办

如果你没有用tmux/screen，又倒霉碰上SSH断线，最直接的现象是升级进程被SIGHUP杀掉。重连服务器后，先查看dpkg是否还有进程在跑：

bash复制ps aux | grep -E 'dpkg|do-release-upgrade'

如果升级进程已经没了，先修复可能中断的半成品状态：

bash复制sudo dpkg --configure -a
sudo apt --fix-broken install

然后重新执行：

bash复制sudo do-release-upgrade

升级器会从断点继续，已经下载的包不会浪费。所以我说tmux是你的朋友，正确姿势是：

bash复制tmux new -s upgrade
sudo do-release-upgrade

挂了tmux之后，SSH断了没关系，重新连上后执行：

bash复制tmux attach -t upgrade

进度都还在。

5.3 升级后无网络排查

升级后上不了网，第一件事是看网卡状态：

bash复制ip link
ip a

如果网卡没有IP，大概率是netplan配置里的接口名变了。查看现有netplan配置：

bash复制ls /etc/netplan/
cat /etc/netplan/*.yaml

对比当前网卡名和配置里的名称，改成一致的，然后：

bash复制sudo netplan apply

如果netplan apply不生效，检查NetworkManager是否被禁用：

bash复制systemctl status NetworkManager

服务器版没有NetworkManager是正常的，它默认走netplan加systemd-networkd或NetworkManager。这里有一个容易漏的点：升级后DHCP客户端可能从dhclient换成了systemd-networkd自带实现，如果租约文件有问题，获取不到IP。重启一下网络服务试试：

bash复制sudo systemctl restart systemd-networkd

再不行就手动在netplan配置里指定静态IP，至少先恢复远程连接。

5.4 GUI/显卡起不来

桌面系统升级后黑屏，先别慌，可以切换到纯文本终端（Ctrl+Alt+F3或F4）。登录后用dmesg和Xorg日志定位问题：

bash复制dmesg | grep -i nvidia
journalctl -b --no-pager | grep -i 'failed\|error'

如果是NVIDIA驱动问题，按4.4节的方法重装驱动。如果你是AMD或Intel显卡，一般开箱即用，如果还是黑屏，检查Wayland和Xorg会话切换。24.04默认使用GNOME + Wayland，有些老应用在Wayland下可能白屏，可以在登录界面点击齿轮图标，选择“Ubuntu on Xorg”试试。

5.5 PHP-FPM socket 404/502

按4.1节的方法，先确认php-fpm版本和socket路径：

bash复制systemctl status php*-fpm
ls /run/php/

如果/run/php/下同时存在php8.3-fpm.sock和php8.1-fpm.sock，要确认你的Nginx配置到底引用了哪个。修改fastcgi_pass后记得测试Nginx配置：

bash复制sudo nginx -t

没问题再重启。如果用了多站点，每个站点的配置文件都要检查，漏一个就是哪个站502。

5.6 dpkg被中断/锁相关问题

升级过程中如果强制中断，dpkg可能会锁死，apt任何操作都报：

text复制Could not get lock /var/lib/dpkg/lock-frontend

先看有没有残留的apt/dpkg进程：

bash复制ps aux | grep -E 'apt|dpkg'

有的话先等待进程结束。如果没有但锁文件还在，手动删除锁文件是最后的办法：

bash复制sudo rm /var/lib/dpkg/lock-frontend
sudo rm /var/lib/dpkg/lock
sudo dpkg --configure -a

但这只建议在确认没有其他apt进程时才做，千万别在系统正常工作时删锁，否则可能造成数据库损坏。

最后再分享一个经验。这次升级我踩过最大的一次坑是升级到24.04之后，原来很正常的cron定时备份脚本开始报错，排查半天发现是脚本里的mysqldump路径变了。20.04时代我自定义编译过MySQL，装在/usr/local/mysql，升级后系统库更新，PATH环境变量变化导致脚本调用了新版本的mysqldump，而新版本的参数和旧版有差异。所以升级完成后，别光盯着系统服务，你自建的定时任务、shell脚本、systemd自定义单元都要逐一验证一遍。那些看起来人畜无害的小脚本，往往是升级后最耗你时间的东西。