Bug#296077: upgrade-reports: Upgrade from Woody to Sarge: System hosed
Package: upgrade-reports
Version: woody -> sarge
Severity: critical
Justification: breaks the whole system
Hi,
about a week ago I took the plunge and upgraded one of my machines from
Woody to Sarge. Apart from the official packages I also had some
packages from backports or compiled from source. After replacing woody
in sources.list with sarge, I did an apt-get upgdate and after that an
apt-get dist-upgrade. As expected quite a number of packages were
scheduled for being upgraded. What was a bit unexpected was that there
were also a large number of packages scheduled for removal. I aborted
to make a backup of /etc/ and to direct the output of apt-get into a
file so that I would be able to install later on the packages that had
been removed. This way, I thought, everything would go smoothly.
Unfortunately, that was not the case. The upgrade ended half-way
through telling me that there was an undefined symbol Perl_gthr_key_ptr.
Going from there I found out with Google's help that there had
previously been similar bugs classified when dist-upgrading from woody
to sarge (278417, 278495 and 279232, possibly others, apparently there
is no way search to search for a string in bug reports present in the
BTS system). These were classified as RC.
Apparently the abortion of the upgrade is due to the fact that perl is
in an inconsistent state out of which the system cannot free itself.
And indeed 'dpkg -l perl*|grep ^i' tells me that perl, perl-modules and
perl-suid are version 5.8.4 -5, installed but unconfigured (iU) and that
perl-base is 5.6.1-8.8 (ii), perl-t k is 800.025-2 (iU) and perlmagick
is 5.4.4.5-1woody (ii). As advised on #debian, I tried via aptitude if
that was able to fix the mess, but quickly found out that it would most
likely only make matters worse. Thus I backed off and have not touched
the system since.
I have the following information still on file and can make it available
on request. I hope you understand that I do not include it yet in this
bug report for reasons of privacy and so as not to flood the BTS.
- tar file of /etc (and /home) before the upgrade
pre-upgrade /var I have unfortunately no copy of
- output of apt-get on what packages to install and which to remove
- output of dpkg -l right after the failed upgrade
- and of course the system itself in its current state
My assumption is that from this it should be possible to somehow
reconstruct what packages were installed at the time I tried the upgrade
and thus analyze what triggered this failure.
Best regards
Rolf Leggewie
-- System Information:
Debian Release: 3.0
APT prefers testing
APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.4.26.desktop041204
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Reply to: