Upgrade Manager crashes during upgrade from Kubuntu Hardy to Intrepid

[Swâmi Petaramesh]

Binary package hint: update-manager

Same problem met on 3 different machines :

During upgrade from Kubuntu Hardy to Intrepid, upgrade manager silently crashes (its window disappears, "ps" shows it doesn't run anymore) and the machine is left is a severely incoherent, half-upgraded, unbootable state.

Only solution if the finish the upgrade manually using a combination of successive "dpkg --configure -a", "aptitude upgrade" and "aptitude install", which shows that exists a serious dependancy problem involving Amarok.

On 4 machines I upgraded from Hardy to Intrepid, 3 failed this way, only one went thru smoothly and the one that went thru smoothly had both Kubuntu and Ubuntu desktops installed. The 3 ones having only Kubuntu desktop crashed in the described manner.

(Actually the one that went thru OK was the dirtiest machine I had, that had been thru severeal dist-upgrades over the years, the 3 that crashed had a "clean" Kubuntu Hardy install before the upgrade...)

ProblemType: Package
Architecture: i386
Dependencies:

DistroRelease: Ubuntu 8.10
ErrorMessage: ErrorMessage: SystemError in cache.commit(): installArchives() failed

NonfreeKernelModules: ath_hal
Package: update-manager None [modified: /var/lib/dpkg/info/update-manager.list]
PackageArchitecture: all
SourcePackage: update-manager
Title: package update-manager None [modified: /var/lib/dpkg/info/update-manager.list] failed to install/upgrade: ErrorMessage: SystemError in cache.commit(): installArchives() failed
Uname: Linux 2.6.27-7-generic i686

[Patola (patola)]

Had the same problems on the 2 machines I have too. Both using 32-bit Kubuntu 8.04 installed with alternate disk to 32-bit Kubuntu 8.10 upgraded via update-manager.

[Patola (patola)]

Also, it would be nice to know if there's something extra that update-manager does when the dist-upgrade finishes, like converting KDE configuration files or the like. I just fixed the dependency problems, but don't know whether there are extra steps.

[Swâmi Petaramesh (swami-petaramesh)]

Yes, on the only machine where I saw the upgrade finish properly without crashing, it ends in "cleaning up" and uninstalling a lot of "obsolete" packages. I would love to know how to start this step after having finished manually an upgrade that badly failed - especially because I have a netbook on which SSD disk space is a real issue, so I wouldn't want to kep useless obsolete packages lying around...

[Jerome Haltom (wasabi)]

I've had this problem happen just today on two machines.

Started an upgrade, walked away. 2 hours later came back, machines were sitting at login screen. Keyboard didn't work. Upon rebooting machine got kernel error unable to sync VFS. Fixed by reverting to old kernel, rerunning dpkg --configure -a, and rebooting. dpkg --configure -a broke the first time, with !quote.length or something. This was because a lot of packages were failing to configure, because dbus could not be configured. /var/run/dbus was missing. I mkdir'd /var/run/dbus and dpkg --configure then worked. Rebooted, machine works.

During dpkg --configure -a, the X server started, repeatedly. This was ODD. I've never seen a package configure screw up X so badly.

I can't really explain what went wrong. What I *think* happened is the upgrade crashed X. Whatever script was causing the flickering the second time around crashed X the first time around... leaving the upgrade busted. grub got updated, so the kernel was in the menu, but the initramfs had not been built. The script that was breaking X... I could not identify it.

The /var/run/dbus thing might be an independent problem. It might be that the preinst script creates it, and after rebooting it was removed, and configure does not create it. I'm not sure if this is a bug or not though. I'll file it anyways and see the responses.

[Jerome Haltom (wasabi)]

Video hardware is an ATI mobility card. If in fact X is the issue, then this matters.

[Jean-Baptiste Lallement (jibel)]

@Swâmi,

The error was
dpkg: la zone de la base de données d'état est verrouillée par un autre processus

This was probably a transient situation due to a previous aborted upgrade. Can we close this report or is it still an issue ?

[Swâmi Petaramesh (swami-petaramesh)]

I've seen it on several machines and it involved issues with Amarok, not a "previously aborted upgrade". Anyway this happened while upgrading Hardy => Intrepid and didn't show up in newer Ubuntu releases, so I believe this bug can be closed.

[Jean-Baptiste Lallement (jibel)]

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