Ubuntu 26.04 LTS 发布了三项更改，这些更改将在升级日破坏现有工作流程。

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 已彻底移除，升级将被阻止

可以把 cgroup 想象成公寓楼的管理。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 则一直同时支持两者。这种情况到此结束。

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

修复方法并不复杂，但需要时间。你需要确认你的 cgroup 版本（使用 `cat /proc/cgroups` 或 `mount | grep cgroup`），更新容器运行时，并针对 cgroup v2 测试每一个容器工作负载。对于单台服务器来说，这需要一下午的时间。对于一组 Kubernetes 节点来说，这需要一次冲刺开发。

Ubuntu 26.04 升级的 cgroup v1 到 v2 迁移决策流程

sudo 现在用 Rust 重写了

sudo 作为同一份 C 代码库已经存在了超过 30 年。你输入 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 改变了这个默认行为。你可以在 sudoers 中使用 `Defaults !pwfeedback` 禁用它，但这会改变行为，让你整个机群中每个终端上的肌肉记忆感到困惑。

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

对于桌面用户来说，这几乎察觉不到。你在输入密码时会看到星号。这就是全部体验。

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

在升级生产环境之前，先在预发环境中进行测试。在一个临时虚拟机上针对 sudo-rs 运行你的 PAM 配置。检查你的合规性工具是否仍然能在 syslog 中看到它所期望的内容。

原版 sudo 仍然可以在软件源中以 `sudo.ws` 的形式获得。但 Canonical 将 Rust 版本设为默认版本，而默认设置很重要。每个新的 Ubuntu 26.04 安装、每个云镜像、每个容器基础镜像都将搭载 sudo-rs。

GNU coreutils 被 Rust 重写版本取代

ls、cp、mv、cat、date、sort。这些命令自 1990 年代初以来就一直是 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`（依赖于语言环境的排序规则）、`date`（格式字符串差异）以及 `cp`（边缘情况的标志行为）。如果你的自动化使用 `awk` 或 `cut` 来解析命令输出，请在升级前针对新的二进制文件进行测试。

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

uutils 项目报告称，在版本 0.7.0 中，与 GNU 测试套件的兼容性达到了 94.59%（在 GNU 于 Coreutils 9.10 中增加了 19 个新测试后，这一数字从 96.28% 下降而来）。这个数字听起来很高，但你要记住有多少脚本每天运行 coreutils 命令数百万次。即使在测试用例中只有 5% 的失败率，分布在一千台服务器上，累积起来也会很快。

APT 3.1 和 GNOME 50

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

APT 3.1 最终确定了 `apt-key` 的移除。可以把 `apt-key` 想象成一个钥匙环，每个钥匙都能打开大楼里的每一扇门。新方法为每个钥匙提供恰好一扇门的访问权限。更安全了，但每把钥匙都必须重新配制。

如果你使用 `apt-key add` 来添加第三方软件源，这些指令在 24.04 中已经不再有效。替代方法（在 sources 文件中使用 `signed-by`）自 Ubuntu 22.04 起就已可用。Canonical 给了四年的过渡期，而 26.04 则继续推进了移除，没有回退路径。

GNOME 50 从 GDM 中移除了 X11 会话。你仍然可以通过 XWayland 运行 X11 应用程序，但登录屏幕不再提供“Ubuntu on Xorg”会话。依赖 X11 回退以获得稳定性的 NVIDIA 专有驱动程序用户，需要在升级前确认他们对 Wayland 的支持情况。

在 4 月 23 日之前要做的事

我经历过足够多的 LTS 升级，知道这种情况会如何发展。团队计划在预发环境中测试。但预发环境与生产环境并不匹配。有人在某个周五运行了 `do-release-upgrade`，因为更新日志看起来没问题。到了周一早上，容器将无法启动。

我亲眼目睹过这个确切的过程三次。升级本身很顺利。周一早上，一个没人测试过的批处理任务静默地失败了。周二，有人开了个工单。

以下是真正有效的步骤：

第一周：审计。在每台 Ubuntu 服务器上运行 `cat /proc/cgroups`。识别使用 cgroup v1 的系统。列出每个使用 `apt-key` 的第三方软件源。检查哪些 shell 脚本解析了 coreutils 的输出。

第二周：解决阻塞项。将 cgroup v1 系统迁移到 v2。用 `signed-by` 替换 `apt-key`。在一个临时虚拟机上使用你的 PAM 配置测试 sudo-rs。

第三周：验证。针对 Ubuntu 26.04 测试版运行你的 CI/CD 流水线。对比每个脚本化命令的 coreutils 输出。如果运行桌面环境，请验证 NVIDIA Wayland 支持。

第四周：升级预发环境。在接触生产环境之前，至少运行一个完整的工作周。

如果你跳过了这些步骤中的任何一步，你将会在生产环境中发现问题。Ubuntu 26.04 是我见过的第一个如果系统未就绪就会拒绝升级的 LTS 版本。老实说，这很好。强制迁移总好过一个损坏的系统在几个月里默默地行为异常，而你还不知道为什么部署一直在失败。

Ubuntu Pro 支持窗口（通过 Legacy 附加组件最长可达 15 年）意味着 26.04 可能会在生产环境中运行到 2041 年。这是一个长期的承诺。在你正式采用之前，请确保你的基础设施确实能与之兼容。

4月23日，三大破坏性变更，一个最终期限，没有回头路。

这三个变化中哪一个对你的基础设施影响最大？欢迎评论区讨论~

作者丨Can Artuc 编译丨dbaplus社群

来源丨网址：https://canartuc.medium.com/ubuntu-26-04-lts-breaks-backward-compatibility-on-purpose-5a221cd94ca4

dbaplus社群欢迎广大技术人员投稿，投稿邮箱：editor@dbaplus.cn