I saw that on a one of my VM guests(ovms3.2.3) OL5.8.
So the problem for me was that the disk image was currupt. I needed to fschk the disk an validate / reinstall all rpm´s
that solve the problem. Check the md5 from the ld and compare with the file from the rpm
It probably means that your ls command is not the ls command it should be, perhaps copied from a 32-bit OS that requries a 32-bit version of the glibc library.
What is your output of the following command:
Thanks Dude. Here is the output you asked for:
$ file /bin/ls
/bin/ls: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.0.0, stripped
So I guess somehow it did get changed to 32 bit somewhere along the line. By the way, this server also had the jboss worm issue that you correctly pointed me to in another post. Could the worm have done something to mess with the libraries? I know ls was working after the machine was built. Now even ps is not working. Probably most basic commands are affected.
Now, how can we fix this? Do I need to copy the rpm for glibc and reinstall?
You can run most 32-bit applications under a x86_64 OS, provided the application is standalone or you have the required libraries installed. But the system is either x86 or x64 with appropriate core utilities and core libraries and you cannot use or install both x86 (i686) and x64 glibc. You are most likely in catch-22 situation and need to reinstall the system from scratch since tools you need to correct the issue are probably no longer working. This cannot happen when updating the system or using software management tools (yum or rpm) in a usual fashion. Perhaps it is the result of a manual copy or accidental restore of core system files such as /bin and /sbin from another system.