Ubuntu 26.04 LTS「Resolute Raccoon」在 2026 年 4 月 23 日就发布了，但如果你的服务器跑着 24.04 LTS，这四个月里 do-release-upgrade 一直告诉你「没有可用的新版本」。原因不是 bug：Canonical 不在发布当天开放 LTS 到 LTS 的升级通道，而是等到第一个点版本。按官方发布计划，那个点版本 26.04.1 定在 2026 年 8 月 27 日。

为什么要等 .1

这四个月是留给升级路径本身的。桌面和服务器用户在 26.04 首发后遇到的升级阻断问题（软件包依赖打架、配置文件迁移出错、驱动回归）会被逐一修掉，并汇总进 26.04.1 的安装介质与升级器。等 .1 不是保守，而是这条路径被真正测过的第一天。

时间账也值得算清楚：24.04 LTS 的标准安全维护到 2029 年 5 月结束，并不紧迫；26.04 LTS 的标准维护到 2031 年 5 月，扩展安全维护（ESM）到 2036 年 5 月。如果你还停在 22.04，情况相反——它的标准支持 2027 年 4 月就到期，而且不能直接跳到 26.04，必须先升到 24.04 再升 26.04，中间要留出两次升级的时间。

VPS 上升级的五个注意点

  • 先做可回滚的快照：升级过程一旦在半路失败，最快的恢复方式是回滚整机，而不是手工修包。没有快照能力就先做一次完整备份并验证能还原——没验证过的备份不算备份。
  • SSH 升级要留后路：do-release-upgrade 会在 1022 端口另开一个 sshd 作为主连接断掉时的备用入口。防火墙和云安全组要提前放行这个端口，否则一旦断线你就进不去了。同时务必在 tmux 或 screen 里跑，网络抖一下不至于让升级进程被杀。
  • 先处理第三方源：升级器会禁用大部分 PPA 和第三方 apt 源，但自己加的 Docker、Node、PHP、数据库仓库最好提前手动确认它们已经有对应 26.04 的分支，否则升完会有一批包卡在旧版本。
  • 提前查主版本跃迁：跨两个 LTS 意味着 PHP、MySQL/MariaDB、Python、Node 都可能跨大版本。先在一台按小时计费的临时实例上把同样的栈升一遍，把报错清单摸清楚，再动生产机。
  • 别在流量高峰做：配置文件冲突提示（保留旧版还是用维护者版本）需要人工判断，nginx、sshd、postfix 的配置尤其要看清楚。升级完成后重启并逐个验证服务，别只看「机器起来了」。

还有个 -d，但别在生产上用

管理员可以用 do-release-upgrade -d 强行提前升级到尚未开放的版本。这是给测试用的路径，Canonical 不推荐用于生产系统；既然 8 月 27 日之后正式通道就开了，也没必要冒这个险。

把升级当成常规演练

LTS 之间的升级两年才做一次，正因为稀少，才更容易在第一次做的时候踩坑。合理的做法是先在一台便宜的小实例上完整走一遍：装同样的栈、跑同样的升级命令、记录每一处需要人工决策的地方，然后再对生产机执行。SharkCloud 在日本、新加坡、香港、美国均有节点，开一台临时实例做升级演练的成本，远低于生产机在升级中途卡住的代价。