when "do-release-upgrade" aborts, no instructions are given for how to complete the upgrade

[Nathan Stratton Treadway]

Binary package hint: update-manager

I was recently running "do-release-upgrade -d" from the command line to upgrade to Lucid (from Hardy).

After the command downloaded downloaded the "lucid.tar.gz" installer bundle followed by all the new .deb packages, and then installed/configured for a while, I got the following error message:

============================
dpkg: subprocess installed post-installation script returned error exit status 1
Exception during pm.DoInstall(): E:Sub-process /usr/bin/dpkg returned an error
code (2)

Could not install the upgrades

The upgrade is now aborted. Your system could be in an unusable
state. A recovery will run now (dpkg --configure -a).
============================

The system proceed with "Setting up" packages for a while, then finally, do-release-upgrade printed
============================
Upgrade complete

The upgrade is completed but there were errors during the upgrade
process.
============================
, and then I was returned to the my shell prompt.

After I resolved the issue that caused the "dpkg" error, I noticed that a number of packages were still back at their Hardy versions -- that is, that the upgrade hadn't actually "completed".
I tried running "do-release-upgrade -d" again in order to get the rest of the packages updated to their Lucid versions, but it aborted with the message "No new release found".

So I am writing to suggest the following (related) changes to the messages printed by the do-release-upgrade process:

1) In the cases where the upgrade is aborted due to a dpkg error, the two messages it prints out (which will often be many pages apart within the terminal session) should more consistent, or at least explained the exact status of the system more clearly (i.e. what has actually "completed" and what is still left unfinished).

2) The above-quoted "there were errors during the upgrade" message should include some more specific instructions about what the user is advised to do to recover from that situation. (In my case I just used "aptitude" manually to upgrade the rest of the packages, but I wasn't sure if there was some "better" way to proceed.)

(If such instructions can't be included into the "lucid" script for some reason, perhaps they could at least be included in the how-to-perform-an-upgrade instructions in the Lucid release notes.)

Thanks.

[Nathan Stratton Treadway (nathanst)]

(For example, I see now that normally the fullUpgrade() routine in the DistUpgradeController.py file [as included in the downloaded lucid.tar.gz] would have called teh doPostUpgrade() routine to "Search[...] for obsolete software".

But since the upgrade run aborted, the cleanup routine did not get called... and I don't immediately see any way to kick off that process by hand.)

[Nathan Stratton Treadway (nathanst)]

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 explanation 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 explanation.)

[Nathan Stratton Treadway (nathanst)]

(Please ignore comment #2, it was posted to the wrong bug.)

[Miguel Gaspar (ghaspias)]

I have been victim of the same problem (only in my case it was kvm-pxe that couldn't be upgraded).

During dist-upgrade, got the message:
Could not install '/var/cache/apt/archives/kvm-pxe_5.4.4-1ubuntu1.1_all.deb'
The upgrade will continue but the '/var/cache/apt/archives/kvm-pxe_5.4.4-1ubuntu1.1_all.deb' package may not be in a working state. Please consider submitting a bug report about it. unable to install new version of `/usr/share/kvm/pxe-e1000.bin': No such file or directory
-----
while setting up package kvm-pxe, got the message:
package kvm-pxe is already installed and configured
-----
The final message from dist-upgrade was:
Could not install the upgrades

The upgrade is now aborted. Your system could be in an unusable state. A recovery will run now (dpkg --configure -a).
-----
Didn't prompt for restart at the end.

As such, I was left with an incomplete upgrade. Although it is running, I don't trust the system now...

There are no clues as to how to finish the upgrade. For the end user, it is unclear whether the system is ok or not. Visually it is inconsistent. And I guess there might be some real issues, besides the cosmetic ones.
So, I would mark this bug's importance as medium or high.

I sugest two things:
1- the dist-upgrade shouldn't abort if at least all meta-packages were installed (the desktop). One package that didn't upgrade shouldn't be enough to abort the upgrade past the 'no-rollback' point.In a server environment it might be done differently.
2- if dist-upgrade aborts after no-rollback point, then it should provide the means to resume whatever it should have done, after the user (eventually) fixes the issues.

I'll try to find how to implement that, but I don't have much experience with python...

[Paul van Genderen (paulvg)]

My botched upgrade is actually Just Fine now. Here's what I did:

1. sudo dpkg --configure -a
2. sudo apt-get dist-upgrade
3. Then I downloaded lucid.tar.gz with wget 'http://archive.ubuntu.com/ubuntu/dists/lucid-proposed/main/dist-upgrader-all/current/lucid.tar.gz'
4. I extracted it in /var/tmp (warning: it dumps everything in the current directory).
5. I commented out line 352 from DistUpgradeView.py (return False)
6. ran sudo ./lucid and let it complain ;)
7. cleaned up /var/tmp (sudo rm -rf /var/tmp/*)

Hope this helps!

[kabsi (i41b-1aunchpad-0ut-hpgu)]

Paul, you saved my day. Thanks!

I was stuck with the error message and the problem reported in this bug. Had I rebooted the system, I would have been stuck with a half-updated non-bootable system. I followed your advice and got my system updated and running.

Changes to your suggestions:
- I dropped step #1 and #2 as I already had updated my system this way before running do-release-upgraded.
- The URL in step #3 has changed to
  http://archive.ubuntu.com/ubuntu/dists/lucid/main/dist-upgrader-all/current/lucid.tar.gz
- I dropped step #5 as I did not have to comment out line 352. it worked anyway.
- In step #6, I ran "sudo ./lucid --frontend=DistUpgradeViewText" as I prefer a text interface instead of a graphical view.

Step #6 failed due to some pakets. I deinstalled them and ran #6 again. I repeated this process until installation went through and offered a reboot.