Force Upgrade Ubuntu 24.04 to 26.04 Early? Read This First

Canonical blocked the official do-release-upgrade path from Ubuntu 24.04 to 26.04 for a reason, and that reason has a name: rust-coreutils. If you're staring at a working 24.04 install and wondering whether you can just edit sources.list and jump the queue, the honest answer is yes, you can — but you need to understand what you're opting into first.

The delay isn't arbitrary bureaucracy. Oliver Reiche's mailing list announcement for Ubuntu 26.04.1 LTS confirmed that Canonical is holding back upgrades from 24.04 for a few weeks so it can land backports addressing regressions in a recent version of rust-coreutils. Ubuntu 25.10 users don't hit this wall, because their upgrade path went live back in April, before this particular issue surfaced. The ISO for 26.04 shipped on schedule, but ISOs and upgrade paths run on different clocks, and Canonical is choosing to hold the latter until the fix is solid.

Context: why the upgrade path lags the ISO

Ubuntu's release engineering treats fresh installs and in-place upgrades as separate problems with separate risk profiles. A new ISO installs onto a clean system, so any rough edges are a known quantity from day one. An in-place upgrade from 24.04 touches years of accumulated configuration, third-party PPAs, custom scripts, and whatever cron jobs you forgot you wrote in 2022.

Coreutils sits underneath almost everything. If the Rust-based reimplementation of core utilities like ls, cp, or mv has behavioral regressions, the blast radius on an upgraded system is much larger than on a fresh one.

This matters because Ubuntu has been migrating parts of its userland from traditional GNU coreutils to a Rust-based implementation, part of a broader industry trend toward memory-safe rewrites of decades-old C utilities. The intent is better security and fewer memory-safety bugs long-term. But rewrites of tools this fundamental carry real risk of subtle behavioral drift — edge cases in flag handling, locale quirks, or symlink resolution that scripts have quietly depended on for years. Canonical would rather delay the automated path by a few weeks than field a wave of broken systems in September. For more on this, see more on how to safely test a linux kernel release candidate.

The manual method itself is straightforward for anyone comfortable with a terminal. Edit /etc/apt/sources.list (or the relevant files in /etc/apt/sources.list.d/) and swap every instance of "noble" for "resolute" or whatever the 26.04 codename maps to in your file. Run apt update, then apt full-upgrade, followed by a reboot and a second full-upgrade pass to catch anything held back. This is the same mechanism do-release-upgrade uses under the hood; you're just doing it by hand instead of letting Canonical's tooling manage phased rollout, pre-checks, and rollback safety nets. This pairs well with go deeper on freebsd 14.5-rc1: upgrade now or wait for ga?.

Implications: who should actually do this

Skip this if the machine matters. That includes any system running production services, anything with irreplaceable data and no recent backup, and anything you can't afford to spend an evening troubleshooting. The rust-coreutils regressions Canonical flagged aren't hypothetical scare stories — they're the specific, named reason the automated path is paused. Forcing the upgrade manually doesn't fix the underlying package issue; it just removes the seatbelt Canonical put there while it finishes stitching backports together.

Also read: context: install a mainline linux kernel before your distro ships it

The calculus changes if you're running a test VM, a spare laptop, or a desktop where you genuinely just want to poke at 26.04 features early and you know your way around apt. In that case, the manual method is a reasonable way to satisfy curiosity, provided you snapshot the VM or keep a clean backup image first. Treat it the way you'd treat installing a beta: useful for feedback and exploration, risky for anything you depend on daily.

There's also a middle path worth considering: dist-upgrade to 25.10 first if you haven't already, since that channel's upgrade path to 26.04 went live back in April and isn't tangled up in the coreutils holdup. That gets you most of the way to bleeding-edge without wrestling with a blocked upgrade path, though it means living on a non-LTS release with its own six-month support clock.

For anyone managing more than one or two machines, or anything with users other than yourself depending on it, the math strongly favors waiting. A few weeks of patience costs you nothing except bragging rights. Jumping early costs you nothing if everything goes smoothly. But if it doesn't, you're debugging coreutils behavior changes on a live system with no official upgrade support to fall back on — and no clean way to have avoided the mess other than reinstalling.

Watch for Canonical's follow-up notice confirming the coreutils backports have landed and reopening the standard do-release-upgrade path for 24.04 users, expected around September based on Reiche's timeline. That announcement will also signal that testers running the manual method didn't uncover anything catastrophic in the meantime — useful information if you're still on the fence.