Ubuntu 25.10 Is Obsolete and apt Still Reports Success
Launchpad marks 25.10 Obsolete, but the repositories are still on archive.ubuntu.com, frozen since July. So apt update succeeds, unattended-upgrades logs a clean run, and nothing on the machine tells you patches stopped.
Canonical’s own tracker settles the question. Ask Launchpad about the questing series and it returns "status": "Obsolete" with "supported": false. Ubuntu 25.10 shipped 9 October 2025, interim releases get nine months of updates, and that ran out in July.
What did not happen is the thing most end-of-life advice describes. The repositories did not go away.
The failure mode is silence, not errors
archive.ubuntu.com is still serving questing today. Not old-releases.ubuntu.com, where dead releases eventually land. The live archive, returning 200, exactly as it did in June. What changed is that nothing is being published into it.
Every suite’s Release file carries the timestamp of its last change, which makes this checkable in one request per suite. Read on 23 August 2026:
| Suite | Release file last dated |
|---|---|
noble-updates (24.04 LTS) | 23 Aug 2026 |
resolute-updates (26.04 LTS) | 23 Aug 2026 |
questing-security (25.10) | 20 Jul 2026 |
questing-updates (25.10) | 17 Jul 2026 |
plucky-updates (25.04) | 19 Jan 2026 |
The supported releases changed today. 25.10 last changed five weeks ago. And 25.04, dead since January, is still on the live archive seven months later.
A vulnerability scanner will eventually flag the package versions, and if you are under SOC 2 or ISO 27001 an unsupported operating system is the kind of finding that lands in the summary rather than the appendix. But the machine itself will never say anything. unattended-upgrades cannot distinguish “no updates because you are current” from “no updates because nobody is publishing any.”
So do not test for the failure. Test for the freeze:
curl -s "http://archive.ubuntu.com/ubuntu/dists/$(lsb_release -cs)-security/Release" \
| awk -F': ' '/^Date:/{print $2; exit}'If that date is weeks old, the release is done, whatever the calendar says. It works on any Ubuntu box and it does not depend on knowing the end-of-life date, which is useful, because the published dates disagree with each other by about a week for this release and none of them matter next to what the archive is actually doing.
The upgrade is offered from 25.10 and not yet from 24.04
Which target do-release-upgrade proposes comes from a text feed, and the two feeds currently disagree. In meta-release, the one an interim release reads, resolute (26.04) is marked Supported: 1. In meta-release-lts, which is what an LTS box reads, the same release is still Supported: 0.
Read plainly: 25.10 can upgrade to 26.04 right now, and 24.04 LTS cannot. Canonical flips the LTS flag at the first point release, so if you are on 24.04 and wondering why the tool says no new release is available, nothing is broken and there is nothing to fix. You are on a supported release that got a security publish today.
That also settles a question worth asking before you start. If the box is on 25.10 only because someone wanted a newer kernel two releases ago, going to 26.04 LTS ends the nine-month cycle: standard security maintenance runs to April 2031, and Ubuntu Pro extends it to 2036. If nothing on the machine actually needs interim packages, this is the upgrade that stops you doing this again in nine months.
Before running do-release-upgrade
Snapshot the disk. On any cloud provider this is a couple of clicks and it converts a bad upgrade from a rebuild into a volume reattach. It is the step everyone skips because it is “just an OS upgrade.”
Fully patch 25.10 first, with sudo apt update && sudo apt full-upgrade -y, and reboot if a kernel came down. Most upgrade failures trace back to a system that was not current, a kernel update that never got its reboot, or a third-party PPA. The first two are free to fix.
Disable third-party PPAs yourself rather than letting the tool do it mid-run. do-release-upgrade usually handles them, but a PPA with no 26.04 packages produces “an unresolvable problem occurred” partway through, and now you are debugging a half-upgraded system instead of a clean one. Re-enable them one at a time afterward. When it does happen, the repository it choked on is named in /var/log/dist-upgrade/main.log, and the fix is to back out and restart cleanly rather than to force through with apt --fix-broken.
Run the upgrade inside screen or tmux so a dropped SSH session does not take the upgrade with it:
sudo apt update && sudo apt full-upgrade -y
sudo do-release-upgradeRead the config-conflict prompts instead of holding down “keep the local version.” Anything you hand-edited, sshd_config in particular, gets asked about, and answering on autopilot is how people lock themselves out of the box they are upgrading.
Afterward
Check rather than eyeball:
lsb_release -a # 26.04
uname -r # new kernel
systemctl --failed # services that did not come back
docker ps # containers restarted and healthysystemctl --failed is the one worth running even when everything looks fine. A service that silently did not restart is a problem you find three days later, attached to something else entirely.
Two configuration files get reset to release defaults during the upgrade and are easy to miss: unattended-upgrades and cloud-init. If either was customized, a schedule, or user-data behavior for an autoscaling group, diff them against the snapshot and reapply. Given that this whole post is about patching quietly stopping, an unattended-upgrades config that reverted is a particularly bad one to lose.
The boxes this catches
Not servers people log into. CI runners.
A self-hosted GitHub Actions runner, GitLab runner, or Jenkins agent gets built once and then executes jobs until something breaks. Nobody opens a shell on it, so nobody sees a release upgrade notice, and the check above never gets run because no human is there to run it. Drain the runner before you upgrade it rather than after, so a job does not land mid-upgrade and fail in a way that reads like a pipeline bug.
Then run one throwaway pipeline against the upgraded runner before trusting it back into the pool. A runner that has been alive for two years has accumulated assumptions nobody wrote down, a glibc version something was compiled against, a Python or Node outside your build’s own toolchain management. The upgrade removes none of it but moves all the versions. And upgrade a fleet one at a time, watching the first for a day, for the same reason you would not deploy to every region at once.
If your interest here is base images rather than hosts, the same shape shows up one layer down in Debian 11 inside your Dockerfiles.
Run the Release date check on every Ubuntu box you own, not just the ones you suspect. It takes a second each, it needs no agent, and the answer for 25.04 machines is that they have been unpatched since January while reporting nothing at all.