Recently, a friend contacted me about recovery of a Solaris box he had made a bit of a mistake on. The problem was, he had moved everything from / into a subdirectory of /, let’s call it /cores for our purposes here. Commands wouldn’t work. He had a running /sbin/sh shell but that was it…. so shell built-ins were all he could do e.g. “echo *”. We fixed it pretty quick, with only minor residual problems, but I thought I’d put down the method here in case it helps someone sometime.
The first problem is that libraries are no longer found along their proper paths…. libc.so is the first problem. That’s easily fixed, however.
# export LD_LIBRARY_PATH=/cores/usr/lib:/cores/lib
That’s the simple part, I’m sure most people know the LD_LIBRARY_PATH tricks to force searching for libraries in other directories. The part that I don’t think people get is… once you’ve done that “ld.so.1″ (the runtime linker) is still in the wrong place. ld.so.1 is responsible for using the LD_* variables in the first place, among the many other wonderful things it does. So running commands from, for example, /cores/usr/bin is still impossible, at least in the standard way.
The second and final trick you need to fix this is to use ld.so.1 to “run” the executable. So, this fails:
# /cores/usr/bin/mv /cores/* /
mv: Cannot find /usr/lib/ld.so.1
Killed
But this allows you to run a command like you’d expect:
/cores/usr/lib/ld.so.1 /cores/usr/bin/mv /cores/* /
Turns out, you can use “ld.so.1″ as an “interpreter” of sorts for executables on some flavors of Unix. At least Solaris and Linux, but I would not be surprised if this works elsewhere, I simply haven’t tested it. On Linux, for example, you would use something like:
/lib/ld-linux.so.2 /bin/ls
To run “ls” in this fashion.
The lesson, boys and girls, is to know your runtime linker, it may save you one day.