Ubuntu 26.04 will block upgrades on Thursday if containers still use cgroup v1

At a glance:

• Ubuntu 26.04 LTS refuses to upgrade systems that still run containers on cgroup v1.
• Docker versions earlier than 20.10, podman, and cri‑o are among the runtimes that need migration to cgroup v2.
• The cut‑over happens on April 23, 2026; there is no gradual wind‑down, so admins must act now.

What the upgrade change means

Ubuntu 26.04 LTS is scheduled for release on April 23, 2026. While most users will see a routine point‑release, Canonical has introduced a hard stop for any host that still relies on the legacy cgroup v1 hierarchy for container workloads. The kernel will abort the upgrade process and leave the system on the previous LTS version until the administrator migrates every container runtime to cgroup v2. This is a departure from the gradual deprecation model used in previous releases, where older subsystems were quietly phased out over several months.

The decision mirrors moves made earlier by Red Hat and Fedora, which dropped cgroup v1 support a few years ago. Canonical’s rationale is to streamline the kernel and reduce maintenance overhead, but the abrupt enforcement means that any production environment still using older container stacks will face an unexpected roadblock on Thursday.

Which runtimes are affected

The release notes list the following container runtimes that are known to depend on cgroup v1 when running older versions:

• Docker < 20.10 (any version prior to 20.10)
• Podman < 3.0
• cri‑o < 1.22
• Any custom OCI runtime that has not been updated to use the unified cgroup hierarchy

If your environment runs any of the above versions, you will need to upgrade the runtime itself or reconfigure it to use the cgroup v2 controller before attempting the Ubuntu upgrade.

How to check your current cgroup version

1. Open a terminal on the host you plan to upgrade.
2. Run stat -fc %T /sys/fs/cgroup.
3. If the output is cgroup2fs, the host is already using cgroup v2. If it returns tmpfs, you are still on cgroup v1.
4. For container‑specific checks, inspect the runtime configuration. For Docker, docker info | grep Cgroup will show the active version.
5. Document any containers that still report cgroup v1 and plan their migration.

Migration steps for a smooth upgrade

• Upgrade the container runtime: Pull the latest Docker (≥ 20.10), Podman (≥ 3.0), or cri‑o (≥ 1.22) packages from the official Ubuntu repositories.
• Enable cgroup v2: Add systemd.unified_cgroup_hierarchy=1 to the kernel command line in /etc/default/grub and run sudo update-grub.
• Reboot the host to apply the new kernel parameters.
• Verify the switch using the stat command above; ensure the output now reads cgroup2fs.
• Test container workloads: Start a few containers and confirm they operate without errors. Look for warnings about missing cgroup controllers.
• Run the upgrade: Execute sudo do-release-upgrade -d after confirming all containers are on cgroup v2.

Skipping any of these steps will cause the upgrade to abort, leaving the system on Ubuntu 24.04 LTS and potentially exposing it to security patches that only arrive for the newer release.

Why there is no gradual wind‑down

Canonical’s engineering team explains that maintaining dual‑stack support for both cgroup versions adds complexity to the kernel and the init system. By enforcing an immediate cut‑over, they can focus development resources on the newer hierarchy, which offers better resource isolation, unified accounting, and improved performance for modern workloads. The trade‑off is a tighter upgrade window for administrators, but the long‑term benefit is a cleaner, more maintainable OS stack.

What to watch after the upgrade

Even after a successful migration, keep an eye on the following:

• Kernel messages: dmesg | grep cgroup can reveal hidden compatibility issues.
• Container logs: Look for errors related to missing cgroup controllers, especially in legacy applications that may still expect v1 semantics.
• Future Ubuntu releases: Canonical has indicated that cgroup v2 will be the default for all subsequent LTS versions, so any lingering reliance on v1 will become a technical debt that must be eliminated.

By preparing now, you avoid a last‑minute scramble on April 23 and ensure your Ubuntu 26.04 LTS deployment runs smoothly with modern container tooling.