'do-release-upgrade' requires the '-d' flag to upgrade from dapper to hardy, and from hardy to lucid

Bug #223741 reported by Alex Mauer
52
This bug affects 6 people
Affects Status Importance Assigned to Milestone
Ubuntu Server papercuts
Invalid
Undecided
Unassigned
update-manager-core (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

Binary package hint: update-manager-core

Despite the fact that Hardy has been officially released and is therefore no longer a 'devel release', upgrading to it from Dapper requires the --devel-release flag.

It is understandable that it might be desirable to prevent users of the LTS release from accidentally upgrading their running system, but this flag should not be used to force the upgrade.

Once Intrepid Ibis is the devel release, will a dapper 'do-release-upgrade --devel-release' upgrade to the development release, or the next non-devel LTS release?

It would be much better to add a '--lts-release' flag for doing the upgrade between LTS releases.

Revision history for this message
Chris Knowles (chrisk-scaredsheep) wrote :

I can confirm this, I have a dapper system that reports "No new release found" to the command "sudo do-release-upgrade" and does update the system if the -d flag is used.

Changed in update-manager-core:
status: New → Confirmed
Revision history for this message
NoOp (glgxg) wrote :

Using the '-d' flag now causes Packages.bz2 and Sources.bz2 Hash Sum mismatch's. "sudo do-release-upgrade" by itself now works. Please modify the upgrade instructions on http://www.ubuntu.com/getubuntu/upgrading as this is causing considerable problems with folks trying to upgrade. I've just tested on a 6.04.2 (fresh) install and the following works:

sudo aptitude upgrade
sudo aptitude dist-upgrade
sudo aptitude install update-manager-core
sudo do-release-upgrade

Revision history for this message
Jamin W. Collins (jcollins) wrote :

This same bug now applies to upgrading from Hardy (8.04) to Lucid (10.04). Issuing "sudo do-release-upgrade" does not find the new LTS release. Heck, even the release notes seem to indicate that passing a "-d" is the "proper" way. This seems very broken and less than desirable to me.

Alex Mauer (hawke)
summary: 'do-release-upgrade' requires the '-d' flag to upgrade from dapper to
- hardy
+ hardy, and from hardy to lucid
Revision history for this message
Ricardo Pérez López (ricardo) wrote :

Confirmed for me, too. In order to upgrade my system from Hardy to Lucid, I need to use the -d option with update-manager.

Revision history for this message
Thierry Carrez (ttx) wrote :

This is not a bug. LTS -> LTS upgrades are enabled for the general public after the LTS.1 version is released, in order to flesh out the remaining upgrade issues. Until .1 you need either "-d" or "--proposed" to upgrade.

10.04.1 is expected on July 29th.

Changed in update-manager-core (Ubuntu):
status: Confirmed → Invalid
Changed in server-papercuts:
status: New → Invalid
Revision history for this message
Jamin W. Collins (jcollins) wrote :

Besides this bug report, where is this listed?

Revision history for this message
Thierry Carrez (ttx) wrote :
Revision history for this message
Jamin W. Collins (jcollins) wrote :

Neither of those links appear to provide any reference to LTS upgrades not needing either the -d or the --proposed after the LTS.1 release. I could be overlooking it, but I can't seem to find any reference to this functionality outside of this bug report.

Revision history for this message
Thierry Carrez (ttx) wrote :

The doc is updated by .1 release to reflect that (if you look at https://help.ubuntu.com/community/HardyUpgrades, you can see that it doesn't mention --proposed anymore). In the mean time, it's true it /could/ mention that --proposed is only temporary, until .1 is out.

Revision history for this message
David Jennings (mail-davidjennings) wrote :

This information should certainly go in the official upgrade instructions here: https://help.ubuntu.com/10.04/serverguide/C/installing-upgrading.html. It'd be nice to have some mechanism to be notified of when the .1 release is out.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.