3

I've been using centos 6.5. And after I used the yum to update my glibc.

yum update glibc

I found that my "yum" command as well as my "python" command will throw error as follows: enter image description here

I' ve tired other shell commands like: ls ll ln rm mv etc. Those commands are working normally. When I check my libc link, the result are as follows: enter image description here

Additionally, I have tried to print my libz config using

ldconfig -v|grep libz

The result will be as follows: enter image description here

I was wondering why this may happen. And I really need your guys help to solve this problem.

What's more, my 'gdb' will throw this error too. When I use 'dmesg' command, I got the message as follows: enter image description here

sweetstar86
  • 96
  • 1
  • 6

1 Answers1

2

CentOS 6 is based on glibc 2.12. The symbolic link points to glibc 2.16, so you tried to install a glibc package which is not part of the operating system. This has corrupted the system, likely beyond repair. You will jave to reinstall it and restore the data from backup.

Avoid reinstallation is a complex operation. You need to make sure that you still have all the files for glibc 2.12 (with names ending in -2.12.so). Then you can delete the glibc 2.16 files (those ending in -2.16.so), with a single rm invocation. (The single rm invocation is necessary because rm will stop working once you start deleting the glibc 2.16 files.) After that, you can run ldconfig to get back the right symbolic links.

You could also try to use sln or ln -sf to fix the symbolic links manually, but you will have to remove the glibc 2.16 files at one point. Until you do the latter, every ldconfig invocation will bring back the glibc 2.16 symbolic links. And ldconfig is run automatically during package installation, so this can happen quite easily by accident.

Florian Weimer
  • 32,022
  • 3
  • 48
  • 92
  • but 2.12 so files still exists. how can i change all symbolic link to 2.12? – sweetstar86 Sep 29 '18 at 09:02
  • @sweetstar86 I added some notes to my answer. – Florian Weimer Oct 05 '18 at 07:27
  • Thank you for all your advice. Now the shell will go normally. But I happen to find that my **libcap.so.2** is now link to **libcap.so.2.16**. And my **lib64** directory only contains **libcap.so.1.10** and **libcap.so.2.16**. – sweetstar86 Oct 08 '18 at 07:18
  • 1
    libcap is unrelated, it's not part of glibc. It could even be normal that you have both versions installed because the have different sonames. This is different for glibc, where all versions have `libc.so.6` as the soname and therefore conflict. – Florian Weimer Oct 08 '18 at 07:40