Ubuntu 24.04 升级到 26.04 的正确方法与时间点

何时可以将 Ubuntu 24.04 升级至 26.04？

一旦 26.04.1 点版本发布（计划于 2026 年 8 月 27 日），您就可以在 VPS 上将 Ubuntu 24.04 升级至 26.04。在此之前，24.04 服务器不会检测到新版本，这是刻意为之。Ubuntu 26.04 LTS (Resolute Raccoon) 已于 2026 年 4 月 23 日发布，但 Canonical 仅在首个点版本发布时才会开放 LTS 到 LTS 的升级路径，因为该版本汇总了发布后最初几个月内发现的安装和升级错误。如果您对版本编号感到陌生，26.04.1 并非不同的 Ubuntu 版本，而是集成了四个月修复补丁的 26.04，这正是 Canonical 将其作为首个推送给现有服务器版本的原因。

在 2026 年 8 月初于 24.04 服务器上运行检查，您将得到以下结果：

sudo do-release-upgrade

Checking for a new Ubuntu release
No new release found.

这并非您的服务器故障。/etc/update-manager/release-upgrades 在 Ubuntu Server 上包含 Prompt=lts，这意味着该工具仅提供下一个长期支持版本，且仅在存在其 .1 点版本时才会提供。设置 Prompt=normal 则会引导您依次经过 24.10、25.04 和 25.10，这些过渡版本均已达到生命周期终点。请将其保留为 lts 并等待。Canonical 的计划日期可能会变动，如果日期过后仍未收到更新，请再次检查。

以下每条命令均需由您在自己的服务器上按顺序执行。发行版升级无法在您正在升级的机器上进行预演。它会替换内核和 C 库，并需要重启以完成升级。

是否有必要进行升级？

Ubuntu 24.04 的标准安全更新将持续到 2029 年，因此运行正常的生产服务器没有升级期限。仅当您需要 26.04 版本中包含的新特性时才进行升级，例如：PHP 8.5、PostgreSQL 18、MySQL 8.4 LTS、OpenSSH 10.2 或 7.0 内核。“版本号提升”不是触碰生产环境服务器的理由。

若出现以下任一情况，请勿进行原地升级：

• 您从未打开过服务商提供的控制台（VNC 或串口）并成功登录。如果 SSH 连接中断，该控制台是恢复访问的唯一途径；若等到被锁在系统外才发现控制台无法使用，为时已晚。
• 您无法承受一小时的停机时间，且没有回滚方案。
• 您的技术栈依赖于尚未发布 resolute 版本的第三方仓库。
• 服务器是两年前手动搭建的，且目前无人清楚其内部配置。

通常更好的替代方案是：新建一台 26.04 版本的 VPS，安装技术栈并恢复数据，待其响应正常后切换 DNS。在验证新服务器可用之前，旧服务器保持运行；此时回滚只需修改 DNS，无需进行数据恢复。如果您选择此方案，请从 新 VPS 的前十分钟配置 开始，规范地构建新服务器。

第 1 步：创建可恢复的备份

请使用双重备份方案，因为不同备份方式的故障模式不同。云服务商提供的快照覆盖整个磁盘，可在几分钟内完成恢复，但由于快照是在数据库写入过程中进行的，因此仅能保证崩溃一致性，而非应用一致性。使用 restic 将备份存储在服务器外部 进行文件级备份，可以实现单文件恢复，且即使您的账户被锁定，备份副本依然可用。

请先手动导出数据库。导出文件是唯一无需停止数据库即可保证可靠性的备份方式。

sudo -u postgres pg_dumpall | sudo tee /var/backups/pg-all.sql > /dev/null
sudo mysqldump --all-databases --single-transaction --routines | sudo tee /var/backups/mysql-all.sql > /dev/null
sudo tar czf /var/backups/etc-before-upgrade.tgz -C / etc
sudo chmod 600 /var/backups/pg-all.sql /var/backups/mysql-all.sql

--single-transaction 仅能为 InnoDB 表提供一致性导出。MyISAM 表必须在停止数据库后才能备份。/etc 压缩包是您真正需要的文件，因为它包含了升级过程中可能涉及的所有配置文件。

从未经过恢复测试的备份只是猜测。请现在就尝试从中提取一个文件，以免在紧急情况下无法使用。

第 2 步：首先完整更新 24.04

do-release-upgrade 在软件包状态异常的系统上拒绝运行，且未完全更新的 24.04 会导致后续故障排查变得困难。

sudo apt update
sudo apt full-upgrade
sudo apt --purge autoremove
sudo dpkg --audit
apt-mark showhold

dpkg --audit 若未输出任何内容，说明没有软件包处于半配置状态。apt-mark showhold 若未输出任何内容，说明没有软件包被锁定（pinned）在会阻碍升级的版本上。若列出了任何软件包，请使用 sudo apt-mark unhold 加软件包名称来解除锁定，或者确认该锁定有其必要性并在此停止。

如果内核已更新，请重启系统，以确保当前运行的内核版本与系统识别的版本一致。

[ -f /var/run/reboot-required ] && sudo reboot

接着检查磁盘空间。升级程序会在安装前下载全部新软件包，若空间不足，程序会中止并报错，提示具体的文件系统。

df -h / /boot

/ 剩余空间低于约 5 GB 时容易出错。/boot 小于 300 MB 会导致后续内核安装失败，并报错 No space left on device。旧内核通常是导致此问题的原因，使用 sudo apt --purge autoremove 可清理它们。

开始前还需注意一点：如果 自动安全更新 在升级过程中触发，它们会占用 dpkg 锁，导致版本升级程序报错 Could not get lock /var/lib/dpkg/lock-frontend 并停止。请先运行 sudo systemctl stop unattended-upgrades，待其完成后再重新开始升级。

Step 3: check third-party repositories and pinned packages

do-release-upgrade disables every apt source that is not an Ubuntu one, because a package built for noble can break a resolute system. It re-enables the ones it recognises afterwards and leaves the rest commented out. Know what you are carrying before the tool decides for you.

ls /etc/apt/sources.list.d/
grep -rhE '^(deb |Types:|URIs:|Suites:)' /etc/apt/sources.list.d/
ubuntu-security-status --thirdparty
ls /etc/apt/preferences.d/

Ubuntu 24.04 uses two formats in that directory: the old one-line .list files, and deb822 .sources files with Types: and Suites: fields. Both are disabled by the upgrade. ubuntu-security-status --thirdparty lists the installed packages that no Ubuntu archive provides, which is the honest count of what you have bolted on. Anything in /etc/apt/preferences.d/ is a pin, and a pin written for noble will keep choosing an old package on the new release.

For each third-party repository, confirm the vendor has published for the new codename before you begin. Docker's suites are listed at https://download.docker.com/linux/ubuntu/dists/, and other vendors expose the same directory. A source pointed at a suite that does not exist gives this on the first apt update after the upgrade:

E: The repository 'https://download.docker.com/linux/ubuntu resolute Release' does not have a Release file.

Leave that source disabled until the vendor publishes. Editing the codename to one the vendor did build is how you install packages linked against the wrong system libraries.

步骤 4：在 tmux 中运行升级，而非直接使用 SSH shell

如果在普通登录 shell 中运行 do-release-upgrade 时连接中断，进程会收到 SIGHUP 信号并在解包过程中意外终止。这会导致 dpkg 处于半配置状态，且服务器可能因网络栈异常而无法重新连接。请在终端复用器中运行升级，这样即使客户端断开，进程仍会在服务器上保持运行。

sudo apt install -y tmux
tmux new -s upgrade

在会话中执行：

sudo ufw allow 1022/tcp
sudo do-release-upgrade

升级程序在进行任何更改前，会在 1022 端口启动第二个 SSH 守护进程，并会提示相关信息：

To make recovery in case of failure easier, an additional sshd will be started on port '1022'. If anything goes wrong with the running ssh you can still connect to the additional one.

它不会自动为您打开防火墙端口，因为未经确认擅自修改防火墙规则存在风险。请在开始前手动开放 1022 端口，并在完成 sudo ufw delete allow 1022/tcp 后将其关闭。请注意，您的服务商可能在控制面板中设有额外的外部防火墙。

如果连接仍然中断，请重新登录并运行 tmux attach -t upgrade。您离开期间，升级仍会继续运行。如果升级没有继续，重新登录后发现 dpkg 处于半配置状态，或 apt 源一部分属于 noble、另一部分属于 resolute，请参阅恢复失败的版本升级，了解如何修复软件包状态，以及何时应停止修复并改为恢复快照。

第 5 步：谨慎处理配置文件提示

dpkg 仅针对您或脚本修改过的文件进行提示。因此，每一个提示都对应您曾手动修改过的文件；直接按回车键跳过提示，会导致加固后的服务器悄然恢复为默认配置。

Configuration file '/etc/ssh/sshd_config'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
      D     : show the differences between the versions
      Z     : start a shell to examine the situation
 The default action is to keep your current version.
*** sshd_config (Y/I/N/O/D/Z) [default=N] ?

每次遇到提示时，请务必先按 D。查看变更内容，然后选择 N 以保留您的版本。系统默认选项通常为 N，这是最稳妥的做法，因为您的文件当前运行正常，而软件包提供的默认文件从未在此机器上运行过。

保留您的文件需要付出代价：您无法直接获得新的默认配置。请在系统恢复运行且时间充裕时，再进行配置合并。

sudo find /etc -name '*.dpkg-dist' -o -name '*.dpkg-new'

列出的每个文件都是维护者提供的版本，它们会保存在您的文件旁边。请逐一进行差异对比（diff），并将关键设置复制过去。其中两个文件需要格外小心：/etc/ssh/sshd_config，因为配置错误会导致您的会话中断；以及您的 Web 服务器配置，因为配置错误会导致站点下线。

升级过程还会通过 needrestart 询问需要重启的服务。请接受列表中的所有服务。如果守护进程仍在调用已被磁盘删除的旧版共享库文件，则会在后续的某个请求中崩溃，且发生时您可能并未在监控该服务。

第 6 步：重启并检查机器

sudo reboot

系统恢复后：

lsb_release -a
uname -r
systemctl --failed
journalctl -p err -b --no-pager | head -50
sudo apt update && sudo apt full-upgrade
sudo apt --purge autoremove

lsb_release -a 应报告 Release: 26.04 和 Codename: resolute。uname -r 应显示 7.0 内核。systemctl --failed 应列出零个单元，若有任何列出的内容，则需优先处理。最后的 apt update 用于拉取发布镜像构建后更新的补丁。

PostgreSQL 16 到 18：静默滞后的集群

Ubuntu 24.04 默认提供 PostgreSQL 16，而 26.04 提供 PostgreSQL 18。升级过程会在 16 旁边安装 18，但不会迁移您的数据。Debian 的 postgresql-common 层会在下一个可用端口上为新主版本创建一个新的空集群，因此 16 继续占用 5432 端口并保留所有数据，而 18 则在 5433 端口上处于空置状态。您的应用程序会继续与 5432 端口通信，且表面上一切正常，这就是为什么人们往往在数月后才发现此问题。

pg_lsclusters

如果列出了两个集群，说明您尚未完成迁移。请在可以停止应用程序时执行以下操作：

sudo pg_dropcluster --stop 18 main
sudo pg_upgradecluster 16 main
pg_lsclusters
sudo -u postgres vacuumdb --all --analyze-only

首先删除空的 18 集群，因为 pg_upgradecluster 不会写入已存在的目标集群。默认方法会将 16 的数据导出并重新导入到 18 中，因此您需要大约相当于数据库大小的可用磁盘空间。-m upgrade 改用 pg_upgrade，对于大型数据库速度要快得多。迁移完成后，请查看 Port 列：新集群将接管 5432 端口，旧集群则保持停止状态。请务必自行运行分析（analyze）步骤，因为新加载的集群没有统计信息，首次查询速度会很慢。

在将应用程序切换到新集群后，请进行几天的测试。确认无误后再移除旧集群：

sudo pg_dropcluster 16 main
sudo apt purge postgresql-16

旧集群的数据目录是您最快的回滚手段。升级当天请勿将其删除。

MySQL 8.0 到 8.4：导致服务器无法启动的已移除选项

26.04 版本将 MySQL 从 8.0 升级至 8.4 LTS，其中两项变更会影响服务器运行。

首先，如果配置文件中包含新版本已移除的选项，mysqld 将拒绝启动。default_authentication_plugin 是最常见的选项，因为许多旧教程仍建议配置它。服务会启动失败，journalctl -u mysql -n 50 会直接指出该未知变量。请从 /etc/mysql/mysql.conf.d/ 下的文件中删除该行，然后执行 sudo systemctl start mysql。

其次，mysql_native_password 插件在 8.4 版本中不再默认启用，因此仍在使用该插件的账户将无法登录。请在 8.0 版本期间进行检查：

sudo mysql -e "SELECT user, host, plugin FROM mysql.user;"

在升级前，将所有显示 mysql_native_password 的账户迁移过来，并更新应用程序配置中的密码：

ALTER USER 'appuser'@'localhost' IDENTIFIED WITH caching_sha2_password BY 'a new password';

如果客户端库版本过旧，无法支持 caching_sha2_password，您可以在 8.4 中通过在 [mysqld] 下添加 mysql_native_password=ON 来重新启用旧插件。请将此视为有期限的过渡方案，因为该插件即将被彻底弃用。

PHP 8.3 升级至 8.5：虚拟主机指向的套接字已失效

24.04 版本预装 PHP 8.3，而 26.04 版本预装 PHP 8.5。软件包安装在带版本号的路径中，系统不会自动重写 Web 服务器配置。若 Nginx 虚拟主机中配置的 fastcgi_pass unix:/run/php/php8.3-fpm.sock; 现在指向一个没有进程创建的套接字，则所有 PHP 请求都会返回 502 错误，且 Nginx 错误日志会显示：

connect() to unix:/run/php/php8.3-fpm.sock failed (2: No such file or directory)

将其指向新的套接字，测试配置并重载服务：

sudo sed -i 's/php8.3-fpm.sock/php8.5-fpm.sock/' /etc/nginx/sites-available/example.com
sudo nginx -t
sudo systemctl reload nginx

在运行 mod_php 的 Apache 上，症状有所不同：Apache 将无法启动，且 sudo apache2ctl -t 会报错称无法加载 libphp8.3.so，因为该文件不存在。已启用的模块是一个指向已移除软件包的符号链接。

sudo a2dismod php8.3
sudo a2enmod php8.5
sudo systemctl restart apache2

如果您是根据 Ubuntu 24.04 上的 LAMP 堆栈 指南构建的服务器，则这两个路径都值得检查，因为该指南留下的模块名称和套接字路径均带有版本号。

您的 php.ini 调优配置也不会自动迁移。memory_limit、upload_max_filesize 以及您设置的任何其他参数都位于 /etc/php/8.3/ 中，而新的目录结构会从默认配置开始。请对比这两个文件并手动复制数值。直接用旧文件覆盖新文件会将 8.3 的默认配置带入 8.5 的安装中。随后运行 php -m 并进行比较：以 php8.3-redis 形式安装的扩展需要其 php8.5- 软件包；如果该扩展来自 PPA，升级程序会禁用该源，导致扩展直接丢失。

证书需要单独检查一次。升级后运行 sudo certbot renew --dry-run。它会模拟完整的续期流程，包括 Web 服务器重载钩子，但不会触及现有的实时证书。如果钩子调用的服务名称或二进制文件发生了变更，此操作会直接报错，从而避免 60 天后静默失败。Nginx 上使用 Certbot 和 Let's Encrypt 介绍了这些钩子应有的配置方式。

SSH：导致当前会话中断的故障

sshd_config 提示符是用户将自己锁定在系统之外的常见原因。选择 Y 会安装维护者提供的文件，这会丢弃您的 PermitRootLogin、PasswordAuthentication、AllowUsers、Port 以及您添加的所有其他行。如果您的防火墙仅允许自定义端口，而打包的配置文件监听在 22 端口，那么下一次连接将被拒绝，而您当前所在的会话将成为您拥有的最后一个会话。

请在升级前预防此问题。24.04 上的 /etc/ssh/sshd_config 以 Include /etc/ssh/sshd_config.d/*.conf 开头，OpenSSH 会保留其读取到的每个设置的第一个值，因此放置在顶部的插入式文件（drop-in）优先级高于下方的任何设置。将您的设置移至一个不属于 dpkg 管理的文件中：

sudo tee /etc/ssh/sshd_config.d/99-local.conf > /dev/null <<'EOF'
PermitRootLogin no
PasswordAuthentication no
AllowUsers deploy
EOF
sudo chmod 644 /etc/ssh/sshd_config.d/99-local.conf
sudo sshd -t && sudo systemctl restart ssh

一旦 /etc/ssh/sshd_config 中不再包含您的自定义配置，该提示符就不再重要了：无论选择哪种方式，您的设置都会被保留，因为它们位于不同的文件中。

自定义端口还需要额外检查，因为它可能不在您预想的位置：

systemctl is-enabled ssh.socket

如果输出显示 enabled，则说明 systemd 接管了监听端口，而 sshd_config 中的 Port 行将被忽略。Ubuntu 自 22.10 版本起对 sshd 使用套接字激活（socket activation），这就是为什么修改 Port 2222 似乎无效的原因。请改用 sudo systemctl edit ssh.socket 在套接字单元中进行设置：

[Socket]
ListenStream=
ListenStream=2222

必须留空 ListenStream=。它会清除继承的值，否则套接字将同时监听 22 和 2222 端口。使用 sudo systemctl daemon-reload && sudo systemctl restart ssh.socket 应用更改。

升级完成后，在关闭当前会话之前：

sudo sshd -t
sudo systemctl status ssh.socket --no-pager
sudo ss -lntp | grep -E ':(22|2222)'

然后在您的本地机器上打开第二个终端并重新登录。在第二个终端中获得可用的 shell 是唯一有效的验证方式。在确认成功之前，请保持第一个会话开启。加固 VPS 上的 SSH 详细介绍了值得保留在插入式文件中的设置。

如果为时已晚，您的服务商提供的 Web 控制台可以提供不依赖 SSH 的登录方式。通过控制台登录，修复配置，运行 sudo sshd -t，然后重启服务。这正是为什么要在升级前而不是升级过程中测试控制台访问权限的原因。

FAQ

为什么在 Ubuntu 24.04 上运行 do-release-upgrade 时提示 "No new release found"？

因为 /etc/update-manager/release-upgrades 在 Ubuntu Server 上包含 Prompt=lts，该设置仅在第一个点版本发布后才会提供下一个长期支持版本。Ubuntu 26.04 LTS 于 2026 年 4 月 23 日发布，而 26.04.1 计划于 2026 年 8 月 27 日发布。在此日期之前，24.04 服务器无法检测到新版本。请保持该设置不变，不要切换到 Prompt=normal，否则系统会引导你通过中间版本进行升级。

升级完成后必须重启服务器吗？

是的。升级会安装新的内核、C 库和初始化系统，而运行中的系统在重启前仍会使用旧版本。do-release-upgrade 会在结束时提示重启，如果推迟重启，机器将处于两个版本混合运行的状态。重启后，请使用 uname -r 检查新内核，并使用 systemctl --failed 检查未能正常启动的服务。

我应该进行原地升级还是构建一台全新的 26.04 服务器？

条件允许时请构建新服务器。使用新的 VPS 可以安装软件栈、恢复数据并进行全面测试，此时旧服务器仍可处理流量，因此回滚只需更改 DNS，无需从备份恢复。当服务器包含难以迁移的状态、服务商按机器计费，或者你有快照且拥有可靠的控制台访问权限时，可以选择原地升级。原地升级路径虽然成熟，但在运行期间是不可逆的操作。

升级过程中 SSH 连接断开会怎样？

在普通的登录 Shell 中，进程会收到 SIGHUP 信号并中途终止，导致 dpkg 处于半配置状态。在 tmux 或 screen 中启动升级进程可以避免此问题，连接断开后只需重新连接并运行 tmux attach -t upgrade 即可恢复。升级程序还会额外在 1022 端口启动一个备用 SSH 守护进程作为第二访问路径，但它不会自动打开防火墙端口，因此请务必先手动放行 1022 端口，并在升级后将其关闭。

升级后我的 PHP 站点返回 502 错误，是什么原因？

PHP FPM 的套接字路径随版本发生了变化。Ubuntu 24.04 运行 PHP 8.3，而 26.04 运行 PHP 8.5，因此 /run/php/php8.3-fpm.sock 已不存在，但你的 nginx 虚拟主机配置中仍指向该路径。nginx 错误日志会显示 connect() to unix:/run/php/php8.3-fpm.sock failed (2: No such file or directory)。请将 fastcgi_pass 更新为 8.5 的套接字路径，运行 sudo nginx -t，然后重载 nginx。对于使用 mod_php 的 Apache，相应的修复方法是执行 sudo a2dismod php8.3，随后运行 sudo a2enmod php8.5 并重启服务。