Ubuntu 22.04 升级到 26.04：必须经过 24.04

Ubuntu 22.04 无法直接升级到 26.04

Ubuntu 22.04 LTS 无法直接升级到 26.04 LTS。do-release-upgrade每次只跨一个 LTS 版本，因此升级路径是先从 22.04 升级到 24.04，再从 24.04 升级到 26.04，并在两次升级之间重启并完成全面检查。26.04 的发行说明明确写道：“如果当前使用的是较旧的 Ubuntu LTS 或 interim release，例如 Ubuntu 22.04 LTS 或 25.04，则必须先升级到 Ubuntu 24.04 LTS 或 25.10，然后才能继续升级到 26.04 LTS。”

第二次升级有一个门槛，现在该门槛已经开放。Canonical 只有在目标版本的第一个点版本发布，且其 meta-release 条目标记为受支持后，才提供 LTS 到 LTS 的升级。26.04.1 于 27 August 2026 发布；截至 27 October 2026，do-release-upgrade读取的文件是 https://changelogs.ubuntu.com/meta-release-lts，其中列出 26.04.1 LTS，并标记为 Supported: 1。因此，完全更新的 24.04 系统会通过普通的 do-release-upgrade 获得 26.04.1，不再显示 No new release found。开放升级曾因 rust-coreutils 中的回归问题等待 backports；这些修复已经发布，因此 26.04.1 公告中提到的 -d 标志已不再需要。不过，仍应使用 do-release-upgrade -c 在自己的系统上确认，不要只相信日期。为什么 LTS 升级要等到 .1 点版本介绍了该门槛的原因。

两次升级意味着两次重启，以及两轮禁用第三方软件源；PHP、Python、PostgreSQL 和内核还会在同一台服务器上跨越 4 年进行主要版本升级。本指南的大部分内容都用于处理这些变化。第二次升级的步骤已在从 24.04 升级到 26.04 的指南中逐步说明，因此本文不再重复。现在开始的原因是：22.04 的标准支持将于 2027 年结束，此后只有Ubuntu Pro 的扩展安全维护或付费的第三方延长支持服务会继续为其提供补丁。

升级程序为何拒绝跳过一个发行版

do-release-upgrade 本身不包含升级逻辑。它会下载元发行版文件 UpgradeTool 行中指定的 tarball；24.04 对应 noble.tar.gz，26.04 对应 resolute.tar.gz。该 tarball 包含一个仅针对固定源发行版列表编写的脚本。该列表位于升级程序的 DistUpgrade.cfg 中的 From= 行。上次于 20 October 2026 检查时，26.04 的该行内容为 noble,oracular,plucky,questing：24.04 LTS，以及其后的 3 个临时发行版 24.10、25.04 和 25.10。这些临时发行版已停止支持，但升级程序仍接受它们作为起始版本。jammy 不在列表中，因此 26.04 升级程序在 22.04 系统上会因错误而停止，而不会开始升级。每个软件包的维护脚本、用于迁移配置文件的 preinst 和 postinst 钩子，都只针对这些升级路径进行了测试。将 22.04 直接升级到 26.04 会让 26.04 的脚本处理它们从未见过的配置状态，dpkg 可能在中途停止，导致系统损坏。

将 /etc/update-manager/release-upgrades 中的设置切换为 Prompt=normal 也无法绕过这一限制。Ubuntu 在该文件中的注释说明，normal 的目标是“紧接当前运行发行版之后的受支持发行版”，而升级检查会跳过元发行版文件标记为不受支持的所有发行版。22.10、23.04 和 23.10 在该文件中均标记为 Supported: 0（于 27 October 2026 检查），因此从 22.04 出发，normal 提供的版本是 24.04，与 lts 提供的目标相同。保留 Prompt=lts。现在发行版可用性门槛已经开放，如果 24.04 系统仍提示 No new release found，原因就在本地；do-release-upgrade 找不到版本的原因 几乎总是该文件或某个被锁定的元软件包。

就地升级，还是新建一个 26.04 VPS？

就地升级会保留数据和配置，但需要安排两个维护窗口。新建 26.04 VPS 再迁移，前期工作量更大，但最终得到的是一个干净的系统。满足以下任一条件时，应选择迁移。

• 服务器已经从 20.04 或更早版本进行过一次就地升级。每次升级都会遗留过时的软件包和陈旧配置，三次升级累积的遗留内容很难排查。
• 已启用超过两个或三个第三方软件源或 PPA。每次升级都会禁用这些源，并且必须逐一确认它们是否提供针对新版本代号构建的软件包。
• 已安装控制面板或 out-of-tree 内核模块。这些组件会在内核升级时失效，且不属于 do-release-upgrade 能修复的范围。
• 无法创建快照。没有回滚点时，对生产服务器执行就地升级存在无法撤销的风险。

将服务器迁移到新的 VPS介绍复制数据和切换服务的步骤。本指南其余部分均假设您选择了就地升级。

升级前：创建快照、检查空间，并确保 22.04 状态干净

先将 22.04 完全更新到最新状态。否则升级程序会拒绝启动，并显示 Please install all available updates for your release before upgrading.

lsb_release -a
sudo apt update && sudo apt full-upgrade -y
sudo apt autoremove --purge -y
sudo reboot

重启后，lsb_release -rs 应输出 22.04，而 uname -r 应显示预期的内核：GA 系列为 5.15.x，HWE 系列为 6.8.x。如果不确定当前使用的是哪个系列，请参阅GA 与 HWE 内核说明，了解如何识别以及这对升级为何重要。

检查磁盘空间。升级程序会在安装前下载所有软件包。单独的 /boot 分区通常存放多个旧内核，也是最常见的空间耗尽位置。

df -h / /boot
dpkg -l 'linux-image-*' | grep ^ii

确保 / 至少有 5 GB 可用空间。如果 /boot 的可用空间少于 200 MB，请在开始前删除旧内核，不要等升级程序中止后再处理。

现在在服务商控制面板中创建快照，并等待快照完成。快照是整个磁盘的回滚点，正适合处理失败的版本升级。但它不是备份；此处快照与备份的区别很重要：仍应继续执行常规备份。然后记录升级前的系统状态。

apt-mark showmanual > ~/manual-packages-22.04.txt
apt-cache policy | grep -oE 'https?://[^ ]+' | sort -u > ~/apt-sources-22.04.txt
ls /etc/apt/sources.list.d/
php -v; python3 --version; node -v; psql --version; mysql --version
sudo iptables-save > ~/iptables-22.04.rules
sudo cp -a /etc/netplan ~/netplan-22.04

如果未安装相应的软件栈，其中一些命令会输出 command not found。这没有问题。关键是留下 22.04 上运行内容的记录，因为经过两次升级后，您不会记得旧站点需要哪个 PHP 版本。

最后确认 /etc/update-manager/release-upgrades 的值为 Prompt=lts，并为该服务器打开第二个 SSH 会话。在整个升级过程中保持该会话打开。

第 1 跳：从 22.04 升级到 24.04

sudo do-release-upgrade -c

预期输出：

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

从 sudo do-release-upgrade 开始。通过 SSH 连接时，首先会看到此提示：

This session appears to be running under ssh. It is not recommended
to perform a upgrade over ssh currently because in case of failure it
is harder to recover.

If you continue, an additional ssh daemon will be started at port
'1022'.
Do you want to continue?

回答 yes，然后从第二个会话开放该端口，因为升级程序会提示它不会代你执行此操作：

sudo ufw allow 1022/tcp

如果使用 nftables 或原始 iptables，而不是 ufw，请添加等效规则。如果服务提供商有网络防火墙，也请在其中开放端口 1022，因为这与服务器本身的防火墙是独立的控制层。

升级程序在 screen 会话中运行，因此连接中断不会终止升级。重新连接后，使用 sudo screen -ls，再使用 sudo screen -r 重新附加会话。随后，升级程序会读取软件包列表并显示摘要：将安装和删除的软件包数量，以及下载所需的时间。注意“删除”数量。在普通服务器上，如果该数量超过几十个，应先按 d 查看详细信息，再继续。

升级过程中有 3 个提示需要注意。

已禁用第三方源。 升级程序会注释掉所有无法识别为 Ubuntu 自有源的 apt 源，并将每行标记为 # disabled on upgrade to noble。这是必要的，因为包含 jammy 的行会提供为旧版本构建的软件包。你将在检查点逐个重新启用这些源。

配置文件提示。 对于由 dpkg 跟踪的已修改配置文件（即 conffile），dpkg 会询问是否安装软件包维护者提供的版本。默认选项 N 会保留你的版本。/etc/ssh/sshd_config 是最可能被你修改的文件，但处理方式不同：openssh-server 通过 ucf 管理该文件，而不是使用 dpkg 的 conffile 机制，因此提示会显示 What do you want to do about modified configuration file sshd_config?，并提供 install the package maintainer's version 或 keep the local version currently installed。除非明确知道不应这样做，否则请保留本地版本，这是 ucf 的默认选项，因为维护者版本会重置 PasswordAuthentication 和 Port，而你正是通过该 daemon 连接的。

删除已废弃的软件包？ 此操作会删除存在于 22.04、但不存在于 24.04 的软件包。如果运行 PostgreSQL，postgresql-14 不在该列表中：升级程序的删除阻止列表会保护所有带版本号的 PostgreSQL 软件包，因为清除其中一个软件包可能会删除其集群，而 pg_upgradecluster 需要使用这些二进制文件迁移数据。如果列表中的其他项目仍有用，请回答 N。检查点之后，可以使用 sudo apt autoremove --purge 删除已废弃的软件包；该命令不会删除仍包含集群的 PostgreSQL 版本。

小型 VPS 的升级通常需要 30 到 60 分钟，其中大部分时间用于 dpkg 解包，而不是下载。完成后，程序会询问是否重启。回答 yes。

跳转之间的检查点

在此清单确认无误前，不要开始第二个跳转。两轮故障叠加在一起，远比单独排查一轮故障困难；而且 24.04 的标准支持期持续到 2029 年，因此在这里暂停一周不会造成任何损失。

lsb_release -rs
uname -r
systemctl --failed
sudo apt update && sudo apt full-upgrade -y

lsb_release -rs 必须输出 24.04，并且 uname -r 应以 6.8 开头，也就是 24.04 的 GA 内核；除非该服务器运行的是可选的 24.04 HWE 内核系列，该系列当前为 7.0。systemctl --failed 应输出 0 loaded units listed。其中列出的任何单元，都是你首先需要处理的问题。

然后检查 apt 源。noble 升级程序会将 /etc/apt/sources.list 转换为 /etc/apt/sources.list.d/ubuntu.sources，也就是 deb822 格式，并在旧文件中保留一条指向新文件的注释。如果之后将针对同一存档、套件和组件的旧格式 deb http://... 行重新粘贴到 sources.list 中，apt 会在两个文件中发现同一个软件仓库，并输出 is configured multiple times。删除旧格式的行或将其注释掉后，该重复源错误 就会消失。

grep -r 'disabled on upgrade' /etc/apt/sources.list /etc/apt/sources.list.d/

对于每一条已禁用的行，判断是否需要启用。如果供应商发布了 noble 套件，将 jammy 改为 noble，删除注释标记，然后运行 sudo apt update。如果输出 E: The repository '... noble Release' does not have a Release file.，说明供应商没有适用于 24.04 的构建；保留该行的禁用状态，或寻找其他源。对 PPA 执行相同操作。然后检查下一节中适用于你服务器的每一项，再次重启一次，确认你关心的每项服务都能正常响应，并创建一个全新快照。为快照命名，以便与 22.04 快照区分；在确认 26.04 正常前，保留这两个快照。

两次升级之间会出现什么问题

这些问题单独看，都是 24.04 或 26.04 上的常见问题。连续完成两次升级会让它们同时出现，因此应在检查点分别修复，避免第二次升级使问题加重。

第三方软件源和 PPA 会被禁用两次

第一次升级时，所有非 Ubuntu 软件源都会被注释掉；第二次升级时也会如此，此时标记为 # disabled on upgrade to resolute。仅为 jammy 和 noble 构建的 PPA，在首日不会有 resolute 软件源，而 does not have a Release file 错误会显示这一点。在 Web 服务器上，最常见的软件源包括来自 download.docker.com 的 Docker CE、NodeSource、ppa:ondrej/php 和 Tailscale 软件源；除 NodeSource 外，它们都会在 apt 软件源行中写入发行版代号。当前的 NodeSource 配置会将 nodistro 写为软件源套件，因此两次升级都不会改动它。Docker 软件源需要在两次升级时都修改发行版代号。或者，26.04 软件仓库中的 docker.io 软件包版本为 29，已经足够新，许多服务器完全不再需要供应商软件源。如果 Tailscale 软件源行属于你的配置，Ubuntu 上的 Tailscale 安装错误正是过时发行版代号导致的问题。

PHP 连续跨越两个主版本：8.1、8.3，然后是 8.5

Ubuntu 22.04 提供 PHP 8.1，24.04 提供 8.3，26.04 提供 8.5。如果你通过未指定版本的元软件包安装了 php-fpm，第一次升级会在 php8.1-fpm 旁边安装 php8.3-fpm，并同时启动两者。没有任何配置会自动切换 Web 服务器，因此 nginx 会继续连接 8.1 套接字并正常工作，直到你删除过时软件包，错误日志开始充满以下内容：

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

解决方法是让 fastcgi_pass 指向 unix:/run/php/php8.3-fpm.sock，运行 sudo nginx -t，然后重新加载配置。在使用 mod_php 的 Apache 上，运行 sudo a2dismod php8.1 && sudo a2enmod php8.3 && sudo systemctl restart apache2。在 8.3 的检查点执行这些操作并运行应用测试；第二次升级后，再针对 8.5 重复执行。尚不能在 8.5 上运行的应用，是在 26.04 上重新启用 ppa:ondrej/php 的唯一实际理由，因为该 PPA 为每个当前 Ubuntu 版本提供所有 PHP 版本。同样的步骤也适用于基于 24.04 构建的 LAMP 栈，但它只会遇到这次跳跃的后半段。

Python：从 3.10 到 3.12，再到 3.14；pip 不再写入系统环境

系统 Python 在第一次升级时从 3.10 变为 3.12，在第二次升级时变为 3.14。会出现两个问题。首先，在 22.04 上创建的每个 virtualenv 都将 bin/python 设为指向 /usr/bin/python3.10 的符号链接；删除过时软件包时，链接目标会被删除，因此 venv 会失败并显示 No such file or directory。使用 python3 -m venv --clear .venv 重建每个 venv，并重新安装其依赖项。其次，从 24.04 开始，在 venv 外运行 pip install 会拒绝执行，并显示：

error: externally-managed-environment

这是 PEP 668 的保护机制，用于防止覆盖由 apt 管理的 Python 软件包。请使用 venv 或 apt install python3-<name>，不要使用错误消息中提到的 --break-system-packages 标志。

Node：使用软件仓库中的 12 到 18，或使用 NodeSource

软件仓库中的 nodejs 软件包在 22.04 上为 12.22，在 24.04 上为 18.19，因此使用 Node 12 构建的应用会一次性遇到 4 年间移除的 API。大多数生产服务器改用 NodeSource；NodeSource 固定一个特定主版本，因此两次升级都不会改变版本。只需重新启用软件源行。

数据库：PostgreSQL 从 14 到 16，再到 18；MySQL 8.4 会锁定账户

第一次升级会在 14 集群旁边安装 PostgreSQL 16，并为新的空集群分配端口 5433。pg_lsclusters 会显示两个集群。你的数据仍在端口 5432 上的 14 集群中。在检查点迁移数据：

pg_lsclusters
sudo pg_dropcluster --stop 16 main
sudo pg_upgradecluster 14 main
pg_lsclusters

pg_upgradecluster 会导出 14 集群的数据，并将其加载到端口 5432 上的新 16 集群，然后停止 14 集群并为其保留端口 5433。检查应用，然后运行 sudo pg_dropcluster 14 main。第二次升级后，软件仓库会提供 PostgreSQL 18；使用 16 和 18 重复相同的 4 条命令。这就是升级程序不会将 postgresql-14 删除为过时软件包的原因，也是 apt autoremove 在该集群存在时不会处理它的原因：pg_upgradecluster 会运行旧服务器的二进制文件来读取旧数据。

22.04 和 24.04 都使用 MySQL 8.0，因此第一次升级不会改变任何内容。第二次升级会变为 8.4，并禁用 mysql_native_password 插件；发行说明称，使用该插件的账户“默认会被锁定”。客户端会显示 ERROR 1524 (HY000): Plugin 'mysql_native_password' is not loaded。在检查点、仍使用 8.0 时，找出这些账户：

SELECT user, host, plugin FROM mysql.user WHERE plugin = 'mysql_native_password';
ALTER USER 'app'@'localhost' IDENTIFIED WITH caching_sha2_password BY 'the-same-password';

无法使用 caching_sha2_password 的旧 PHP 和 Python 驱动程序是这些账户存在的原因，因此每次 ALTER USER 后都要测试应用。

22.04 时代的 netplan 文件

许多 22.04 时代的 VPS 镜像会以 gateway4: 创建 /etc/netplan/50-cloud-init.yaml，并设置为全局可读权限。24.04 上的 Netplan 1.0 和 26.04 上的 1.2 仍接受这两种配置，但首次运行 sudo netplan generate 时会显示警告：

** (generate:1234): WARNING **: 10:21:07.512: Permissions for /etc/netplan/50-cloud-init.yaml are too open. Netplan configuration should NOT be accessible by others.
** (generate:1234): WARNING **: 10:21:07.513: `gateway4` has been deprecated, use default routes instead.

使用 sudo chmod 600 /etc/netplan/*.yaml 修复权限。将 gateway4: 203.0.113.1 替换为默认路由：

routes:
  - to: default
    via: 203.0.113.1

使用 sudo netplan try 测试，不要使用 netplan apply。try 会应用更改，并在 120 秒后自动恢复，除非你按 Enter。因此，即使错误导致 SSH 会话断开，也会自动恢复。在 24.04 的检查点执行此操作，因为第二次升级后才发现的 netplan 错误看起来与第二次升级问题完全相同。

iptables-legacy 会在两次升级后继续保留

自 20.10 起，Ubuntu 的 iptables 一直使用 nftables 后端。某台 22.04 服务器如果因旧版 Docker 或防火墙脚本，通过 update-alternatives --set iptables /usr/sbin/iptables-legacy 切换到 legacy 后端，该选择会在两次升级中保留，因为 update-alternatives 不会覆盖手动选择。检查方式如下：

sudo iptables -V
sudo update-alternatives --display iptables | head -3
sudo nft list ruleset | head

iptables v1.8.x (legacy) 表示 legacy 后端。它仍能正常工作，而这正是问题所在：通过 legacy 工具加载的规则和通过 nftables 加载的规则都会在内核中运行，但两个工具都看不到另一个工具加载的规则，因此 nft list ruleset 几乎为空，同时 legacy 规则仍在丢弃数据包。26.04 上的 Docker 29 可以切换到 nftables 后端，ufw 会遵循当前选中的 alternative，因此混合配置会产生两套无法集中查看的规则集。在检查点使用 sudo update-alternatives --set iptables /usr/sbin/iptables-nft 切换到 iptables-nft，重新加载保存的规则，并确认 sudo nft list ruleset 现在可以显示这些规则。

内核从 5.15 到 6.8，再到 7.0；initramfs 工具也会变化

GA 内核在第一次升级时从 5.15 变为 6.8，在第二次升级时变为 7.0。升级不会删除旧内核，因此 /boot 可能会被占满；VPS 在内核变更后无法启动，是创建快照的原因。VPS 在内核更新后无法启动时的恢复方法介绍控制台和 GRUB 菜单。全新安装的 26.04 使用 dracut 构建 initramfs，而不是 initramfs-tools。升级后的服务器可能仍保留 initramfs-tools；使用 dpkg -l initramfs-tools dracut 检查，并保留当前已安装的工具。

另外两个 26.04 的变更会在第二次升级时生效，开始升级前应先阅读相关内容。sudo 现在是 sudo-rs；如果你有复杂的 sudoers，sudo-rs 会带来哪些变化很重要。coreutils 已改写为 Rust 版本，Rust coreutils 说明介绍了有差异的标志。此外，systemd 259 不再支持 cgroup v1。如果 /proc/cmdline 中包含旧容器配置留下的 systemd.unified_cgroup_hierarchy=0，请在第二次升级前从 GRUB 中删除它，因为在 26.04 上它已经无法实现当初设置它的目的。

从 24.04 升级到 26.04

在系统本机确认升级入口已开放：

sudo do-release-upgrade -c

New release '26.04.1 LTS' available. 表示 meta-release 条目已标记为受支持。Canonical 开放此次升级后，该状态一直如此；此状态于 27 October 2026 检查确认。按照第一跳中的方式准确运行 sudo do-release-upgrade，将第二个 sshd 设置为端口 1022，并使用相同的提示响应。这次第三方标记为 # disabled on upgrade to resolute。如果已完全更新的 24.04 系统仍输出 No new release found，原因就在本地：存在待安装更新、Prompt= 行的值不是 lts，或某个元软件包被锁定。不要使用 do-release-upgrade -d。它读取开发版 meta-release 文件；在 rust-coreutils backports 已合并且正常升级路径已开放的情况下，服务器没有理由使用它。有关该版本更新实际包含的内容，以及如何读取控制升级入口的 meta-release 条目，请参阅26.04.1 版本更新说明。完整流程以及 26.04 专用提示和升级后检查，参见24.04 到 26.04 升级指南。请从创建快照步骤开始执行，因为您已经有检查点快照。

如果某个升级阶段失败

升级器会将日志写入 /var/log/dist-upgrade/。main.log记录升级器自身的决策，term.log记录每一行 dpkg 输出；apt.log则记录依赖解析器的视图。升级阶段中途停止时，通常会让 apt 处于可由 sudo dpkg --configure -a 和 sudo apt -f install 完成修复的状态。如果仍然无法完成，请参阅恢复失败的发行版升级，按救援流程操作；而你在该阶段之前创建的快照是最后的恢复手段。阶段 two 失败后恢复 24.04 快照，除了耗费一些时间外不会丢失任何内容。阶段 one 失败后恢复 22.04 快照，就能回到开始时的状态，并获得一份待修复问题清单，然后再尝试升级。

FAQ

能否直接将 Ubuntu 22.04 升级到 26.04？

不能。do-release-upgrade 每次只能跨一个 LTS 版本，26.04 的发行说明指出，22.04 系统必须先升级到 24.04。上次检查是在 2026 年 10 月 20 日，当时下载的 26.04 升级程序只接受 24.04 LTS 以及之后的中间版本（24.10、25.04 和 25.10）作为起始版本，列表中没有 22.04。从 22.04 开始，唯一受支持的路径是先从 22.04 升级到 24.04，再从 24.04 升级到 26.04。设置 Prompt=normal 不会改变路径：升级程序会跳过 meta-release 文件标记为不受支持的版本，而 22.10、23.04 和 23.10 都属于此类，因此从 22.04 出发时，无论是否设置该选项，程序都只会提供 24.04。

为什么在 24.04 上运行 do-release-upgrade 时显示 “No new release found”？

Canonical 只有在目标版本发布第一个点版本后，且 meta-release-lts 文件将其标记为 Supported: 1 时，才会开放 LTS 到 LTS 的升级。Ubuntu 26.04.1 于 2026 年 8 月 27 日发布。截至 2026 年 10 月 27 日，该条目已显示 Supported: 1，因为 rust-coreutils 回归问题的修复已经回移植，因此完全更新的 24.04 系统应能看到 New release '26.04.1 LTS' available。如果系统没有显示该版本，请先运行 sudo apt update && sudo apt full-upgrade，然后确认 /etc/update-manager/release-upgrades 的内容为 Prompt=lts，而不是 never。

应该原地升级，还是新建 26.04 VPS？

如果系统是单用途服务器，第三方软件源很少，并且每次升级前都能创建快照，可以原地升级。如果服务器之前进行过原地升级、运行控制面板、使用自定义内核，或依赖多个 PPA，建议新建 26.04 VPS 后迁移，因为这些因素都会增加两次升级的工作量。

从 22.04 升级到 26.04 需要多长时间？

对于小型 VPS，应安排两个各 30 到 60 分钟的维护窗口，并预留窗口之间处理检查点的时间。实际耗时主要在检查点阶段，因为需要在此阶段迁移 PostgreSQL、切换 PHP socket、重建 Python virtualenv 并重新启用软件源。两次升级之间间隔数周不会产生影响：24.04 的标准支持期持续到 2029 年。

升级过程中 PPAs 会发生什么变化？

升级程序会注释掉每个非 Ubuntu 软件源，并将每一行标记为 # disabled on upgrade to noble；第二次升级时，它会使用 resolute 再执行一次。PPA 行中包含发行版代号，因此请修改代号后重新启用该软件源，并运行 sudo apt update。如果 apt 输出 does not have a Release file，表示该 PPA 尚未为该发行版提供构建版本；此时可以等待，或寻找其他软件源。