Can anyone tell me why Ubuntu thinks I’m asking it to install a “development” version of the distribution (see output below) when I run sudo do-release-upgrade? The command name carries no such implication.
Relevant System Information
No relevant customization (this is a stock 24.04 LTS box). The /etc/update-manager/release-upgrades file has
[DEFAULT]
Prompt=lts
Error Messages / Logs
$ sudo do-release-upgrade
Checking for a new Ubuntu release
There is no development version of an LTS available.
...
What I’ve Tried
I’ve tried reading the man page for the command. That documentation clearly states that the --devel-release option (which I am not using) is to be used to request a development release.
Well, it isn’t wrong per-se, the next “development version of an LTS” will be 28.04 during its development cycle … so until after 27.10 is released this is a correct statement.
I assume it falls back to that sentence since it can not find the stable 26.04 yet (because it is held back until all upgrade issues are resolved (which is actively being worked on), only the isos for 26.04.1 are out yet but there were issues with the upgrader that need solving)
Users of Ubuntu 24.04 LTS will be offered an automatic upgrade to 26.04.1 LTS
via Update Manager a couple of weeks following this release after some planned
backports to address regressions in a recent version of rust-coreutils.
In the meantime, those eager to make the jump can do so at any time by
running:
Thanks for all the replies. However, I’m not asking why the upgrade path isn’t ready yet (I understand they’re still wrestling with issues introduced by the rust tools). I’m asking why the message I get from the command makes it look like it thinks that I’m asking it to install a “development” version.
I can see how it might read like that. Here’s the code that makes that happen:
# now inform about a new release
if m.new_dist is None:
if not options.quiet:
if m.prompt == 'never':
print(_("In /etc/update-manager/release-upgrades Prompt "))
print(_("is set to never so upgrading is not possible."))
elif m.prompt == 'lts':
print(_("There is no development version of an LTS available."))
print(_("To upgrade to the latest non-LTS development release "))
print(_("set Prompt=normal in /etc/update-manager/release-upgrades."))
elif options.devel_release:
print(_("Upgrades to the development release are only "))
print(_("available from the latest supported release."))
else:
print(_("No new release found."))
sys.exit(NO_RELEASE_AVAILABLE)
Note that it doesn’t display something different if you did choose to do a development (-d) release (and you have Prompt=lts). It’s just informing you of the fact that there isn’t one that it could upgrade to if you did.
So it’s basically saying “if they configured the system to never upgrade then we tell them so, if they chose upgrade to a development release, tell them how they can get there, and if they’re on an LTS, remind them there is no development release for the LTS”. It’s all informational, if a little confusing.
I would be happy to file a bug report, once I’ve completed the first step in the instructions (“Confirm it’s a bug”). However, it’s looking more and more as if the consensus is that I’m the only one who finds the message to be odd.
The confusion (at least in my mind) is compounded further when I run sudo do-release-upgrade -c –devel-release I get this message:
```
Checking for a new Ubuntu release
New release ‘26.04.1 LTS’ available.
Run ‘do-release-upgrade’ to upgrade to it.
```
So, if the original message is conveying some correct and useful information (“informational”) and I just need to study it more closely in order to dispel my confusion, can I please get a clue explaining why the command is telling me it can’t find a “development” release when I run sudo do-release-upgrade, because I’m not seeing it.
If the answer is “yeah, that’s weird, but it’s been that way so long that all the rest of us have gotten used to it, so just get over it” then please let me know and I’ll not bother filing a bug report.
-d, --devel-release If using the latest supported release, upgrade to the
development release
{snip}
-c, --check-dist-upgrade-only
Check only if a new distribution release is available
and report the result via the exit code
You’re essentially telling it to check if the “development release” is available to upgrade to, and then it’s instructing you how, minus the -d since those who the -d flag targets already know this.
If you run do-release-upgrade -d, it will do what you’re expecting. However, until a few bugs are resolved (being tracked at LP: #2167221), it is highly discouraged.
The problem is, when executing do-release-upgrade without -d users expects it will search for a stable release so the There is no development version of an LTS available is highly confusing. Why it would inform me about development version when searching for stable update?
In fact this message convinced me I’m somewhat stuck on tracking development releases and that’s the reason I can’t upgrade to stable 26.04 release which whole world is talking about. I forced the update afterwards thinking I’m fixing some bug. The message should say There is no stable version of an LTS available if -d wasn’t passed.
It’s because development doesn’t go LTS directly to LTS. It goes LTS → interim → interim → interim → LTS. You cannot get a development version of an LTS as it just doesn’t exist. Therefore, development is always the next release regardless of interim or LTS status.
The release always develops on top of the release prior, regardless of LTS status.
Nobody has answered the actual question from the OP’s #9 — why the two commands appear to contradict each other. I read the source, and the answer has nothing to do with wording.
The key fact: in changelogs.ubuntu.com/meta-release-lts, the entry for 26.04.1 currently has Supported: 0.
When do-release-upgrade picks a target release (UpdateManager/Core/MetaRelease.py), it loops:
for dist in dists:
if dist.date > current_dist.date:
if not dist.supported and not self.useDevelopmentRelease:
continue
upgradable_to = dist
break
So:
do-release-upgrade (no -d): useDevelopmentRelease=False → 26.04.1 gets skipped by the continue because Supported: 0 → the loop finds nothing → new_dist is None → it hits the m.prompt == 'lts' branch and prints “There is no development version of an LTS available.”
do-release-upgrade -c --devel-release: useDevelopmentRelease=True → not skipped → new_dist is 26.04.1 → prints “New release ‘26.04.1 LTS’ available.”
The two messages aren’t contradictory — they’re the same piece of metadata (Supported: 0) run through two different filters. What -d actually bypasses is this supported-check, which is also why it has always worked as the “force” flag.
So this probably isn’t a wording bug. The upgrade path to 26.04.1 simply isn’t open yet — which lines up with ogra’s #3 point that the upgrade is being held back until the remaining issues are resolved. Once changelogs.ubuntu.com flips Supported to 1, the first command will start printing “New release ‘26.04.1 LTS’ available.” on its own. Until then, only -d gets through.
(One clarification: the snippet popey posted in #7 lives in do-release-upgrade, but the logic deciding whether new_dist is None lives in the UpdateManager package’s MetaRelease.py. They’re separate, which is why looking at the message branch alone doesn’t explain the behaviour.)
Which is a bug. The 26.04.1 is not a “development version of LTS” and its availability should not depend on the useDevlopmentRelease.
While the text “There is no development version of an LTS available.” is technically correct it lacks the most vital piece of information for the end users - why the non development LTS version is not offered.
The situation is 100% equivalent to the phased updates. They are available (apt list --upgradable shows them), but they are skipped by apt upgrade. But at least here users get clear explanation why it happens. Simple line “The upgrade to the current LTS release is held back” would be enough to stop these endless threads.
