Comment 7 for bug 365485

The difference is that on Debian, I can always resume an upgrade done with apt-get (or aptitude) dist-upgrade. Even though the dpkg process had gotten wedged in state D, the (first) reboot was a normal one; after I rebooted, I fully expected 'dpkg --configure -a' to resume where it left off, as it did.

Now although it turns out that I can do that on Ubuntu too, I had no way of knowing that; all I had to go on was that the upgrade was started from a mysterious icon in the notification area that no longer appears; after some research I found out that this was update-manager, but since that requires pygtk and X, I was not able to run it. For all I knew, this upgrade script did important things in addition to a dist-upgrade, things that wouldn't be done if the script was not used...

The problem here is basically the fragility of the upgrade process caused by relying on the update-manager script. From the PoV of an experienced Debian user, it seems like a pretty, but fragile front-end to running 'aptitude dist-upgrade'. And since it does not present any upgrade documentation to the user, the user is powerless to fix their system when an upgrade is aborted for whatever reaso.
I have now got the system to a working state by doing the old 'dpkg --configure --pending' followed by a few invocations of 'aptitude dist-upgrade' punctuated by fixing the issues I listed above. Working enough to download an install CD, anyway, and do a fresh install. :)

As for /usr/shareFeisty, I assumed that was an artifact of buggy maintainer scripts, rather than filesystem corruption; although, since I didn't run fsck before re-installing, I can't rule that out.