do-release-upgrade 找不到新版本：原因与修复

do-release-upgrade 提示找不到新版本

以 do-release-upgrade 开头并以 No new release found. 结尾的提示，几乎从来不表示工具本身损坏。您请求的升级路径在当前时刻不可用，工具只能用最简短的方式报告这一点。导致升级路径不可用的原因有5种：/etc/update-manager/release-upgrades 中的 Prompt 设置、LTS（长期支持）升级的版本发布门槛、第三方软件源、被保留或配置未完成的软件包，以及已超过支持期限的版本。

请按此顺序逐项检查。每种情况都有一个命令可以证明它是否适用于您的服务器，因此无需猜测当前遇到的是哪一种原因。

仅检查标志实际报告的内容

sudo do-release-upgrade -c
echo $?

-c表示仅执行检查。它通过 HTTPS（安全超文本传输协议）读取 Canonical 的版本元数据并输出结果。它不会下载升级工具，也不会改写源文件。需要关注两项输出：

Checking for a new Ubuntu release
No new release found.

Checking for a new Ubuntu release
New release '26.04.1 LTS' available.
Run 'do-release-upgrade' to upgrade to it.

退出码会为脚本返回相同的结果。有可用版本时，退出码为 0；没有可用版本时，退出码为 1。这与通常的 shell 约定相反，因此在据此编写检查逻辑前要仔细确认。

如果登录提示仍显示旧结果，说明该结果来自缓存。该行来自 /etc/update-motd.d/91-release-upgrade，它会输出已保存的结果，而不是访问网络查询。使用 sudo /usr/lib/ubuntu-release-upgrader/release-upgrade-motd 刷新，或者直接信任 -c。登录提示只会重复上一次检查的结果。

检查还需要连接到 changelogs.ubuntu.com。如果服务器位于严格限制出站流量的防火墙之后，或需要通过代理访问，而该工具无法发出请求，就无法发现任何版本。

curl -sI https://changelogs.ubuntu.com/meta-release-lts | head -n 1

HTTP/2 200 行表示服务器可以读取元数据。curl: (28) Connection timed out 表示真正原因是出站规则，编辑多少 APT（高级软件包工具）文件都不会改变结果。

如果系统完全找不到该命令，它位于 ubuntu-release-upgrader-core 中。某些精简云镜像会省略该软件包。

sudo apt install ubuntu-release-upgrader-core

更改任何内容前，先读取 /etc/update-manager/release-upgrades

cat /etc/update-manager/release-upgrades

[DEFAULT]
Prompt=lts

该文件在注释中包含自身的说明。有效值有 3 个：

• never：从不检查新版本，也不允许升级到新版本。
• normal：提供紧接当前运行版本之后的受支持版本。
• lts：提供当前运行版本之后的第一个 LTS 版本。

Prompt=never 是 3 个值中最容易诊断的，因为该工具会在输出中同时指出文件和设置：

Checking for a new Ubuntu release
In /etc/update-manager/release-upgrades Prompt is set to never so upgrading is not possible.

托管服务提供商和配置管理工具会有意设置 never，以防止服务器集群在不同版本之间逐渐偏离。如果你在那里发现了它，说明这是有人做出的选择。对于希望使用长期支持版本的服务器，将其改为 lts；如果自动化流程依赖旧值，完成操作后再改回去。

注释中有一个细节容易导致误解。当设置为 Prompt=lts 且当前运行版本本身不是 LTS 版本时，升级工具会将该设置视为 normal。在 25.10 计算机上，这两个值的行为相同。在 24.04 计算机上则不同，而这一差异正是下一节的全部内容。

为什么从一个 LTS 版本升级到下一个 LTS 版本时，要等到首个点版本发布

Prompt 决定升级程序读取哪个元数据文件。文件地址位于 /etc/update-manager/meta-release：

[METARELEASE]
URI = https://changelogs.ubuntu.com/meta-release
URI_LTS = https://changelogs.ubuntu.com/meta-release-lts
URI_UNSTABLE_POSTFIX = -development
URI_PROPOSED_POSTFIX = -proposed

Prompt=lts 读取 meta-release-lts。Prompt=normal 读取 meta-release。这两个文件都用一小组键描述每个版本；只有当某个版本的 Supported: 标志为 1 时，升级程序才会提供该版本。您可以从同一台服务器直接查看这些文件：

curl -s https://changelogs.ubuntu.com/meta-release-lts | grep -A 4 resolute
curl -s https://changelogs.ubuntu.com/meta-release | grep -A 4 resolute

截至 13 August 2026，这两个文件对 Ubuntu 26.04 的信息并不一致。LTS 文件显示：

Dist: resolute
Name: Resolute Raccoon
Version: 26.04 LTS
Date: Thu, 23 April 2026 00:26:04 UTC
Supported: 0

普通文件显示：

Dist: resolute
Name: Resolute Raccoon
Version: 26.04 LTS
Date: Thu, 23 April 2026 00:26:04 UTC
Supported: 1

LTS 文件中的 Supported: 0 就是放行条件。使用默认 Prompt=lts 的 24.04 服务器会读取该文件，发现没有标记为可用的更新 LTS 版本，然后显示 No new release found.。您的机器没有问题。Canonical 尚未开放升级路径。

首个点版本发布后，该标志会变为 1。Ubuntu 26.04.1 计划于 27 August 2026 发布，但版本计划可能调整，因此应检查元数据，而不要只看日历。点版本不是新的 Ubuntu 版本，而是在全新安装介质中整合了发布以来所有更新的同一版本。因此，对正在运行的服务器而言，重要的是它开启的放行条件，而不是安装介质本身。延迟是有意安排的：较早升级的用户会发现阻塞问题，相关问题会在数量更多的 LTS 服务器升级前得到修复。

因此有两个合理选择。等待点版本发布。这是适合不希望持续观察服务器的情况的选择。或者设置 Prompt=normal，让同一工具改为使用 meta-release；其中 26.04 已标记为受支持。第二种方式会将系统升级到已发布的 26.04，而不是开发版本，因此如果您可以从快照恢复，在这台机器上采用这种方式是合理的。完成后，将该值改回 lts。完整的操作步骤请参阅24.04 到 26.04 的完整服务器升级指南。

阻止升级的第三方软件仓库和 PPA

升级程序会重写 APT 源，使其指向新版本。只有为新版本发布软件包的仓库才能这样处理，因此其他仓库都会被注释掉。程序会为每个条目单独打印原因，具体包括：was disabled (unknown mirror)、was disabled (unknown dist) 和 was disabled (no Release file)。

为 noble 构建的 PPA 在服务器上没有 resolute 目录，因此升级程序无法为新系列获取 Release 文件，并会禁用该条目。这通常只是警告，可以接受。如果第三方仓库提供了新版本也会发布的软件包，问题就会升级为阻断条件，因为升级计算会得到两个候选版本，无法同时满足两者的依赖关系。

应在开始前自行决定，而不是让工具在长时间无人值守运行期间作出决定。

ls /etc/apt/sources.list.d/
apt policy nginx
sudo add-apt-repository --remove ppa:example/ppa

对软件包名称使用 apt policy，可以显示每个已安装版本来自哪个仓库。这样可以准确查看哪些软件包依赖于即将禁用的软件源。删除软件源不会降级任何软件包，因此从 PPA 安装的软件包仍会保留 PPA 版本，并且可能比新版本中提供的版本更新。如果这会造成问题，请同时删除该软件包，并在升级后从软件包仓库重新安装。计划恢复使用的仓库（例如 Tailscale 的仓库）必须先将其代号更新为新版本，否则无法再次安装软件包。Ubuntu 上大多数 Tailscale 安装错误都由此引起。

也可以选择相反的做法。手册页将 --allow-third-party 描述为“在启用第三方镜像和仓库的情况下尝试升级，而不是将其注释掉”。只有在确认该仓库已经为目标版本发布软件包时，才应使用此选项。如果没有，等于要求 APT 根据该仓库从未构建过的软件系列解析依赖关系。

在 Ubuntu 24.04 及更高版本中，大多数软件源以 deb822 格式存放在 /etc/apt/sources.list.d/ubuntu.sources 中。同一个仓库同时以旧格式和新格式写入，会产生另一个独立错误，并显示专属错误消息。详见 deb822 格式中的重复软件源条目错误。

已保留和仅完成部分配置的软件包会阻止计算

版本升级需要迁移系统中的几乎所有软件包。如果某个软件包无法迁移，计算就会失败。升级程序宁愿提前停止，也不会让系统停在半完成状态。使用以下两个命令查找原因。

apt-mark showhold
sudo dpkg --audit

apt-mark showhold会逐行列出已保留的软件包。在正常系统上不会输出任何内容。保留表示手动指示系统永远不要更改该软件包。有人可能固定了某个内核或数据库版本，之后忘记取消。对于不再需要保留的软件包，使用 sudo apt-mark unhold，后面加软件包名称即可解除保留。

dpkg --audit会列出已解包但尚未配置的软件包。这种状态通常源于安装过程被中断，最常见的原因是会话断开。升级程序会尝试修复这些问题，并输出 dpkg interrupted, calling dpkg --configure -a。但先自行运行修复命令，可以直接读取错误，而不是看着错误信息快速滚过。工具无法修复的软件包会产生消息 Package in inconsistent state。重新尝试前必须先处理该问题。

升级前，先让当前版本完全更新。

sudo apt update
sudo apt full-upgrade -o APT::Get::Always-Include-Phased-Updates=true
sudo apt --fix-broken install
sudo dpkg --configure -a
sudo reboot

分阶段更新选项的重要性通常超出预期。Ubuntu 会按机器比例逐步推出部分更新，因此直接运行 apt upgrade 可能会正常地留下未更新的软件包。这样服务器的更新程度就会低于预期。该选项会安装所有更新。如果其中包含内核，之后请重启系统，以便在实际运行的内核上执行升级。已经通过 无人值守安全升级 自动保持更新的服务器需要处理的内容较少。不过，这种机制按设计不会跨越版本边界。

标准支持结束后版本已过期

Ubuntu 临时版本支持九个月。支持结束后，其 Supported: 标志会变为 0，而常规升级路径不会提供从该版本升级的方式。经 2026 年 8 月 13 日检查，meta-release 对 25.10 的说明如下：

Dist: questing
Name: Questing Quokka
Version: 25.10
Date: Thu, 09 October 2025 00:25:10 UTC
Supported: 0

软件包归档也会同时迁移。生命周期结束版本的软件包会从 archive.ubuntu.com 移除，并保存在 old-releases.ubuntu.com 中。因此，apt update 会开始返回 404 Not Found，系统无法再更新到最新状态；由于升级程序要求系统处于最新状态，升级过程不会继续。请先修复软件源。

lsb_release -cs
grep -rn ubuntu.com /etc/apt/sources.list /etc/apt/sources.list.d/

将 archive.ubuntu.com 和 security.ubuntu.com 都指向 old-releases.ubuntu.com，不要修改您的版本代号。只需更改主机名。

sudo sed -i.bak -e 's/archive.ubuntu.com/old-releases.ubuntu.com/g' \
                -e 's/security.ubuntu.com/old-releases.ubuntu.com/g' \
                /etc/apt/sources.list.d/ubuntu.sources
sudo apt update

如果您的服务器仍将软件源保存在该单个文件中，请改为对 /etc/apt/sources.list 执行相同的命令。-i.bak 选项会在原文件旁写入备份，因此如果编辑的目标文件不正确，您可以恢复原文件。之后，如果 apt update 正常完成，说明归档已可访问，do-release-upgrade 现在就会与您通信。

请合理评估这种方式能将系统升级到什么程度。Ubuntu 每次只支持跨越一个版本升级，因此落后两个或三个已停止支持的版本的服务器，必须依次完成每个升级步骤；每一步都可能因其自身的第三方软件源或被保留的软件包而失败。在 VPS 上，通常更快的做法是在当前 LTS 版本上创建新服务器，迁移服务，并保留旧服务器，直到确认新服务器运行正常。这样还可以提供回滚方案，而原地升级无法提供该方案。如果您要决定之后使用哪条版本路线，建议先阅读服务器上的 LTS 与临时版本有何区别，再做决定。

开发版发布标志的实际作用

-d 或 --devel-release 会让升级程序读取 meta-release-development，而不是读取由 Prompt 选择的文件。手册页将其描述为：“如果正在使用最新的受支持版本，则升级到开发版。”

截至 13 August 2026，该文件中的最新条目不是 26.04：

Dist: stonking
Name: Stonking Stingray
Version: 26.10
Date: Thu, 15 October 2026 00:26:10 UTC
Supported: 0

因此，-d 不会将 24.04 服务器升级到已发布的 26.04。它会指向 26.10，而该版本仍在开发中。以前建议“只需添加 -d”的做法，适用于 LTS 发布前的阶段。现在重复使用该方法，会让服务器指向并非预期的版本。由于 Prompt=lts 仍然存在，该标志会显示自身的错误消息并停止：

There is no development version of an LTS available.

Ubuntu 服务器文档明确说明了该标志：“不建议在生产环境中使用开发版（或 -d 标志）”。开发版每天都会变化，也不提供安全支持承诺。因此，早上正常工作的软件包，下午可能就会导致服务故障。请仅在专门用于测试自有配置的临时虚拟机上使用它。不要在任何人依赖的服务器上使用它。若要在 LTS 版本升级入口开放前获取已发布的 26.04，Prompt=normal 才是正确的方式。

在 SSH 会话断开后仍可继续执行升级

版本升级会替换大部分系统，包括 openssh-server 和 systemd。如果 dpkg 工作期间 SSH（安全 Shell）会话断开，进程会被终止，系统会停留在软件包已解包但尚未配置的状态。这正是导致下一次尝试失败的状态。每次都应在终端复用器中启动升级。

sudo apt install -y tmux
tmux new -s upgrade
sudo do-release-upgrade

如果连接断开，请重新登录并运行 tmux attach -t upgrade。升级仍会继续执行，因为它是 tmux 服务器的子进程，而不是 SSH 会话的子进程。如果您更喜欢使用 screen，screen -S upgrade 和 screen -r upgrade 也能完成相同的工作。

对于不使用终端复用器的用户，升级程序自带保护机制。它检测到自身在 SSH 下运行时，会询问是否在端口 1022 上启动第二个 sshd。这样，即使主会话断开，仍有其他方式可以登录。它会检查自身的父进程，查找名为 sshd 的进程。若在 tmux 或 screen 中运行，该检查会找到终端复用器服务器，因此不会显示此提示；只有额外的守护进程真正启动时，才会写入 pid 文件 /var/run/release-upgrader-sshd.pid。如果没有看到提示，不代表出现问题。您已经具备更好的保护。

如果接受此提示，端口不会自动为您开放。工具会明确说明这一点，因为开放端口属于安全决策，工具无权代您执行。请在升级期间开放该端口，升级完成后再次关闭。

sudo ufw allow 1022/tcp
sudo ufw delete allow 1022/tcp

大多数 VPS 提供商还会在操作系统之外的控制面板中运行另一层防火墙。您也必须在那里开放端口 1022，否则备用监听器虽然正在运行，却无法访问，这是最糟糕的情况。

在输入命令前，必须完成以下 4 项准备：

• 创建快照或完整备份。就地版本升级无法撤销，而这是您唯一可用的回退手段。
• 确认您可以在需要时打开提供商的控制台。如果服务器重启后无法恢复，您恰恰无法使用 SSH。无法启动的内核是另一个问题，需要单独执行恢复步骤，详见 内核更新后无法启动的 VPS。
• 使用 df -h / /boot 检查可用空间。升级会下载完整的软件包集合，而保存多个旧内核的 /boot 分区经常会成为阻塞点。
• 阅读所运行服务的发行说明。PostgreSQL 或 PHP 的主版本升级会随发行版一同到来，无论您是否提前计划。

FAQ

为什么在 Ubuntu 24.04 上运行 do-release-upgrade 时提示找不到新版本？

/etc/update-manager/release-upgrades 中的默认 Prompt=lts 会使该工具读取 https://changelogs.ubuntu.com/meta-release-lts。在 Ubuntu 26.04 首个点版本发布前，该文件中的值为 Supported: 0。升级工具找不到标记为可用的更新 LTS 版本，因此停止。使用 curl -s https://changelogs.ubuntu.com/meta-release-lts 自行检查该文件，并查看最后一个区块。截至 13 August 2026，该标志仍为 0；Ubuntu 26.04.1 计划于 27 August 2026 发布。

与其等待点版本，直接将 Prompt=normal 设置为 normal 是否安全？

这样会将系统升级到已发布的 26.04，而不是开发版本，因为 Prompt=normal 会读取 meta-release，其中 26.04 已标记为 Supported: 1。风险在于升级时机。你会在早期升级用户发现的问题得到修复前进行升级。请在可以从快照恢复、并且重启失败时可以访问服务商控制台的服务器上执行。完成后将该值改回 lts。

-d 标志会将系统升级到 26.04 吗？

不会。-d 会读取 meta-release-development；截至 13 August 2026，其中最新条目是 Ubuntu 26.10，该版本仍在开发中。在设置了 Prompt=lts 的 LTS 系统上，该标志会输出 There is no development version of an LTS available.，然后停止。Ubuntu 官方服务器文档不建议在生产环境使用开发版本，因此如果要提前升级到已发布的 26.04，请使用 Prompt=normal。

在旧版本上运行 apt update 返回 404 错误。如何升级系统？

该版本已结束生命周期，因此其软件包已从 archive.ubuntu.com 移至 old-releases.ubuntu.com。只修改 /etc/apt/sources.list.d/ubuntu.sources 中的主机名；对于较旧的布局，则修改 /etc/apt/sources.list 中的主机名，并保留原有代号。然后运行 sudo apt update 和 sudo apt full-upgrade。系统恢复为最新状态后，do-release-upgrade 可以按每次一个版本的方式继续升级。

运行 do-release-upgrade 前是否需要删除 PPAs？

不需要。升级工具会注释掉不为新版本发布软件包的源，并为每个源输出类似 was disabled (no Release file) 的行。最好先手动处理，因为这样可以自行决定顺序并查看结果。对需要关注的软件包运行 apt policy，找出它们分别来自哪个 PPA；如果 PPA 中的版本高于新版本所提供的版本，则从软件包归档重新安装这些软件包。