Re: Problem with upgrading libc6
On 2009-03-16 17:42 +0100, NFN Smith wrote:
> I have a server that is running etch, and before upgrading to lenny,
> there's a a couple of packages with a lot of local configuration work in
> them that I want to upgrade individually to lenny versions first, so
> that I don't have the problem of having to adjust for lenny-specific
> changes to packages at the same time I'm upgrading the server. This
> server is running AMD-64 versions of Debian.
>
> For these packages, updates are requiring upgrade of libc6, that's
> giving me problems in version conflicts between libc6 and libc6-dev.
> libc6 upgrades, but for some reason libc6 dev doesn't.
This last sentence is not an accurate summary -- in fact, the libc6
is not upgraded because its preinst script fails. The new libc6-dev is
unpacked but will not work without the new libc6.
> Highlights from screen logs, when I run:
>
> aptitude -t stable install libc6
>
>> The following NEW packages will be installed:
>> linux-libc-dev [2.6.26-13]
>> The following packages will be REMOVED:
>> linux-kernel-headers [2.6.18-7]
>> The following packages will be upgraded:
>> binutils [2.17-3 -> 2.18.1~cvs20080103-7]
>> libc6 [2.3.6.ds1-13etch9 -> 2.7-18]
>> libc6-dev [2.3.6.ds1-13etch9 -> 2.7-18]
>> locales [2.3.6.ds1-13etch9 -> 2.7-18] tzdata [2008e-1etch3 -> 2008h-2]
>
>
>> Preparing to replace locales 2.3.6.ds1-13etch9 (using .../locales_2.7-18_all.deb) ...
>> Unpacking replacement locales ...
>> dpkg: linux-kernel-headers: dependency problems, but removing anyway as you request:
>> libc6-dev depends on linux-kernel-headers.
>
> Here's the beginning of the conflict. Locales seems OK, but removal
> linux-kernel-headers causes problems with libc6-dev.
These would have been temporary if everything had went okay. The new
version of libc6-dev depends on linux-libc-dev instead.
>> Unpacking linux-libc-dev (from .../linux-libc-dev_2.6.26-13_amd64.deb) ...
>> Preparing to replace binutils 2.17-3 (using .../binutils_2.18.1~cvs20080103-7_amd64.deb) ...
>> Unpacking replacement binutils ...
>> Preparing to replace libc6-dev 2.3.6.ds1-13etch9 (using .../libc6-dev_2.7-18_amd64.deb) ...
>> Unpacking replacement libc6-dev ...
>> Preparing to replace libc6 2.3.6.ds1-13etch9 (using .../libc6_2.7-18_amd64.deb) ...
>> Checking for services that may need to be restarted...
>> Checking init scripts...
>> Unpacking replacement libc6 ...
>> dpkg: error processing /var/cache/apt/archives/libc6_2.7-18_amd64.deb (--unpack):
>> dpkg: warning - old post-removal script killed by signal (Segmentation fault)
>
> Here's where it gets worse -- segmentation fault.
And this is your real problem. Right now I don't know why a program run
by the preinst script would segfault, but this seems to be a problem
specific to your machine. I suggest that you file a bug against libc6
and wait for the maintainers to give you instructions how to debug that.
My idea would be to unpack the preinst manually by switching to a
scratch directory, calling
# dpkg-deb -e /var/cache/apt/archives/libc6_2.7-18_amd64.deb
then adding a "set -x" at the beginning of DEBIAN/preinst and running it
manually with
# DEBIAN/preinst upgrade 2.3.6.ds1-13etch9
This is the way dpkg invokes it during the upgrade and should give you
an idea which program segfaults, if the problem is reproducible at all.
>> dpkg: error while cleaning up:
>> subprocess pre-installation script killed by signal (Segmentation fault)
>> Errors were encountered while processing:
>> /var/cache/apt/archives/libc6_2.7-18_amd64.deb
>> E: Sub-process /usr/bin/dpkg returned an error code (1)
>> A package failed to install. Trying to recover:
>> dpkg: dependency problems prevent configuration of libc6-dev:
>> libc6-dev depends on libc6 (= 2.7-18); however:
>> Package libc6 is not installed.
>> dpkg: error processing libc6-dev (--configure):
>> dependency problems - leaving unconfigured
>
> Here's the core conflict -- new version of libc6 and old version of
> libc6-dev.
This and the next errors are just consequences of the failed libc6
upgrade.
>> Setting up linux-libc-dev (2.6.26-13) ...
>> dpkg: dependency problems prevent configuration of locales:
>> locales depends on glibc-2.7-1; however:
>> Package glibc-2.7-1 is not installed.
>
> This one prevents correct configuration of locales
>
>> dpkg: error processing locales (--configure):
>> dependency problems - leaving unconfigured
>> dpkg: dependency problems prevent configuration of binutils:
>> binutils depends on libc6 (>= 2.7-1); however:
>> Package libc6 is not installed.
>> dpkg: error processing binutils (--configure):
>> dependency problems - leaving unconfigured
>> Errors were encountered while processing:
>> libc6-dev
>> locales
>> binutils
>
>
> At the end, three essential packages not upgraded.
These packages are not really essential, at least not in the sense of
the "Essential" field in the debian/control file.
> At this point, I went back and reinstalled libc6 from etch:
>
>>>
>>> Downgrade the following packages:
>>> binutils [2.18.1~cvs20080103-7 (stable, stable, now) -> 2.17-3 (oldstable, oldstable)]
>>> libc6-dev [2.7-18 (stable, stable, now) -> 2.3.6.ds1-13etch9 (oldstable, oldstable)]
>>> locales [2.7-18 (stable, stable, now) -> 2.3.6.ds1-13etch9 (oldstable, oldstable)]
>>>
>>> Score is -160
>>>
>>> Accept this solution? [Y/n/q/?] y
>>> The following packages will be DOWNGRADED:
>>> binutils [2.18.1~cvs20080103-7 -> 2.17-3]
>>> libc6-dev [2.7-18 -> 2.3.6.ds1-13etch9]
>>> locales [2.7-18 -> 2.3.6.ds1-13etch9]
>>> 0 packages upgraded, 0 newly installed, 3 downgraded, 0 to remove and 0 not upgraded.
>
>
> Following this downgrade, libc6 (and related dependencies) are all still
> at etch versions.
Given the circumstances, that was the best that you could do.
Sven
Reply to: