We installed Oracle Linux release 6 update 2 for X86_64 on a virtual machine. After the machine was built, everything
was ok. After a few days, the ls command produces the following error:
-bash: /bin/ls: /lib/ld-linux.so.2: bad ELF interpreter: No such file or directory
So far the only thing turning up in searches is the problem is related to 64 bit vs 32 bit libraries being installed. The strange thing in this case is that nothing was done to the server between the time the ls worked and the time it stopped working. Nothing installed, no changes made. Could the system have dome some automatic update and installed a wrong version of a library? The machine has been built 3 times, and in each case this has happened. A few days after being built, ls stops working with the above error. Has anyone experienced this?
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
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.