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

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

do-release-upgrade 以 No new release found. 结尾时，几乎从来不是工具本身损坏。您请求的升级路径在当前时刻不可用，工具只能用最简短的方式报告这一点。以下五种情况会导致升级路径不可用：/etc/update-manager/release-upgrades 中的 Prompt 设置、LTS（长期支持）升级的点版本门槛、第三方软件源、被锁定或配置未完成的软件包，以及已结束支持周期的版本。

请按此顺序逐项排查。每种情况都有对应的命令，可以确认它是否适用于您的服务器，因此无需猜测当前遇到的是哪一种问题。

check-only 标志实际报告的内容

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最容易诊断，因为该工具会在输出中同时指出文件和设置：

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 发布，但发布时间可能变动，因此应检查元数据，不要只看日历。延迟是有意安排的：早期升级的用户会发现阻塞问题，开发者可以先修复这些问题，再让数量大得多的 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 及更高版本中，大多数源位于 /etc/apt/sources.list.d/ubuntu.sources，采用 deb822 格式。同一个存储库同时以旧格式和新格式写入时，会产生另一个独立错误，并显示专属错误消息；详见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 的临时版本支持期限为 9 个月。支持结束后，其 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 一次只支持跨越一个版本升级，因此落后 2 或 3 个已停止支持版本的服务器必须逐步完成每次升级；每一步都可能因各自的第三方软件源或被保持的软件包而失败。在 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 中运行，该检查会找到终端复用器服务器，因此不会显示此询问；只有额外的 daemon 真正启动时，才会写入 pid 文件 /var/run/release-upgrader-sshd.pid。如果没有看到该提示，不代表有问题。您已经获得了更好的保护。

如果接受此选项，端口不会自动为您开放。工具会明确说明这一点，因为开放端口属于安全决策，工具无权代您决定。请仅在升级期间开放该端口，完成后立即关闭。

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

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

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

• 创建快照或执行完整备份。就地版本升级无法撤销，而这是您唯一拥有的恢复点。
• 确认您可以在需要时打开提供商的控制台。如果服务器重启后无法恢复，您将无法使用 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 设置为正常模式是否安全？

这会将系统升级到已发布的 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 版本高于新版本中提供的版本，请从 Ubuntu 软件包归档重新安装这些软件包。