eldergods.org » OpenSolaris

Solaris recovery

mcclung — Sun, 23 Mar 2008 23:15:38 +0000

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.

The results are in…

mcclung — Mon, 29 May 2006 19:02:29 +0000

With a full make clobber that it has to do on the source tree before it can start to compile, the OpenSolaris nightly build takes a long time:

(5) mcclung@dogstar: time nightly ./opensolaris.sh
40724.25u 7185.90s 15:02:27.12 88.4%

This is 5.11 svn_38. It’s faster in an untouched OpenSolaris tree, I think, I will have to test that as well. Even with all the other stuff I compiled for /usr/local during the first build, it only took 11-12 hours.

I’m assuming we’re still somewhat limited by the 650MHz CPU. I don’t think it’s using that much RAM, and I don’t see that we’re swapping (machine has 1GB of RAM.) The real limit is probably disk I/O, but I’ll have to verify that.

Welcome to OpenSolaris

mcclung — Sat, 27 May 2006 21:39:23 +0000

Recently, I bought a Sunblade 150 off of Ebay to experiment with OpenSolaris. I considered getting another PC specifically for this project, but eventually my nostalgia for Sun SPARC gear won out and I got it… it wasn’t even that expensive. I did end up replacing the RAM and adding a second IDE drive to it, which all seems to be working fine. I had earlier tried to get OpenSolaris working on a Sun Ultra 10 someone has on semi-permenent loan to me. With only 128MB of RAM it didn’t seem to want to boot SunOS 5.10 or 5.11 svn_16 (although it runs Gentoo just fine, if slowly). Between that and having a couple of 9GB drives in it, that wasn’t an ideal platform.

I’m hoping, as time goes on, to become more familiar with the internals of OpenSolaris. I had some exposure in a couple of classes, mostly the SunOS 5.5.1 device drivers class I took way back in 1996. If nothing else, this will give me more practice on Solaris features that became available in SunOS 5.10, such as Dtrace

My first project is to time the compile of the complete system using the nightly command. I timed it before, but it wasn’t a fair test because I was compiling several things at the same time, as sort of a stress test of the system after I replaced all the memory. I’ll post the results here.