eldergods.org

So awhile ago, I got greedy and tried to install a 400GB IDE drive in a Sunblade 150 I’d got for cheap. Those of you who are more familiar with that hardware than I was (or am, really), will already be laughing at what a stupid idea that was. For those of you who don’t know, it can only address about 138GB per drive. The math is out there, but basically it’s a limitation of the IDE controller… and doesn’t apply to SCSI and FC drives in any of the Sun boxes, which is probably why this never occurred to me.

So… I backed off that plan and installed a pair of 120GB drives.  Now the system won’t boot.  And the console is, shall we say, unresponsive. I live a charmed life, I tell ya.

As a result, I have since collected a couple of other old Sun workstations via Ebay and the employee purchase program at work (which are basically “worthless”, like $65), and even an old Pentium 4 for Solaris x86.   So I’ve got the gear, but I haven’t had time to continue with any but the most cursory examinations of OpenSolaris.   I got 2 of them booted up with ZFS root on fairly recent versions of Nevada.   Waiting for the SPARC release of Indiana to be readily available.

In the meantime, I thought I might work on some of my other Solaris related projects.

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.