Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

Before stating the question, here's what I did and observed before the problem started:

  1. On a fedora 18 Xfce, I tried compiling 3.6.10 kernel with a cdv driver,
  2. After many attempts, it finally compiled without error, so I went ahead with make modules_install, and make install.
  3. Then I had to install couple of binaries from a few tarballs. Everything seemed fine till this moment. I could use firefox, vi in terminal, yum, rpm etc. commands.
  4. I installed binaries from few tarballs using tar xvf and a few files from these tarballs were moved to directories like /usr, /usr/lib. Even after this point, I remember using vi and rpm.
  5. Then finally I installed the last tarball using same tar xvf and it transferred few files to /lib, /lib/firmware etc.

After the 5th step above, without doing anything else, I just tried opening one file using vi command and got following error:

bash: /usr/bin/vi /lib/ld-linux.so.2: bad ELF interpreter: No such file or directory

I tried opening Firefox for solution, but it did not open. Fired few more commands from terminal but all the commands gave similar error. I checked few solutions that suggest installing glibc but neither yum works nor rpm. What might have gone wrong? How can it be fixed now when no command except cd is working, not even ls?

Meanwhile the only other hiccup that happened was that I had for kill Firefox somewhere in between since the machine wasn't responding very well and some plugin in it was eating up resources.

share|improve this question
    
After some looking into the file system using already running file browser, I found ld-linux.so.2 file in /usr/lib, just copied /usr/lib/ld-linux.so.2 and /usr/lib/ld-2.16.so files to /lib. And viola! the problem resolved, all the commands are back. I am not really sure what happened here, but my /lib was empty except for the files put up by the 'tar xvf'. I am yet to reboot and see what happens. But for now it is solved. Can anyone help me understand why /lib became empty or was it already so and what is the solution to avoid it? –  Rahul Jan 14 at 22:58
2  
First , Fedora 18 is now at end of life, so support is limited. Your problem is that you are not using the package manager to install and thus are deleting or over writing files. This is bad practice. See - fedoraproject.org/wiki/Package_management_system –  bodhi.zazen Jan 14 at 23:06
    
The reason I am doing this is to get the cedartrail powervr drivers working on a newer kernel. Intel has officially given a set of instructions but it refers to 3.1 kernel version. So for porting the driver to later kernel, I choose a mid-way kernel and followed the instructions. After many changes, the driver code is made suitable for 3.6.10 and compiles fine without any warnings. Problem is with the installation instructions given in the intel document where it says using make install for the kernel and few more tar archives for other libraries. –  Rahul Jan 15 at 10:11
    
I am not sure if rpm of equivalent libraries from intel are available. I also suspect using vanilla kernel on fedora system may not be a good idea and also there must be something missing in the make configurations that does not load /lib properly. After rebooting, I am not getting a blank screen with the installed kernel and if I remove the line 'video=lvds-1:d' it takes me to emergency mode with error messages like 'Failed to start Load kernel modules' and 'failed to initialize storage subsystem'. –  Rahul Jan 15 at 10:17
    
Wow, let this be a lesson to all who would blindly untar executables and libraries into OS critical directories. This is a recipe to bork your system. –  rickhg12hs Jan 15 at 16:30

3 Answers 3

A lot depends on what exactly you unpacked into your system. Generally, using tar to install things on a system with package management is a Bad Idea (TM). My guess would be you used a tarball for a different distribution or it didn't create properly some symbolic links. In other words I suppose the root of the problem might be the /usr - / merge. But lots of other things could have gone wrong.

share|improve this answer
2  
Indeed. Some time with rpm -V is probably warranted. –  derobert Jan 14 at 23:05

/lib/ld-linux.so.2 is the dynamic loader for dynamically-linked executables, which is almost all of them. Specifically, /lib/ld-linux.so.2 is the standard path for the dynamic loader on i386 (32-bit) systems. This file must exist and be valid (it can be a symbolic link), otherwise almost no program will be able to start (programs that are already running, such as your shell, aren't affected).

Try to recreate the dynamic loader. Hopefully you have it somewhere already, but in a wrong location. Look for it. Note that you can use echo * to list the contents of the current directory.

If you find the dynamic loader somewhere, you can use it to create a symbolic link in the right location. Say you find that /lib32/ld-linux.so.2 looks valid, then you can run

/lib32/ld-linux.so.2 ln -s /lib32/ld-linux.so.2 /lib/ld-linux.so.2

Plausible directories are /lib, /lib32, /usr/lib, /usr/lib32. Plausible names have the form ld-*.so.

Your system may still be broken in other ways but at least you'll be able to keep going. Note that you should never copy files manually inside /lib or /usr, except under /lib/modules and /usr/local.

share|improve this answer
    
Thanks. Almost everything came up after linking /usr/lib with /lib. But then, had to remove all the binary files installed through tarball and also reinstall few equivalent packages that provide similar libraries to get the system log in to graphical mode. Finally this system is up and running without problem, except that it still does not support the particular driver that I was trying to compile. Turns out that some of that driver depends on proprietary technology sources for which are not yet released by intel. PowerVR Graphics to be specific. –  Rahul Jan 16 at 18:06

The reason cd works is simply because it is an internal command of bash and not an external program. Other built-in commands like echo should work as well.

That at least explains why that works, but doesn't solve the problem of having trashed your external command setup. For that I would go for restoring from backup after booting from rescue partition (or CD if you don't have that).

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.