Situation is critical for me: network upgrade failed-updater has hanged in the middle, system is in intermediate state and I see no way to resume update (Kubuntu x64 7.04 to 7.10)

Bug #154434 reported by PowerUser
8
Affects Status Importance Assigned to Milestone
update-manager (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

Initiall state:
 There was x64 Kubuntu 7.04 "Fiesty Fawn" with dozen of programs installed.

Actions I did
 Launched Adept manager and when noticed that it is possible to upgrade I'd chosen to perform distributive upgrade.

What happened?
 - Network update has started.
 - Download of updater was OK
 - It downloaded its required files - *very* slow but finally OK
 - It has changed repositories OK
 - It has detected which new packages to fetch.
 - It has downloaded all packages to update (took approx 2 hours).Seems to be OK.
 - Then packages extraction and replacing has began...
 ...and somewhere in the middle updater has stopped further progressing while replacing libgcc1.
 I waited for several hours and since there was no any progress I'd quit updater.
 - It warned me that exiting is bad idea but well... I'm tired watching on hanged and non-progressing updater for several hours anyway. There was no progress indication, HDD does nothing, CPU load is zero.
 - Looks like this did not terminated updater properly with clicking [x] button even while it detected cancel request. There was still dist-upgrade.py running with it's child subprocesses (dpkg, etc) in background. These did exactly nothing except that when I'm killed hanged dpkg command (see below) it attempted to proceed with next package (without success, new dpkg hangs, too). I'd killed this script and its childs since they're doing nothing useful anyway at this point (still no any noticeable activity in 30 minutes time frame).

What now?
 Now I have half-upgraded system which is probably unstable.I do not know if it will be able to boot properly if restarted.
 As a QA I see the following issues here:

 1) No proper error handling. When developing such tools you have to keep in mind that network or servers can fail during upgrade, something may hang or malfunction, etc. Looks like upgrader did not handles errors properly and gives me no chance to retry failed operation?
 2) I see no evident option to retry network upgrade so I'm now having half-upgraded system.Looks like packages are remaining downloaded but how to use them?Install over 1000 packages manually is a BAD idea.Have I redownload them all and wait for another 2 hours?
Also I wonder if there is any safety checks that packages downloaded OK and did not corrupted due to server failures and auto-redownload if something fails check?Maybe I have some packages corrupted?

Any ideas?Are there any options to retry upgrade with upgrade wizard?Or any options how to try to complete upgrade manually?
Or should I consider my OS install now became completely messed up and I should reinstall it from scratch?

Technical details:
 I discovered that hanged command which has caused upgrader to stop further processing was the following:

/tmp/kde-root/adept_manageriAwzFa.tmp-extract/backports/usr/bin/dpkg --force-overwrite --status-fd 72 --unpack --auto-deconfigure /var/cache/apt/archives/libgcc1_1%3a4.2.1-5ubuntu4_amd64.deb

There is probably also some usable logs - if you need these tell me their path.Please note that if it will take a while to handle this bug, logs can be trashed or they can contain other data since sticking to half-upgrated system is not an option for me.

Tags: feisty2gutsy
Revision history for this message
PowerUser (i-am-sergey) wrote :

Now there is continuation of this update story - I'm attempting to recover my half-updated system...
 As you may know, I was not able to perform upgrade and after updater failure I used my half-upgraded system and attempted to get things working properly.

After some googling, reading more about update procedure and finally taking a look on my Adept settings I figured out that I need re-enable some kinds of updates (disabled during [failed] update) and refresh packages list.This should enable dist upgrade.However doing so has completely crashed my APT subsystem :(.GUI software reported some problems with database but no any detailed hints. Running apt-get has made things clear.At any action error was always same and it was related to packages database:

# apt-cache stats
E: Dynamic MMap ran out of room
E: Error occurred while processing kdeprint (NewVersion1)
E: Problem with MergeList /var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_feisty-updates_main_binary-amd64_Packages

This effectively prevented me from dealing with apt subsystem at all, totally eliminating all my chances to upgrade. Some investigation and googling has shown that this issue has workaround:

1) Create file /etc/apt/apt.conf (if not exists)
2) add the following line into it:
APT::Cache-Limit 125829120;

In original solution 12582912 was suggested but this is too few and as for me it just delayed a bit appearance of this error.Increasing cache size by factor 10 was enough to get apt-get and all related tools working again.Hooray!

Now I'm launched adept, ensured all update types enabled and refreshed packages.Hooray, now I can dist-upgrade!
Upgrade applied ok, looks like downloaded packages were taken from cache.So system is basically updated and works.Reboot was requested, it has completed and overall status was success...

...except that my system did not booted and I had to fix /boot/grub/menu.lst manually.This happens since I'm booting from 2nd physical HDD while first one is data-only and it looks like my BIOS has pretty strange idea about mapping this second HDD as first if you're switching boot in bios to boot from it, actually seems to be some sort of BIOS "surprises". I'm really suspect my bios is quite bigged and needs update.Thanks to Live CD I can mount my HDD and correct menu.lst to get my system back in booting state.Voila! :)

But er... while things are genereally working, upon reboot adept notifier has falsely claimed that dist-upgrade has arrived (yikes!).This is pretty strange since updater has cleaned things up and adjusted software channels.When I attempted to run updater to perform dist upgrade it did worked up to some point and then discovered the truth :) that dist upgrade is not really needed.It output error:
 Your system is up-to-date.
There are no upgrades available for your system. The upgrade will now be cancelled.

This is OK :) but hey, why it offers to upgrade already upgraded system? I did something wrong when doing crash-recovery steps?

Revision history for this message
Steve (ubuntu-ittibitti) wrote :

I had a very similar problem using the xfce front-end. Things started going poorly toward the end of the pam upgrade where the daemon was restarted. It hung there for more than an hour with no system activity. I killed the restart job and the upgrade resumed. It eventually decided to fail. I'm restarting from scratch.

Revision history for this message
Ralph Janke (txwikinger) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. This bug did not have a package associated with it, which is important for ensuring that it gets looked at by the proper developers. You can learn more about finding the right package at https://wiki.ubuntu.com/Bugs/FindRightPackage . I have classified this bug as a bug in adept.

Revision history for this message
PowerUser (i-am-sergey) wrote :

Btw....
1) False reports about new OS version available are gone after some update.That's good :)
2) Now, after BIOSupdate and reset to defaults, BIOS's view of HDDs matches Kubuntu's so problem with failed OS boot should no longer occur.Looks like it is motherboard vendor to blame rather than anyone else :)

Revision history for this message
Jean-Baptiste Lallement (jibel) wrote :

Thanks for following up. I'm closing this report due to your last comment. Don't hesitate to submit any new bug.

Changed in update-manager:
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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