3 项升级被阻止。2 个系统工具被重写。1 个完全不在乎你旧有配置的版本。

Ubuntu 26.04 LTS (Resolute Raccoon) 可能是有史以来变化最大的 Ubuntu LTS。但在深入研究 beta 版发行说明并测试迁移场景后，有一点变得很清楚：Canonical 不只是在发布新功能。他们是在有意打破旧功能。

Canonical 跳过了温和的弃用周期。现在就迁移，否则升级甚至无法启动。

Ubuntu 26.04 带来了三项没有回退方案的变更。如果你的基础设施依赖 cgroup v1、旧的 sudo 行为，或对 GNU coreutils 输出进行解析，那么 4 月 23 日就是最后期限，而不是一次普通功能发布。升级工具会强制执行。

cgroup v1 已经消失。升级会被阻止。

可以把 cgroups 想象成公寓楼管理。cgroup v1 给每位住户（进程）分别为每项公用服务设置一个信箱：电、水、燃气。cgroup v2 则给每位住户一个统一信箱，所有内容都放进去。对楼管来说更简单，但每位住户都必须重新登记。

systemd 258 移除了所有 cgroup v1 支持，而 Ubuntu 26.04 搭载的是 systemd 259，延续了这一移除。这不是弃用警告，也不是“方便时请迁移”的提示。从 24.04 升级到 26.04 的流程会检查你的 cgroup 配置，如果你仍在使用 v1，就会阻止升级。

内核多年来一直维持双 cgroup 支持。Red Hat 早在 RHEL 9（2022）中就不再默认使用 cgroup v1。Fedora 也随后跟进。Ubuntu 则一直同时支持两者。现在到此为止了。

受影响最严重的人群：任何运行旧版容器运行时的人。Docker 20.10 之前的版本默认使用 cgroup v1。2022 年之前配置的 Kubernetes 集群，通常在 kubelet 配置中硬编码了 cgroup v1。带有显式 cgroup v1 挂载的 LXC/LXD 容器将无法启动。

修复并不复杂，但需要时间。你需要验证自己的 cgroup 版本（cat /proc/cgroups 或 mount | grep cgroup），更新容器运行时，并针对 cgroup v2 测试每一个容器工作负载。对于单台服务器来说，这需要一个下午。对于一组 Kubernetes 节点来说，这需要一个 sprint。

如果你管理带有容器的 Ubuntu 服务器，请为这篇文章点赞或分享。你的团队需要在 4 月 23 日之前看到这些内容。

sudo 现在用 Rust 编写

sudo 30 多年来一直是同一个 C 代码库。你输入 sudo，就能获得 root 权限。它一直能用。没人会多想。

Ubuntu 26.04 将默认的 sudo 提供者替换为 sudo-rs，这是 Trifecta Tech Foundation 用 Rust 从零重写的版本。命令相同。sudoers 文件格式相同。但底层二进制文件不同。

可以把它想象成更换你家前门的锁。钥匙仍然能用。门仍然能打开。但里面的锁芯机制已经完全换新；如果你的旧钥匙有一点弯齿，而旧锁能容忍，新锁可能就不行。

兼容性总体上还不错。 sudo-rs 解析方式相同 /etc/sudoers 语法。它遵循相同的环境变量。它支持相同的 NOPASSWD 指令。Trifecta Tech 已经用原版 sudo 测试套件对其进行了两年的测试。

显而易见的区别是：密码反馈现在默认启用。当你在 sudo 提示符下输入密码时，会看到星号。原版 sudo 什么都不显示（这是一个有意为之的安全选择，用来防止他人从肩后窥视）。 sudo-rs 改变了这个默认设置。你可以通过 Defaults !pwfeedback 在 sudoers 中将其禁用，但这是一次行为变化，会让你整个终端环境中的肌肉记忆都感到困惑。

更深层的担忧在于边缘情况。 sudo-rs 不支持 sudo 的插件 API、基于 LDAP 的 sudoers、I/O 日志记录或 sendmail 集成。解析 sudo syslog 输出的审计日志集成可能会看到不同的消息格式。检查 sudo 二进制签名的安全工具会将新的二进制文件标记为未知。

对桌面用户来说，这几乎察觉不到。你输入密码时会看到星号。整个体验也就如此。

对于运行 LDAP 支持的身份验证或自定义审计流水线的企业来说，情况就不同了。如果你的 sudoers 文件使用了 sudo-rs 不支持的功能（LDAP 后端、I/O 日志记录、自定义插件），该二进制文件会告诉你。它会打印清晰的错误，而不是悄悄出现异常行为。但这个错误会让任何调用 sudo 的自动化流程停止；而在周六午夜，“清晰的错误消息”并不能带来多少安慰。

在升级生产环境之前，先在预发布环境中测试。将你的 PAM 配置拿去针对 sudo-rs 在一台可随时丢弃的 VM 上运行。检查你的合规工具是否仍能在 syslog 中看到它期望的内容。

原版 sudo 仍可作为 sudo.ws 在软件仓库中获得。但 Canonical 已将 Rust 版本设为默认，而默认值很重要。每一次新的 Ubuntu 26.04 安装、每一个云镜像、每一个容器基础镜像都会附带 sudo-rs.

GNU coreutils 被 Rust 重写版本取代

ls, cp, mv, cat, date, sort。这些命令自 20 世纪 90 年代初以来一直存在于 GNU coreutils 中。它们是 Linux 命令行的动词。每个 shell 脚本、每个 cron 任务、每条 CI/CD 流水线都默认假设 GNU 行为。

Ubuntu 26.04 将它们替换为 uutils/coreutils 0.7.0，这是 GNU coreutils 的 Rust 重新实现。就像把你家里的每一个电灯开关都换成了新品牌。它们仍然是上下拨动，灯也仍然会亮。但手感略有不同，而且你的一些调光器可能无法工作。

这并不是理论风险。2025 年 10 月，Ubuntu 25.10 中的 Rust date 命令发布时不支持 -r 标志，导致自动更新检查器失效。这个 unattended-upgrades 工具使用 date -r 来检查上次运行更新的时间，但 Rust 版本悄悄忽略了这个标志，反而返回了当前时间。Canonical 在几周内修复了它，但这起事件恰好证明了系统管理员最担心的一点：GNU 兼容并不等于与 GNU 完全一致。

最可能引发问题的命令： ls （在脚本中解析输出）、 sort （依赖 locale 的排序）、 date （格式字符串差异），以及 cp （边缘情况下的标志行为）。如果你的自动化流程会用 awk 或 cut解析命令输出，请在升级前先用新的二进制文件进行测试。

GNU coreutils 仍然可以从软件仓库安装。你也可以切换回去。但默认的系统路径会指向 Rust 版本，任何作为 systemd 服务运行的程序，或在最小化容器中运行的程序，都会使用新的二进制文件，除非你显式重新配置。

uutils 项目报告称，版本 0.7.0 与 GNU 测试套件的兼容率为 94.59%（在 GNU 于 Coreutils 9.10 中新增 19 个测试后，从 96.28% 下降）。这个数字听起来很高，直到你想到每天有多少脚本会运行 coreutils 命令数百万次。即便测试用例中只有 5% 的失败率，分散到上千台服务器上，也会很快累积成大问题。

你的团队是否已经在测试中遇到 Rust coreutils 的兼容性问题？欢迎留言说说哪个命令最先出问题。

APT 3.1 和 GNOME 50

cgroup v1、sudo-rs 和 coreutils 是最可能破坏现有系统的三项变化。但它们并不是 26.04 中仅有的兼容性破坏。

APT 3.1 最终完成了对 apt-key的移除。可以把它想象成一个钥匙圈，每把钥匙都能打开楼里的每一扇门。新的做法让每把钥匙只能打开一扇门。更安全，但每把钥匙都必须重新配制。

如果你正在使用 apt-key add添加第三方软件仓库，那么这些说明在 24.04 中已经不再适用。替代方案（signed-by 写在 sources 文件中）从 Ubuntu 22.04 起就已经可用。Canonical 给了四年的过渡时间，而 26.04 会继续推进这项移除，并且没有回退路径。

GNOME 50 从 GDM 中移除了 X11 会话。你仍然可以通过 XWayland 运行 X11 应用程序，但登录界面不再提供 “Ubuntu on Xorg” 会话。依赖 X11 fallback 来保证稳定性的 NVIDIA proprietary driver 用户，需要在升级前确认自己的 Wayland 支持情况。

4 月 23 日之前要做什么

我经历过足够多次 LTS 升级，知道事情会怎么发展。团队计划在 staging 中测试。staging 环境和生产环境并不一致。有人会在周五运行 do-release-upgrade ，因为 changelog 看起来没问题。到了周一早上，容器就启动不了了。

我已经三次见过完全相同的流程。升级本身没问题。周一早上，一个没人测试过的批处理任务悄无声息地失败。周二，有人提交了一个 ticket。

真正有效的流程是这样的：

第 1 周：审计。在每台 Ubuntu 服务器上运行 cat /proc/cgroups 。识别 cgroup v1 系统。列出所有使用 apt-key的第三方 repo。检查哪些 shell 脚本会解析 coreutils 输出。

第 2 周：修复阻塞项。将 cgroup v1 系统迁移到 v2。把 apt-key 替换为 signed-by。在一次性 VM 上用你的 PAM 配置测试 sudo-rs。

第 3 周：验证。让你的 CI/CD pipeline 基于 Ubuntu 26.04 beta 运行。对每个脚本化命令比较 coreutils 输出。如果运行桌面环境，验证 NVIDIA Wayland 支持。

第 4 周：升级 staging。在动生产环境之前，至少运行一个完整工作周。

如果跳过这些步骤中的任何一步，你就会在生产环境中发现问题。Ubuntu 26.04 是我见过的第一个会在系统未准备好时拒绝升级的 LTS 版本。说实话，这很好。强制迁移总比系统坏了却默默异常运行几个月、让你一直困惑为什么部署失败要好。

Ubuntu Pro 的支持窗口（加上 Legacy 附加服务最长可达 15 年）意味着 26.04 可能会在生产环境中运行到 2041 年。这是一项很长的承诺。在你决定采用它之前，先确保你的基础设施确实能与它正常协作。

三个破坏性变更。一个截止日期。没有退路。4 月 23 日不会推迟。

如果这篇拆解帮你避免了一次生产事故，欢迎点赞并分享给你的团队。也欢迎在评论区告诉我：这三个变化中，哪一个对你的基础设施冲击最大？