Ubuntu 服务器选 LTS 还是临时版本？

Ubuntu LTS 与临时版本：简要结论

在服务器上选择 Ubuntu LTS 还是临时版本，关键取决于一个数字：该版本会持续获得多长时间的安全更新。LTS 提供 5 年的标准安全维护。临时版本提供 9 个月的安全维护，之后更新停止，因此您必须升级或重建系统。凡是依赖该服务器的其他服务，都应运行 LTS。只有在无需征求他人同意即可重建系统的环境中，才应运行临时版本。

LTS 表示长期支持。Canonical 每两年发布一个 LTS，时间为偶数年的 4 月；两次 LTS 之间每 6 个月发布一个临时版本。26.04 LTS 于 23 April 2026 发布，其标准安全维护将持续到 2031 年。26.10 计划于 15 October 2026 发布，它是临时版本，因此其支持周期将在 July 2027 结束。

每个 Ubuntu 版本的支持期限

[
  {
    "label": "LTS, standard support",
    "support_months": 60,
    "upgrades_over_5_years": 1
  },
  {
    "label": "LTS with Ubuntu Pro",
    "support_months": 120,
    "upgrades_over_5_years": 0
  },
  {
    "label": "Interim release",
    "support_months": 9,
    "upgrades_over_5_years": 10
  }
]

以上是 Canonical 截至 2026 年 8 月公布的政策数据，不是测试服务器上的测量结果。LTS 版本提供 60 个月的标准安全维护期，因此 5 年内需要进行 1 次计划内版本升级。中间版本提供 9 个月的支持期。在同样的 5 年内持续使用中间版本，需要进行 10 次版本升级，因为不能跳过版本，而 5 年内会发布 10 个中间版本。

Ubuntu Pro 订阅会将 LTS 的支持期限延长至 120 个月，即 10 年，并将覆盖范围从 main 组件扩展到整个软件仓库。截至 2026 年 8 月，个人用户可在最多 5 台计算机上免费使用 Pro，这足以覆盖大多数小型 VPS 集群。中间版本没有等效方案。支持期限就是 9 个月，任何订阅都无法延长该期限。

真实服务器在 9 个月内的成本

以 26.10 为例。该版本于 15 October 2026 发布，安全维护于 July 2027 结束。这与 25.10 于 July 2026 结束维护的 9 个月模式相同。如果按日历计算，看起来像是每 3 个季度才需要进行一次维护。但这种计算方式是错误的，而且会导致更高的成本。

版本升级会原地替换操作系统。do-release-upgrade 会重写 apt 源，禁用第三方软件仓库，修改几乎所有已安装软件包的版本，暂停并询问您编辑过的配置文件如何处理，最后重启系统。因此，升级需要安排专门的维护窗口，不能作为后台任务运行。

通过 ssh 执行升级时，升级工具会防止您的连接意外中断。它会启动自己的 screen 会话，并打开第 2 个 sshd，还会先告知您：

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 端口，则不存在这个备用连接。此时连接中断会留下不完整的软件包升级状态。在任何服务器上，您自己在 tmux 或 screen 中运行升级，也能获得同样的保护。

配置文件提示会把 15 分钟的升级变成 1 小时：

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 ?

保留您的文件，意味着您会错过新默认配置中的变更。使用维护者提供的文件，意味着您的加固配置会消失，直到您重新应用。不了解该版本具体发生了哪些变化时，这两个选择都不安全。因此，阅读发行说明是维护窗口的一部分，而不是可选的准备工作。

然后还要乘以服务器数量。在 5 年内，1 台使用中间版本轨道的 VPS 需要进行 10 次升级。5 台 VPS 就是 50 次，除非每台服务器都是一次性实例，并且始终从镜像重新构建。5 台使用 LTS 轨道的服务器在同一时期只需升级 5 次，而且您可以自行选择每次升级的月份。

为什么不能跳过 Ubuntu 版本

升级路径是固定的。临时版本只能升级到下一个版本，无论下一个版本是什么。LTS 版本可以直接升级到下一个 LTS 版本，也可以在明确要求时升级到下一个临时版本。任何升级都不能一次跨过两个版本。从 26.10 升级到 28.04 LTS，必须经过 27.04 和 27.10，或者重新安装系统。

了解其工作机制很重要，因为这说明该规则不会变通。do-release-upgrade 从 changelogs.ubuntu.com 获取 meta-release 文件，然后下载针对某个特定版本迁移构建的升级工具。Canonical 一次只构建和测试一条迁移路径，因此跳过版本的升级既没有对应工具，也没有经过测试。升级程序拒绝执行并不是出于谨慎，而是因为没有可供它执行的升级路径。

系统提供哪个版本，取决于配置中的一行：

grep -i prompt /etc/update-manager/release-upgrades
sudo do-release-upgrade -c

Prompt=lts 只提供下一个 LTS 版本。Prompt=normal 提供下一个版本，无论它是否为 LTS。Prompt=never 不提供任何版本。这样可以防止同事好意启动您没有计划的升级。在非 LTS 版本上，lts 的行为与 normal 完全相同，因为无论采用哪种设置，26.10 之后的下一个版本都是 27.04。检查会输出 Checking for a new Ubuntu release，然后输出 New release ... available. 行或 No new release found.

还有一条版本发布时间规则容易被忽略。新的 LTS 发布当天不会立即提供 LTS 到 LTS 的升级。该升级会在第一个点版本发布后开放，而 26.04.1 计划于 27 August 2026 发布。某台配置了 Prompt=lts 的 24.04 系统在 2026 年夏季通过 No new release found. 返回的结果并不表示系统故障，而是系统遵循了该策略。升级路径开放后，应将24.04 到 26.04 LTS 的升级作为计划和演练内容。

何时应选择中期版本

以下4种情况下，中期版本确实更合适：

• 您现在就需要这台机器使用 LTS 软件包仓库中没有提供的 kernel 或 userspace 版本。
• 这台机器是构建主机、CI runner 或测试机，您会通过镜像重新构建它，因此升级只是创建新实例，而不是安排维护窗口。
• 某项硬件或 hypervisor 功能在 LTS 冻结后才加入，并且没有可用的 backport。
• 您需要确认下一个 LTS 将包含哪些内容。28.04 基于 26.10、27.04 和 27.10 组装而成。在备用 VPS 上发现 breaking change，比在关键服务器上发现的成本更低。

大多数选择中期版本的人，只是需要某个更新的软件包，而不是更新的发行版。还有两种成本更低的方案。硬件启用栈会将后续版本中的 kernel 引入 LTS：在 24.04 中为 sudo apt install linux-generic-hwe-24.04，并从第2个 point release 开始，在每次 point release 时继续更新。对于单个应用，使用 container image 或厂商自己的 repository，只需更新一个组件，而不必更新整个操作系统。

不应选择中期版本的情况

• 任何有付费用户或采用值班轮换的系统。您需要每年接受两次强制升级，换来的可能只是一些您永远不会使用的软件包版本。
• 任何由 unattended-upgrades 自动执行安全更新 的服务器。该自动化机制的安全性取决于它所使用的 security pocket。
• 需要手动升级的服务器集群，因为实际成本是每台服务器都需要经历一次维护窗口。
• 任何安装后长达一年无人查看的系统。您遗忘的中期版本，9 个月后就可能变成未打补丁的公网服务器。

最后一种故障不会立即显现，因此更加危险。版本达到生命周期结束后，其软件包会移至 old-releases.ubuntu.com，因此 sudo apt update 针对 archive.ubuntu.com 执行时会因 404 错误而失败。磁盘上的软件包列表会逐渐过期。unattended-upgrades 仍会按计划运行，并持续将类似下面的内容写入 /var/log/unattended-upgrades/unattended-upgrades.log：

No packages found that can be upgraded unattended and no pending auto-removals

在已完成全部更新的服务器上，以及版本已在 4 个月前结束生命周期的服务器上，这一行看起来完全相同。除非有人查看 apt 错误或跟踪版本生命周期结束日期，否则系统中没有任何信息能告诉您当前面对的是哪一种情况。

首先进入中间版本轨道的变更类型

2026 年 3 月，一名 Canonical 工程师在 Ubuntu Discourse 上提议，在 26.10 中移除为 secure boot 提供的已签名 GRUB bootloader。该提案将移除 btrfs、hfsplus、xfs 和 zfs 的文件系统驱动，JPEG 和 PNG 图像解析器，Apple 分区表，LVM 上的 /boot，除 RAID 1 以外的软件 RAID，以及经过 LUKS 加密的 /boot。给出的原因是，bootloader 中的解析器反复成为安全漏洞的来源，而存储和加密逻辑应属于 initramfs，也就是内核在挂载真正的 root 文件系统前挂载的小型初始 RAM 文件系统。截至 2026 年 8 月，这仍是正在讨论的提案，并不是已经发布的变更。

对于大多数 VPS 实例，这不会带来任何变化，因为它们通常不使用 secure boot 启动，而是从 GPT 分区表上的普通 ext4 /boot 启动。请检查自己的配置，不要想当然。如果 root 位于 ZFS 上，或者 /boot 位于 btrfs 上或 LUKS 内部，这正是会首先在中间版本轨道中影响你的变更类型；该讨论串给受影响用户的建议也是继续使用 LTS。这条建议用一句话概括了全部原因：中间版本用于尝试变更；LTS 则是在经过两个中间版本、确认这些变更会破坏什么之后再接收它们。

每个中间版本都会以更小的形式重复这一模式。数据库、语言运行时和 init 配置的默认版本都会前进，因此原本可用的配置文件可能停止工作。推进默认版本正是中间版本存在的目的，所以在每次升级这 10 个版本前阅读发布说明，是你需要承担的成本。

构建服务器时选择发布轨道

请在安装时选择发布轨道。之后更改通常意味着重新安装，或连续进行多次升级。在新服务器上，运行以下四条命令即可确认当前状态：

lsb_release -a
grep -i prompt /etc/update-manager/release-upgrades
sudo do-release-upgrade -c
pro security-status

lsb_release -a 应显示您计划安装的版本；如果是 LTS 版本，描述行应以 LTS 结尾。Prompt 行应与您选择的发布轨道一致，而不应取决于服务商镜像实际附带的版本。当前 LTS 上，do-release-upgrade -c 应返回 No new release found.。如果它提供的是 interim 版本，则 Prompt 已设置为 normal，应有人确认这是否是有意为之。pro security-status 会报告已安装软件包分别由哪些更新流覆盖，并明确说明服务器未关联订阅。

然后将生命周期结束日期写入您之后还能再次看到的位置，与该服务器的其他构建记录放在一起。这项工作应与 新 VPS 上线后的前十分钟中的其他任务一起完成，因为只存在于某个人记忆中的支持日期，最容易在无人注意时到期。如果您试图彻底摆脱半年一次的版本更替，决定将整组服务器部署到哪种系统之前，值得花一小时阅读 FreeBSD 发布模型与 Linux 的比较。

FAQ

我应该在生产服务器上运行 Ubuntu 的 interim release 吗？

几乎所有情况下都不应该。interim release 在发布 9 个月后停止接收安全更新，因此让生产环境使用这条发布轨道，意味着大约每年必须升级两次，而且长期如此。确实存在例外，例如 CI runner 和构建主机，因为这类机器本来就会从镜像重建，升级相当于创建新实例，而不是安排维护窗口。如果服务器承载真实用户的业务，请安装 LTS，把节省下来的维护窗口用于其他工作。

Ubuntu 的 interim release 支持多长时间？

9 个月。26.10 于 15 October 2026 发布，其安全维护将在 July 2027 结束；25.10 也是同样的周期，于 July 2026 结束。每个 interim release 都遵循这一周期：在 April 或 October 发布，9 个月后结束支持。LTS 提供 5 年标准安全维护；使用 Ubuntu Pro 后可延长到 10 年。截至 August 2026，个人用户最多可在 5 台机器上免费使用 Ubuntu Pro。

升级时可以跳过 Ubuntu 的版本吗？

不可以。do-release-upgrade 一次只能前进一个版本：interim release 升级到下一个版本，LTS 则可以直接升级到下一个 LTS。从 26.10 升级到 28.04 LTS，需要先依次通过 27.04 和 27.10 完成升级，或者重新安装系统。Canonical 会逐一构建和测试每次版本转换，升级程序也会下载针对该次转换的工具。因此，两步跨版本没有对应的升级工具，系统不会提供这种升级路径。

Ubuntu 版本到达生命周期结束后会发生什么？

该版本的软件包会迁移到 old-releases.ubuntu.com，因此 sudo apt update 对 archive.ubuntu.com 的请求会因 404 错误开始失败，并且该版本不会再发布任何新的安全更新。机器不会对此发出提示。服务器会继续运行并继续提供网络流量服务，但其中新发现的每个漏洞都会持续处于未修复状态。恢复方式是顶着时间压力执行版本升级，或者重建系统。因此应关注日期，而不是等问题出现后再处理。

LTS 内核是否太旧，无法支持新硬件？

通常不是，因为 LTS 不会在 5 年内始终使用最初的内核。硬件启用堆栈 HWE 会在点版本中将后续版本的内核引入 LTS，服务器安装也可以通过类似 linux-generic-hwe-24.04 的软件包选择启用该功能。在认定内核是阻碍因素前，请使用 uname -r 检查当前运行的内核。如果缺少的是 userspace 版本而不是内核，使用容器或厂商软件源通常比将整台机器迁移到 interim release 更改动更小。