Discussion:
Bug#817960: libc6: relocation error version GLIBC_PRIVATE not defined in file libc.so.6
Chiraag Nataraj
2016-03-12 03:57:44 UTC
Permalink
Package: libc6
Version: 2.22-2
Severity: critical
Justification: breaks the whole system

Dear Maintainer,

When I upgrade from libc6 2.21-9 to 2.22-2, I get the error "relocation error version GLIBC_PRIVATE not defined in file libc.so.6" whenever I launch most programs (sed, grep, ls, etc.) and the program fails to start. This extends to booting up and so the system is unbootable.

-- System Information:
Debian Release: stretch/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.5.0-rc7-chiraag (SMP w/8 CPU cores; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Aurelien Jarno
2016-03-12 11:15:13 UTC
Permalink
Post by Chiraag Nataraj
Package: libc6
Version: 2.22-2
Severity: critical
Justification: breaks the whole system
Dear Maintainer,
When I upgrade from libc6 2.21-9 to 2.22-2, I get the error "relocation error version GLIBC_PRIVATE not defined in file libc.so.6" whenever I launch most programs (sed, grep, ls, etc.) and the program fails to start. This extends to booting up and so the system is unbootable.
Could you please give us the exact error message you encountered,
including the symbol name (a photo is fine), so that we can narrow down
the problem? At a first glance it looks like the libc has been partially
upgraded, and that you now have a mix of both 2.21 and 2.22.

Then we can instruct you how to fix your system, probably using
debian-installer in rescue mode.

Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
***@aurel32.net http://www.aurel32.net
ಚಿರಾಗ್ ನಟರಾಜ್
2016-03-12 13:53:12 UTC
Permalink
Post by Aurelien Jarno
Could you please give us the exact error message you encountered,
including the symbol name (a photo is fine), so that we can narrow down
the problem? At a first glance it looks like the libc has been partially
upgraded, and that you now have a mix of both 2.21 and 2.22.
Then we can instruct you how to fix your system, probably using
debian-installer in rescue mode.
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
I fixed my system by downloading 21.9 from snapshot.debian.org and
reinstalling libc6, libc6:i386, and all of the other packages
(libc-bin, libc6-dev, libc-dev-bin, locales) from a livecd.

Well then...when I upgrade within a virtual machine, everything's fine.
What is this witchcraft?!

- Chiraag
ಚಿರಾಗ್ ನಟರಾಜ್
2016-03-12 14:04:41 UTC
Permalink
Post by Aurelien Jarno
Could you please give us the exact error message you encountered,
including the symbol name (a photo is fine), so that we can narrow down
the problem? At a first glance it looks like the libc has been partially
upgraded, and that you now have a mix of both 2.21 and 2.22.
I have attached a screenshot of what I'm getting (I made a LVM
snapshot this time and tried to upgrade the snapshot so it didn't
hose my actual system). It conks out when it's processing
triggers for man-db.

- Chiraag
Aurelien Jarno
2016-03-12 15:50:17 UTC
Permalink
Post by ಚಿರಾಗ್ ನಟರಾಜ್
Post by Aurelien Jarno
Could you please give us the exact error message you encountered,
including the symbol name (a photo is fine), so that we can narrow down
the problem? At a first glance it looks like the libc has been partially
upgraded, and that you now have a mix of both 2.21 and 2.22.
I have attached a screenshot of what I'm getting (I made a LVM
snapshot this time and tried to upgrade the snapshot so it didn't
hose my actual system). It conks out when it's processing
triggers for man-db.
Thanks for your screenshot, it definitely helps. The symbol
***@GLIBC_PRIVATE has been renamed into ***@GLIBC_PRIVATE in
glibc 2.22.

Normally if you use both libpthread.so.0 and libc.so.6 from glibc 2.21
and glibc 2.22 everything should work. In your case it seems after the
upgrade you end up with libc.so.6 from glibc 2.21 (instead of 2.22)
while libpthread.so.0 is from glibc 2.22. It might be you have a copy if
libc.so.6 somewhere in the locations ld.so is search for.

Could you therefore please send me the output of "ldd /bin/ls" before
upgrading your system? That should give something like that:

linux-vdso.so.1 (0x00007ffe1013f000)
libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007f836df6f000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f836dbcb000)
libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f836d95a000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f836d756000)
/lib64/ld-linux-x86-64.so.2 (0x0000562bc2437000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f836d539000)

You should check if the libc.so.6 which is used is the one from
/lib/x86_64-linux-gnu or if another one is used.

Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
***@aurel32.net http://www.aurel32.net
ಚಿರಾಗ್ ನಟರಾಜ್
2016-03-12 15:59:45 UTC
Permalink
Post by Aurelien Jarno
Thanks for your screenshot, it definitely helps. The symbol
glibc 2.22.
Normally if you use both libpthread.so.0 and libc.so.6 from glibc 2.21
and glibc 2.22 everything should work. In your case it seems after the
upgrade you end up with libc.so.6 from glibc 2.21 (instead of 2.22)
while libpthread.so.0 is from glibc 2.22. It might be you have a copy if
libc.so.6 somewhere in the locations ld.so is search for.
Could you therefore please send me the output of "ldd /bin/ls" before
linux-vdso.so.1 (0x00007ffe1013f000)
libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007f836df6f000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f836dbcb000)
libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f836d95a000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f836d756000)
/lib64/ld-linux-x86-64.so.2 (0x0000562bc2437000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f836d539000)
You should check if the libc.so.6 which is used is the one from
/lib/x86_64-linux-gnu or if another one is used.
Oh damn...I don't know how this happened, but I had another libc.so.6 in
/lib/ (*not* /lib/x86_64-linux-gnu). I removed it and will try upgrading
in a snapshot so that if it still breaks I can always revert.

- Chiraag
ಚಿರಾಗ್ ನಟರಾಜ್
2016-03-12 16:21:08 UTC
Permalink
Post by Aurelien Jarno
Thanks for your screenshot, it definitely helps. The symbol
glibc 2.22.
Normally if you use both libpthread.so.0 and libc.so.6 from glibc 2.21
and glibc 2.22 everything should work. In your case it seems after the
upgrade you end up with libc.so.6 from glibc 2.21 (instead of 2.22)
while libpthread.so.0 is from glibc 2.22. It might be you have a copy if
libc.so.6 somewhere in the locations ld.so is search for.
Could you therefore please send me the output of "ldd /bin/ls" before
linux-vdso.so.1 (0x00007ffe1013f000)
libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007f836df6f000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f836dbcb000)
libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f836d95a000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f836d756000)
/lib64/ld-linux-x86-64.so.2 (0x0000562bc2437000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f836d539000)
You should check if the libc.so.6 which is used is the one from
/lib/x86_64-linux-gnu or if another one is used.
Looks like that fixed it!

Thank you so much!

- Chiraag

Loading...