[doc] hardy installation fails to take direct route to lucid

Please can you post the contents of /etc/update-manager/release-upgrades, it should look something like this unless it has been changed:

# default behavior for the release upgrader
#

[DEFAULT]
# default prompting behavior, valid options:
# never - never prompt for a new distribution version
# normal - prompt if a new version of the distribution is available
# lts - prompt only if a LTS version of the distribution is available
Prompt=lts

I also ran into this problem.

The instructions on the various Lucid-related Wiki and web pages (e.g.
  https://wiki.ubuntu.com/LucidLynx/TechnicalOverview
and
  http://www.ubuntu.com/testing/lucid/alpha3
[along with the "alpha1" and "alpha2" pages]) all specifically say that the "Prompt=" line should be set to "normal".

When I saw those instructions, I figured that Lucid might not be considered an "LTS" release at this point in time (because it hadn't been released yet, or something like that), and I went ahead and set the line to "normal" -- but, just as reported in this bug, when I did the "do-release-upgrade -d" command, it tried to upgrade my system to Intrepid.

But once I changed the Prompt= line to "lts", the program started choosing Lucid as the target instead (as I wanted)

Perhaps the Lucid upgrade instructions could be edited to mention that people intending to jump directly from Hardy need to use "Prompt=lts" instead of "Prompt=normal"?

After waiting for a couple of days and unsuccessfully pinging mvo a couple of times for further triage I went ahead and updated the system with aptitude about 2 weeks ago. As such, I can now only provide information post-update.

the file in question has "Prompt=normal" and I don't remember touching that file.

The various Lucid release-notes pages now do include specific instructions for the direct hardy -> lucid upgrades.

So, that leaves just one wishlist suggestion: I wonder if it would make sense to update the comments in the /etc/update-manager/release-upgrades file to explain the situation more fully, e.g. something along these lines:

  # default prompting behavior, valid options:
  # never - never check for a new release
  # normal - check to see if a new release is available. If more than
  # one new release is found, the release upgrader will
  # attempt to upgrade to the release that immediately succeeds
  # the currently-running release.
  # lts - check to see if a new LTS release is available. The upgrader
  # will attempt to upgrade to the first LTS release available
  # after the currently-running one. (Note that this option
  # should not be used if the currently-running release is not
  # itself an LTS release, since in that case the upgrader won't
  # be able to determine if a newer release is available.)

(Or, perhaps it would be better to put the explaination of options into /usr/share/doc/update-manager-core/README , and replace the existing comments in the release-upgrades file with a pointer to that explaination.)

I see that launchpad doesn't preserve spaces with lines of Bug comments, so I am posting the suggested release-upgrades comment lines as an attachment.

Thanks Nathan. I pushed a branch that included your update to the comments, slightly modified by myself. I don't think moving them to the README is an improvement though. Better to leave the comments right where the option is I think. Thanks for the contribution!

Great, thanks.

The reason I suggested moving the explaination to the README was to avoid dpkg "Configuration file modified since installation" messages during future package upgrades.

Obviously one round of such manual intervention is unavoidable (for anyone who has changed already the file from its original installed form), but if the full description of the various supported options is moved into the README file, it could be changed/expanded later without triggering the changed-conffile situation again....

Related to that, I noticed that Bug #543165 has been marked as a duplicate of this one. However, I see that that request actually goes a few steps further: the idea there is that the upgrade manager would recognize that the currently-running release is an LTS and automatically check for both the next release and the next LTS release, and if both were available the user would then be presented with the choice as to which target release to upgrade to.

Obviously that would involve new logic in the upgrade-manager code... but if such a thing were eventually implemented, presumably the description text that you have just updated would need to be changed again....

Hi Nathan, good point about the config file message. It might be inconvenient but I still like having the description as close as possible to the thing it's describing. Otherwise, it's just way to easy for the information to get out of sync. As an example, I updated referenced wiki pages but do not have permission to update the www.ubuntu.com page. Hmm...

I think you're right that bug 543165 is not a strict duplicate of this one, so I'll remove that.

Thanks again.

This bug was fixed in the package update-manager - 1:0.133.7

---------------
update-manager (1:0.133.7) lucid; urgency=low

  [ Nathan Stratton Treadway ]
  * data/release-upgrades
    - Provide better explanation of what how the various options in the
      configuration file control which upgrades are presented to the user.
      (LP: #522910)

  [ Barry Warsaw ]
  * README
    - Minor clean up.

  [ Michael Vogt ]
  * DistUpgrade/DistUpgradeCache.py:
    - check if the kernel returned from base-installer is upgradable
      (needed on hardy cdrom only upgrades)
  * check-new-release-gtk:
    - fix "ask me later" button time
  * DistUpgrade/DistUpgradeQuirks.py:
    - fix 386 kernel check/transition on upgrades from hardy
    - move kubuntu-kde4-desktop transition into its own function
  * check-new-release-gtk:
    - use GtkProgress when downloading the release upgrader

  [ Dustin Kirkland ]
  * debian/91-release-upgrade: do the release upgrade check with the
    quiet option to avoid putting debug messages in the MOTD, LP: #548376
 -- Michael Vogt <email address hidden> Fri, 26 Mar 2010 22:13:17 +0100