eldergods.org » OpenSolaris

OpenIndiana 151a

mcclung — Mon, 10 Oct 2011 20:38:21 +0000

I’ve been having some problems with the OpenIndiana oi_148 to oi_151a update, but only on one virtual machine in particular. Until today i’ve been stuck, until I thought to:

pkg set-publisher --non-sticky opensolaris.org

After that, the image-update went fine. I need to learn more of the options for pkg, apparently. I had skipped that before because my other OI machines did not have that non-sticky option set, and the upgrade worked there.

Opensolaris zone fixes

mcclung — Fri, 24 Sep 2010 00:09:15 +0000

Whenever I create a zone on Solaris, I have a couple of things I always seem to have to fix beyond the usual configuration. Since I don’t do it that often, I have to look them up repeatedly, so I thought I’d just put them in this post and maybe that’ll help me remember and I can just look them up in one place.

First, I always need to change the permissions on /dev/ptmx. Before you change the permissions to 666 on this STREAMs master clone device, the shell won’t have any terminal control, so:

chmod 666 /dev/ptmx

Second, install SUNWuiu8 to get rid of an annoying message when you log in via ssh:

sshd[4860]: [ID 800047 auth.error] error: Can't convert to UTF-8: Cannot convert the local codeset strings to UTF-8

I think this is a missing dependency for SunSSH.

So,

pfexec pkg install SUNWuiu8

I’ll add more as I think about it.

EDIT:

Sure enough, even with OpenIndiana 151a, I still need to change permissions on the /dev/ptmx device file.
The SUNWuiu8 problem is gone, though. It appears to already be installed now.

root@nebula:/home/mcclung# pkg list system/library/iconv/utf-8
NAME (PUBLISHER) VERSION STATE UFOXI
system/library/iconv/utf-8 0.5.11-0.151.1 installed -----

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.