>
Tech News

Why the Ubuntu LTS upgrade is a habit, not a version

I skipped the last Ubuntu LTS upgrade on my main laptop. Not because of a bug report, not because I had read something scary on a forum, and not because I was too busy to run do-release-upgrade. I skipped it because my current install still works for everything I do, and the longer an install lives, the more muscle memory and tuned packages stack on top of it. Every upgrade I have done on a long-running laptop has cost me something, sometimes an hour, sometimes a Saturday. The new 26.04.1 point release made me think about that math again.

A point release is the polished version of an LTS you should already be on. It is the install media Canonical ships once the dust from the April launch has settled, with several months of bug fixes already folded in. Anyone installing Ubuntu for the first time should grab this image. Anyone still on a previous LTS is being asked to upgrade. The catch this cycle is that the LTS-to-LTS offer through the GUI is not on yet, and Canonical is being upfront about why.

The cost of skipping, and the cost of going

The argument for not upgrading sounds reasonable on the surface. Your current install works. Your packages are pinned. Your keyboard shortcuts are wired up. The system has the cron jobs, the SSH keys, the Python virtualenv (a self-contained Python install that keeps dependencies isolated per project) that you do not want to rebuild. Every time you upgrade, you trade a known-good system for a known-later system, and the only thing that changes in your favor is the date string in lsb_release.

That math is wrong in three specific cases.

  • The kernel is far enough behind that new hardware stops working. USB-C docks, Wi-Fi 7 chips, and newer AMD GPUs are the obvious offenders. Plug something in this year and watch it not show up, and the kernel line on your LTS is the first thing to check.
  • A security fix shipped that your installed base genuinely needs. Most distros backport (apply newer patches onto an older codebase to keep the package stable) security patches, but backports can lag by weeks and occasionally miss the bleeding-edge variants. Anyone whose laptop handles regulated data should treat the backport lag as the real deadline, not the LTS end-of-life date.
  • You want to hand the laptop to someone else and never hear about it again. A fresh install on supported media is the cleanest way to do that. The 26.04.1 image is built for exactly this scenario.

For everything else, the case for staying put is real. I kept a laptop on 22.04 for an extra six months past the official upgrade window because I had a long-running project pinned to a specific Python interpreter. The cost of breaking that project would have been more than the cost of staying on the older LTS.

What Canonical is being careful about, in plain language

The Ubuntu Release Team has said the automatic LTS-to-LTS offer for 24.04 users will land a couple of weeks after 26.04.1, not on day one. The official reason is that they want to backport fixes for regressions in a recent version of rust-coreutils (the GNU core utilities like ls, cat, and cp rewritten in the Rust programming language for memory safety) before they offer the upgrade to millions of machines at once.

That is the right call, and it is worth understanding why. A regression in core utilities is not the kind of regression you can roll back from a single user’s bug report. It is the kind of regression that breaks cp on specific filenames, or breaks sort on locale-specific input (the way text is sorted depends on the user’s language and region), or breaks find on a specific filesystem layout. When that ships through an automatic offer, the blast radius is the entire 24.04 installed base. The two-week delay is the boring adult answer, and I am grateful for it even though it broke my plan for the weekend.

The impatient path, if you have a test box

Anyone who does not want to wait for the GUI prompt can trigger the upgrade today. The command has been the same for years:

sudo do-release-upgrade -d

The -d flag tells the upgrade tool to consider the next development release as a valid target. In the LTS context, that means the next LTS. You see a summary, answer a few prompts, and let it run for an hour or two. I have used this command more times than I would like to admit, and the only times it has gone badly for me were when I skipped the snapshot step.

  • Run a full apt update && apt full-upgrade first so your starting state is clean.
  • Take a snapshot or a Timeshift backup before you start. The upgrade is reliable. Your data is the part I am protecting.
  • Have a recovery USB on hand. You will not need it nine times out of ten, but the one time you do, it is the only thing that matters.
  • Treat the command the way you treat any major version bump: never run it on the laptop you are presenting from the next morning.

I personally run this on a test box, watch it for an hour, and only then decide whether to run it on the laptop that matters.

What to actually do this week

Anyone on 24.04 LTS has a choice between the wait-and-see path and the manual path. The wait-and-see path is the default. Let Canonical push the offer through the GUI, click through it on a Saturday, and stop thinking about it. The manual path is fine for anyone who has already tested their critical apps on 26.04 and just wants to get it done.

For people already on 26.04, there is nothing special to do. Run your normal update routine and stop reading. The 26.04.1 media is for fresh installs, not for the people who have already been on the April release.

Anyone installing Ubuntu fresh today should download the 26.04.1 image. You are skipping the post-install patch marathon that anyone who installed the original April release had to sit through. That is the entire point of the point release, and it is the only reason this article exists.

Trade-offs

The 24.04 automatic upgrade delay is annoying for anyone who had a weekend planned. It is also the cheapest insurance policy you will get for the next major version. Core utility regressions on a multi-million-machine installed base are not a thing you want to debug on a Friday night.

Manual path users get the upgrade today, but they also take on more responsibility than the wait-and-see path. Production boxes that cannot tolerate a surprise should wait. Anyone with a test box and a free hour can take the manual path, which has been stable for years.

Flavor lock-in is real. Anyone running Kubuntu, Lubuntu, or any of the official community editions gets three years of standard support instead of the main edition’s five. That is fine for a home desktop, less fine for a server. Long support windows plus a non-default desktop means either committing to stay current with each LTS cycle or paying for Extended Security Maintenance on top.

The bigger trade-off is the one I keep coming back to. Every LTS upgrade is a bet that the next two years of muscle memory are worth rebuilding. For me, on my main laptop, the answer is still no, not yet. For the test box, the answer was yes, last weekend. The point release is what made that question worth asking again.

What I would tell past me

  • The install date is not a deadline. You are allowed to skip an LTS upgrade if your current install still does the job. The cost of upgrading is real even when the upgrade works.
  • Point releases are for fresh installs, not for staying current. Anyone already on the right LTS treats the .1 release as a non-event. Anyone handing a laptop to someone else wants the .1 image as the install media.
  • Two weeks of delay is not a story. It is a release team being careful about core utilities across a huge installed base. Anyone who has ever been on the hook for a botched upgrade understands why this is the right call. Anyone who has not should trust the boring answer.

Source: Ubuntu 26.04.1 LTS Released, 24.04 LTS Upgrades Coming in a Few Weeks

EDLJX-20260829-011900-14123-2

Leave a comment