Turns out that selinux was enabled during the yum update since some of its packages were installed. As a result, it messed up some of the links. The solution was to disable selinux immediately after the yum update.
mingetty error while loading shared library libc.so.6
Question
I have a 64bit CentOS 5.5 box that I recently upgraded to 5.6. During the upgrade, I removed the unnecessary 32 bit packages (i*86 architecture packages) since they are not really valid for 64 bit machines. As well, I removed some other packages that were only needed for development machines.
Some of the 32 bit packages removed include:
glib2 glibc libgcc libstdc++
Some of the 64 bit packages removed include:
boost-devel cpp gcc gcc-c++
gdb glibc-devel glibc-headers libstdc++-devel
The following are some of the packages that remain:
# rpm -qa | grep libc
libcap-1.10-26
glibc-common-2.5-58.el5_6.4
glibc-2.5-58.el5_6.4
However, now I get the following error when I reboot:
/sbin/mingetty: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory
This log is repeated many times for each terminal, and then INIT pauses for 5 minutes because it is respawning too fast.
As a result, I cannot log into the console, but can still SSH to the box.
I have verified that libc.so.6 is present:
# ls -lrt /lib64/libc[\.-]*
-rwxr-xr-x 1 root root 1716720 Jun 27 2011 /lib64/libc-2.5.so
lrwxrwxrwx 1 root root 11 Sep 20 19:16 /lib64/libc.so.6 -> libc-2.5.so
And that mingetty is pointing to it:
ldd /sbin/mingetty
linux-vdso.so.1 => (0x00007fffb7ffc000)
libc.so.6 => /lib64/libc.so.6 (0x00002adf73cb2000)
/lib64/ld-linux-x86-64.so.2 (0x00002adf73a94000)
If I perform a fresh install of CentOS 5.6 with these same set of packages, everything works fine, so I suspect that the problem is a result of the removal scripts for some of these packages.
Does anyone know what might be going on?
Solution