Ubuntu 26.04 LTS, codenamed Resolute Raccoon, introduces foundational changes that may affect servers, containers, and legacy automation. The final removal of cgroup v1 is the clearest risk, while the adoption of sudo-rs and Rust-based replacements for GNU utilities requires administrators to review configurations, audit integrations, and scripts that depend on very specific behavior. However, some of these changes already debuted in Ubuntu 25.10, so they are not all exclusive to this LTS release.

Ubuntu 26.04 LTS in 20 Seconds

Ubuntu 26.04 removes cgroup v1 support and uses cgroup v2 exclusively.
sudo-rs and Rust coreutils were already the defaults in Ubuntu 25.10.
Traditional sudo and GNU utilities remain available as alternatives.
Scripts, old containers, and LDAP or audit integrations require testing.
The desktop now relies on Wayland, without a full Ubuntu on Xorg session.

The upgrade should not be interpreted as Canonical arbitrarily deciding to break existing systems. It reflects a wider move away from outdated technologies, the adoption of memory-safe components, and transitions that had already begun in previous releases. Even so, the impact may be substantial in infrastructure that has been running for years without a detailed review of its dependencies.

Ubuntu 26.04 was released on 23 April 2026 and will receive five years of standard maintenance, until April 2031. Organizations using Ubuntu Pro can extend that period, meaning the technical decisions introduced in this LTS may shape servers and workstations for many years.

cgroup v1 Is Gone and May Block the Upgrade

The most relevant change for system administrators is the removal of cgroup v1, including hybrid configurations that combined both cgroup generations.

Control groups, or cgroups, allow the Linux kernel to organize processes and limit resources such as CPU, memory, and input/output. They are essential to systemd, Docker, Kubernetes, LXC, and many container platforms.

Ubuntu 26.04 includes systemd 259. This release carries forward the decision introduced in systemd 258 to remove the legacy and hybrid hierarchies, meaning the system now uses cgroup v2 only. Ubuntu documentation also warns that the upgrader will inspect the configuration and refuse to continue from Ubuntu 24.04 if the system still depends on cgroup v1.

This pre-upgrade check prevents a server from completing the migration only to find that its workloads no longer start correctly. The downside is that the migration must be resolved before the distribution upgrade begins.

The systems most at risk are those using:

old versions of Docker or containerd;
Kubernetes clusters configured before widespread cgroup v2 adoption;
LXC containers with explicit cgroup v1 mounts;
kernel parameters that force the legacy hierarchy;
custom software that directly accesses paths under /sys/fs/cgroup.

A more reliable way to check the active version is to inspect the mounted filesystem type:

stat -fc %T /sys/fs/cgroup

If the result is cgroup2fs, the system is using cgroup v2. It can also be checked with:

mount | grep cgroup

Looking only at /proc/cgroups is not enough to determine which hierarchy is active because that file shows the controllers supported by the kernel, not necessarily the mode in use.

The migration may be straightforward on a single updated server, but it requires more work in a cluster. Changing the boot configuration is not enough. Administrators also need to validate the container runtime, kubelet, resource policies, monitoring systems, and any agent that reads metrics from the old hierarchy.

sudo-rs Replaces Traditional sudo, but There Is a Way Back

Ubuntu now uses sudo-rs as the default provider for the sudo command. It is a Rust rewrite developed by the Trifecta Tech Foundation with the aim of reducing exposure to memory-safety vulnerabilities.

This is not a feature introduced exclusively in Ubuntu 26.04. Canonical already made sudo-rs the default in Ubuntu 25.10. Resolute Raccoon includes version 0.2.13 with additional fixes.

For most users, the change should be almost invisible. The command keeps the same name, works with /etc/sudoers, and supports common features such as NOPASSWD, sudoedit, AppArmor profiles, and PAM authentication.

There is one visible difference: pwfeedback is enabled by default, so users see asterisks while typing their password. It can be disabled with:

Defaults !pwfeedback

The more important differences appear in enterprise environments. The project acknowledges that it still supports fewer features than the original sudo. It does not include, among other capabilities, sudoers.ldap, some plugins, INTERCEPT, the logfile option, or every form of timestamp_type. It also enforces some specific behavior related to PAM and environment variables.

This may affect organizations that rely on:

authorization rules stored in LDAP;
custom sudo plugins;
advanced session recording or analysis;
tools expecting specific log formats;
policies based on less common sudoers options;
scripts using arguments that are not yet implemented.

Canonical has not completely removed the historical implementation. The original sudo developed by Todd C. Miller remains available through binaries ending in .ws, and administrators can switch providers with:

sudo update-alternatives --config sudo

There is therefore still an alternative. The important point is that fresh installations, cloud images, and upgraded systems will use sudo-rs unless the administrator changes the default.

Rust Coreutils May Expose Hidden Assumptions in Scripts

Ubuntu also uses uutils coreutils by default, a Rust reimplementation of familiar commands such as ls, cp, mv, cat, date, sort, head, and tail.

This change also began in Ubuntu 25.10. Rust utilities became the default while Canonical kept GNU versions available in parallel because compatibility was not yet complete.

For normal interactive use, the differences are often minor. The greatest risk appears in automation that treats command output as a fixed data interface rather than as human-readable text.

A script may fail if it depends on:

exact spaces or columns in ls output;
specific date formats;
locale-dependent sorting behavior;
exact error messages;
edge-case exit codes;
uncommon options in cp, stat, sort, or tail;
undocumented GNU behavior.

The long-standing recommendation not to parse ls output becomes even more relevant here. When working with files, it is better to use find, shell globbing, null-delimited output, or language-native APIs.

Passing most of the GNU compatibility test suite does not guarantee identical behavior in every existing script. Test suites include thousands of cases, and differences often appear precisely in advanced options, locale handling, errors, and unusual combinations.

Canonical keeps GNU coreutils available as an alternative. That reduces the immediate risk but does not remove the need for testing because the default binaries are the Rust implementations.

A practical method is to run the same test suite on Ubuntu 24.04 and Ubuntu 26.04, save the output, and compare the results. Tests should include successful execution, errors, return codes, and behavior with unusual file names.

APT, Xorg, and SysV Services Also Need Attention

The original text also attributes several changes to Ubuntu 26.04 that, in some cases, happened earlier.

The removal of apt-key has been in progress for years. Modern repository configurations should associate each repository with a dedicated key through the Signed-By option, preferably in Deb822 files under /etc/apt/sources.list.d/.

For example:

Types: deb
URIs: https://packages.example.com/ubuntu
Suites: resolute
Components: main
Signed-By: /etc/apt/keyrings/example.gpgCode language: HTTP (http)

Binding each repository to its own key limits the scope of trust. The old global keyring allowed a key added for one vendor to validate packages from other configured repositories.

On the desktop, Ubuntu had already removed the full Xorg session in version 25.10. X11 applications can still run through XWayland, but users no longer see the traditional “Ubuntu on Xorg” option at login.

Ubuntu 26.04 also includes systemd 259 and is expected to be the final release retaining compatibility with System V init scripts. That does not mean they stop working immediately in Resolute Raccoon, but it does make migration to native systemd units necessary before the next LTS.

For systems with NVIDIA GPUs, the removal of the Xorg session does not automatically make Wayland unusable. Proprietary drivers have improved across recent releases, although workstations with specialized graphics software, remote desktops, or complex multi-monitor setups should be tested before migration.

What to Review Before Upgrading from Ubuntu 24.04

An LTS upgrade should not begin directly in production. The first step is to identify which components depend on old behavior.

On servers and cloud platforms, administrators should review:

stat -fc %T /sys/fs/cgroup
systemd --version
docker info | grep -i cgroup
grep -R "apt-key" /etc /usr/local /opt 2>/dev/null
grep -R "sudoers.ldap\|INTERCEPT\|logfile" /etc/sudoers /etc/sudoers.d 2>/dev/nullCode language: JavaScript (javascript)

It is also useful to locate scripts that parse command output:

grep -R -E "ls .*\|.*(awk|cut|sed)|date .*\+|sort " \
    /usr/local/bin /opt /etc/cron* 2>/dev/nullCode language: JavaScript (javascript)

A match does not automatically mean the code is incompatible. It creates an initial list of elements that require testing.

A controlled process should include four phases:

Inventory: locate cgroup v1 systems, SysV scripts, old repositories, sudo plugins, and automation sensitive to coreutils output.
Pre-migration: move containers to cgroup v2, replace apt-key, and convert legacy services.
Testing: run applications, pipelines, backups, monitoring, and scheduled tasks on Ubuntu 26.04.
Gradual rollout: upgrade non-critical systems first and allow enough time to detect errors.

A rollback procedure should also be prepared. During a distribution upgrade, restoring a snapshot or rebuilding the server is usually safer than trying to downgrade individual packages.

Ubuntu 26.04 does not destroy all backward compatibility or remove every route back. Traditional sudo and GNU coreutils remain available, and some transitions began in 25.10. However, the removal of cgroup v1 does establish a clear boundary: legacy configurations must migrate before moving to the new LTS.

Frequently Asked Questions

Does Ubuntu 26.04 block the upgrade if cgroup v1 is in use?

Yes. Ubuntu documentation states that the upgrader checks the cgroup hierarchy and blocks the process when it detects a configuration that is incompatible with cgroup v2.

Can the original sudo still be used?

Yes. Ubuntu keeps the traditional implementation available as sudo.ws and allows administrators to select the provider through update-alternatives.