Bug#465753: libc6: symbol _dl_out_of_memory, version GLIBC_PRIVATE not defined
Michael Prokop a écrit :
> Package: libc6
> Version: 2.7-8
> Severity: important
>
>
> I've a base.tgz for faster chroot setup within FAI (so it's like a
> normal bootstrapped system in case you aren't familiar with FAI) and
> upgrading from 2.3.6.ds1-13etch2 to libc6 2.7-8 fails:
>
> ,---- [ quoting upgrade process ]
> | [...]
> | Non-interactive mode, upgrade glibc forcibly
> |
> | Unpacking replacement libc6 ...
> | /bin/sh: relocation error: /lib/tls/libc.so.6: symbol _dl_out_of_memory, version GLIBC_PRIVATE not defined in file ld-linux.so.2 with link time reference
> | dpkg: warning - old post-removal script returned error exit status 127
> | dpkg - trying script from the new package instead ...
> | /bin/sh: relocation error: /lib/tls/libc.so.6: symbol _dl_out_of_memory, version GLIBC_PRIVATE not defined in file ld-linux.so.2 with link time reference
> | dpkg: error processing /var/cache/apt/archives/libc6_2.7-8_i386.deb (--unpack):
> | subprocess new post-removal script returned error exit status 127
> | /bin/sh: relocation error: /lib/tls/libc.so.6: symbol _dl_out_of_memory, version GLIBC_PRIVATE not defined in file ld-linux.so.2 with link time reference
> | dpkg: error while cleaning up:
> | subprocess pre-installation script returned error exit status 127
> | Errors were encountered while processing:
> | /var/cache/apt/archives/libc6_2.7-8_i386.deb
> | E: Sub-process /usr/bin/dpkg returned an error code (1)
> `----
>
> I'm not sure whether it's a known issue currently (though I can't
> find an according bugreport) or if I've an upgrade path not
> supported at all right now - sorry for the noise then.
>
This is a problem that has been reported more than once, but it is
usually unreproducible. Basically it looks like dpkg fails to remove
/lib/tls/* during the upgrade, but we are unsure if it is actually a bug
in dpkg.
A quick workaround is to remove /lib/tls/* and then continue the upgrade.
If I understand correctly, you started from a clean chroot in base.tgz.
Are you able to reproduce the problem when starting again from the same
base.tgz? If yes, it would be nice if you can share this file so that we
can try to reproduce the problem locally.
--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' aurel32@debian.org | aurelien@aurel32.net
`- people.debian.org/~aurel32 | www.aurel32.net
Reply to: