Distribution upgrade feisty->gutsy leaves system half configured

[Torsten Eichstädt]

I mounted /var/cache/apt over NFS, because my disk is only 4GB, free space was about 700MB .
Upgrade seemed to do fine, so I went away letting it download the stuff.
When I came back, all packages were downloaded, and I started answering the questions.
The upgrader's window freezed when I tried to scroll back in the terminal ouput.
So I shot that window and rebooted in the hope that the system would go on upgrading automagically.
But no, the upgrade left the system half-configured (wishlist: upgrade should try to proceed after a crash):
- Now, when I start adept-updater, it complains that some other program is using the package database.
  It crashes when I click "Yes" to resolv that issue. Traceback appended.
- no net, only IPV6 for eth (DHCP fails; manually ifconfig'ing the interface for IPV4 is possible)
- no rpc.statd --> (manual) NFS mounts now must have 'nolock' (no automatic mount because no net)
- '/etc/init.d/nfs-common.dpkg-new start' runs several minutes, but statd does not start.
  Manually starting rpc.statd does not help either.
- /etc is full of *.dpkg-new files
- Only 100MB free on my disk (ok, that's not a bug, but wishlist): the upgrader could warn in such a case
  beforehand that after the upgrade there will be such little space left free (15% threshold to show this warning)
- !Very good!: The system guesses the meta-package kubuntu-desktop, although I removed a package.
  Hence, new packages in the meta-package will be installed (I can remove later if I don't like 'em)
Logs appended.
How can I resolve this?

[Torsten Eichstädt (torsten-eichstaedt)]

KDE crash handler backtrace:
(no debugging symbols found)
Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
(no debugging symbols found)
...
[Thread debugging using libthread_db enabled]
[New Thread -1235621680 (LWP 13062)]
(no debugging symbols found)
...
[KCrash handler]
#6 0xffffe410 in __kernel_vsyscall ()
#7 0xb65f9875 in raise () from /lib/tls/i686/cmov/libc.so.6
#8 0xb65fb201 in abort () from /lib/tls/i686/cmov/libc.so.6
#9 0xb68046e0 in __gnu_cxx::__verbose_terminate_handler ()
   from /usr/lib/libstdc++.so.6
#10 0xb6801f65 in ?? () from /usr/lib/libstdc++.so.6
#11 0xb6801fa2 in std::terminate () from /usr/lib/libstdc++.so.6
#12 0xb68020ca in __cxa_throw () from /usr/lib/libstdc++.so.6
#13 0x08116f26 in ?? ()
#14 0x0811749a in ?? ()
#15 0x081174f8 in ?? ()
#16 0x08117d45 in ?? ()
#17 0x0811583d in ?? ()
#18 0x080ff989 in ?? ()
#19 0x08082bbd in ?? ()
#20 0x080711fa in ?? ()
#21 0x08071554 in ?? ()
#22 0xb6e49893 in QObject::activate_signal () from /usr/lib/libqt-mt.so.3
#23 0xb71d58ec in QSignal::signal () from /usr/lib/libqt-mt.so.3
#24 0xb6e69842 in QSignal::activate () from /usr/lib/libqt-mt.so.3
#25 0xb6e71258 in QSingleShotTimer::event () from /usr/lib/libqt-mt.so.3
#26 0xb6de0af0 in QApplication::internalNotify () from /usr/lib/libqt-mt.so.3
#27 0xb6de291f in QApplication::notify () from /usr/lib/libqt-mt.so.3
#28 0xb75a6ca2 in KApplication::notify () from /usr/lib/libkdecore.so.4
#29 0xb6d73209 in QApplication::sendEvent () from /usr/lib/libqt-mt.so.3
#30 0xb6dd353b in QEventLoop::activateTimers () from /usr/lib/libqt-mt.so.3
#31 0xb6d87d49 in QEventLoop::processEvents () from /usr/lib/libqt-mt.so.3
#32 0xb6dfb1ce in QEventLoop::enterLoop () from /usr/lib/libqt-mt.so.3
#33 0xb6dfafde in QEventLoop::exec () from /usr/lib/libqt-mt.so.3
#34 0xb6de2699 in QApplication::exec () from /usr/lib/libqt-mt.so.3
#35 0x0806e7b5 in ?? ()
#36 0xb65e5050 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
#37 0x0806e501 in ?? ()

[Torsten Eichstädt (torsten-eichstaedt)]

'dpkg --configure -a' fixed the package database temporarily.
Note: I had to get the NFS lock things run for the command above to succeed.
But I ran into problems with the package management system again today; I'll post annother bug on that.