Saturday, March 29, 2014

Solaris 7 x86

Introduction

A week ago I got Solaris 8 x86 working in VMware. This week, Solaris 7!

I would swear that Sun made Solaris 7 available for download way back because I'd swear that I had a copy of it at one time. But, I have no distinct memory of owning it, only a vague memory, and I can't seem to find any reference it it ever having been available for download on the whole internet. Hmm...

Maybe my memory is failing.

At any rate, it was eBay to the rescue, and I ended up getting an unusual package with both x86 and sparc versions. Maybe I'll be able to get the sparc version running under QEMU some day, but yesterday I was focused on the x86 version.

Installation

The Solaris 7 DVD isn't bootable, so I had to boot from the Device Configuration Assistant floppy. VMware didn't get along with the Solaris 7 install kernel any better than with the Solaris 8 install kernel, so I had to convert the iso to a vmdk and install from that, just like with Solaris 8.

To convert, I used qemu-img:

qemu-img convert solaris-7-x86-software.iso -O vmdk solaris-7-x86-software.vmdk

To install, I added a second hard disk to the VMware configuration, aimed it at that vmdk I just made, moved it to IDE 1:1 and made sure the CD/DVD was at IDE 1:0. Then, after booting to the floppy and stepping through a few of the prompts, I told the installer to install from that disk, rather than the CD.

[ ] DISK: Target 1:...

I left the CD/DVD attached though, even though I didn't use it to install, because VMware detects the OS type from the CD. I'm not sure how important that really is, but I figured it was better to do it than not.

Like the Solaris 8 installer, the Solaris 7 installer has a few quirks.

  • Sometimes it crashes right away with a BAD TRAP error. If you just let it reboot, sometimes it works, but sometimes it takes a few times before it will work. I never figured out what caused this.
  • Several times, it tries to get you to run kdmconfig. In each case, just select Bypass or Bypass&Suppress.
  • It doesn't ask for DNS info or a default route. You have to add it manually later.
  • The disk partition and filesystem configuration is just as quirky as on Solaris 8. You have to unselect and reselect c0d0 (c-zero-d-zero) or the installer will think that it has partitions defined even though it doesn't. Also, the default filesystem layout includes a small root and large /export/home and the editor for removing /export/home and resizing root isn't very intuitive.

But, hey, this is an os from the late 90's. I was happy that it installed at all.

And it did.

solaris 7 x86 - 1. installation

And eventually, I got a login.

solaris 7 x86 - 2. login

Post Install Tweaks

Post-install, I had a bit of work to do.

Network configuration was high on the list. I added a default route...

echo "192.168.123.254" > /etc/defaultrouter

...and added a DNS configuration to /etc/resolv.conf.

domainname firstworks.com
nameserver 192.168.123.37
search firstworks.com

(Note the odd "domainname" keyword vs. the more traditional "domain")

I also configured the /etc/nsswitch.conf so the system would actually pay attention to my fancy new resolv.conf file:

hosts: files dns

I also added a /export/home directory and created a user for myself.

mkdir /export/home
useradd -m -d /export/home/dmuse dmuse
passwd dmuse

Like on 8, you have to supply the -d parameter even though /export/home is the default location for home directories.

I also added some useful paths to PATH in /etc/profile.

PATH=$PATH:/usr/ccs/bin:/usr/ucb:/usr/openwin/bin:/usr/openwin/demo:/usr/dt/bin
...
export LOGNAME PATH

There's probably some easy way to restart the network, but I just rebooted and when it came back up, I could telnet in with my new login.

Telnet kind of sucks though. I'd much rather use ssh, but I was a little short on software. Solaris 8 came with a companion CD but I had no such CD for Solaris 7. Googling for Solaris 7 x86 software didn't turn up anything. Well... nothing easy to install at least. I could build software from source, but the C compiler in /usr/ucb required a license that I didn't have. If I could find a copy of gcc, I'd be in business, but I couldn't even find that.

It was the classic bootstrapping, chicken-egg problem.

Eventually it occurred to me that I might be able to build a compiler on my Solaris 8 system, that could run on and target Solaris 7. I downloaded the source for gcc-2.95.3 on my Solaris 8 VM, fiddled around a bit, and voila, it worked!

Running this on Solaris 8...

./configure --prefix=/usr/local/gcc-2.95.3 --host=i386-pc-solaris2.7 --target=i386-pc-solaris2.7 --enable-shared
gmake
gmake install

...resulted in a tree under /usr/local/gcc-2.95.3 that I could tar up and ftp to solaris 7 and untar in /usr/local. After adding /usr/local/gcc-2.95.3/bin to my PATH, I had a working compiler!

Woohoo!

I used it to build gzip-1.3.12 and then rebuild itself. I installed them under /opt/sfw (which appears to be where "companion" software likes to go). I also built and installed bash-1.14.7 and sudo-1.6.9p23.

After adding /opt/sfw/bin to everybody's PATH, the system started to feel kind-of usable, but I still wanted to be able to ssh in.

Remote Access

Now that I had gcc, I could build openssh. It wasn't trivial though.

I ended up having to build and install perl-5.003_07, openssl-0.9.6h and zlib-1.2.8 first. I didn't have trouble with them but openssh-2.9p2 took a little coaxing.

After configuration...

./configure --prefix=/opt/sfw

I had to edit config.h and replace line 13 with:

#define GETPGRP_VOID 1

and edit openbsd-compat/bsd-snprintf.c and comment out line 58:

/*# undef HAVE_VSNPRINTF*/

Then I could build and install.

make
make install

To run the server at boot, I created /etc/init.d/sshd

#!/bin/sh

case "$1" in
  start)
        /opt/sfw/sbin/sshd
        ;;
  stop)
        killall sshd
        ;;
  *)
        echo $"Usage: $0 {start|stop}"
        exit 1
esac

exit 0

And configured it to start.

chmod 755 /etc/init.d/sshd cd /etc/rc3.d ln -s ../init.d/sshd S90sshd

And enabled X Forwarding in /opt/sfw/etc/sshd_config.

X11Forwarding yes

It appeared to work, and after a reboot, just to make sure it would start on boot, I was able to ssh in.

solaris 7 x86 - 3. ssh

scp worked too.

Ok, NOW the system felt usable.

The Web

I poked around a bit but I couldn't find anything resembling a web server in the base installation. Apache 2.0.65 build and installed cleanly under /opt/sfw though and after a few tweaks to the config file, the "It worked" page came up and I was even able to run a few simple cgi's.

The trickiest part of the apache configuration was setting the group to run as. By default, it uses #-1. On most systems, group id's are 16-bit, -1 translates to 2^16-2, and the "nobody" group has that group id. Apparently, on Solaris, group id's are 32-bit, "nobody" has an id like 60001, and it couldn't make any sense of #-1. This fixed it:

#Group #-1
Group nobody

Easy to fix. Tricky to diagnose.

I added an init script for it too, at /etc/init.d/httpd:

#!/bin/sh

case "$1" in
  start)
        /opt/sfw/bin/apachectl start
        ;;
  stop)
        /opt/sfw/bin/apachectl stop
        ;;
  *)
        echo $"Usage: $0 {start|stop}"
        exit 1
esac

exit 0

And configured it to start at boot:

chmod 755 /etc/init.d/httpd
cd /etc/rc3.d
ln -s ../init.d/httpd S90httpd

On the client side, I couldn't find anything resembling a browser at first, but I eventually discovered HotJava. Unfortunately, it struggled pretty badly with just about any web site I pointed it at.

The web provided Netscape 4.78 for Solaris 2.5.1 x86. Aside from supporting PNG's, it didn't work all that much better.

solaris 7 x86 - 4. netscape

lynx-2.8.7 and wget-1.5.2 both built cleanly from source though.

Good old, reliable lynx.

Graphics

The Xsun server that comes with Solaris 7 doesn't support SVGA, so the best you can do with it is 640x480 at 16 colors. To me, monochrome always seems more usable than 16 colors, but there's no obvious way to configure Xsun for monochrome.

For Solaris 8 and 9, there are driver packages available that add SVGA support, but not for Solaris 7. I tried several things, but I was eventually able to install XFree86 4.7.0 and get it working.

I basically downloaded everything from http://ftp.xfree86.org/pub/XFree86/4.7.0/binaries/Solaris and ran:

sudo sh Xinstall.sh

The prompts were fairly intuitive.

I then added /usr/X11R6/bin ahead of everything else in everybody's PATH and /usr/X11R6/lib ahead of everything else in everybody's LD_LIBRARY_PATH.

Just running X -autoconfig sort-of worked, but really worked too well. It configured itself to 1024x768 which was cumbersome to use on my screen. Tuning it down required a little work. I had to run x86config and that brought back bad memories. It wasn't so bad this time though. The important bits for me were:

  • Mouse protocol: Auto
  • Monitor: 31.5 - 35.1; Super VGA, 800x600 @ 56 Hz
  • Vertical sync range: 40-150
  • Yes, look at a card database
  • Card: Generic VESA compatible
  • Video memory: 1024K
  • Color depth by default: 16 bits (65536 colors)

The server still had issues with the mouse though. The configurator defaults to /dev/mouse. I had no idea what the mouse device actually was, and nothing in /dev looked mouse-ish. The mouse worked in autoconfig mode, so I knew it was possible to get it to work. It turned out, all I had to do was edit the XF86Config file manually and just comment out the mouse device line:

#Option "Device" "/dev/mouse"

Woohoo, CDE!

solaris 7 x86 - 5. cde

To get that running, I had to create a ~/.xinitrc with:

/usr/dt/bin/Xsession

And run xinit.

Getting openlook to run was trickier. It really likes to run the Xsun server, so I had to swap that with the XFree86 server:

cd /usr/openwin/bin sudo mv Xsun Xsun.old ln -s /usr/X11R6/bin/X Xsun

I also had to remove my .xinitrc. But after that, running openwin worked:

solaris 7 x86 - 6. openlook

Well, sort-of.

It complained about a lack of display postscript. No idea how to get that working, if it's even possible.

Starting a graphical login was a little more difficult. dtlogin likes to run Xsun too, with arguments that XFree86 doesn't understand. Replacing the Xsun link with this script seemed to solve the problem:

#!/bin/sh

ARGS=`echo $@ | sed -e "s|-nobanner||g"`

/usr/X11R6/bin/X $ARGS

After that, I could enable dtlogin:

sudo dtconfig -e

And after a reboot, it worked.

Well.. again... sort-of. For some reason, I couldn't exit a CDE session without hitting ctrl-alt-backspace.

Ahh, who knows? It wasn't worth figuring out. I didn't plan on running dtlogin anyway, so I disabled it:

sudo dtconfig -d

Development

I had gcc working, but I needed a few other tools to be able to compile my software. Fortunately I didn't have any trouble building or installing cvs-1.11.23, gnu make-3.82, gnu tar-1.13, or vim-7.4 from source. It was as simple as configure, make and make install. I made symlinks from make to gmake and tar to gtar too, just for good measure.

I couldn't get modern-ish versions of postgresql, mysql, sqlite or even freetds to compile though. Actually, freetds compiled but the install script left files out. Who knows? I'll have to look into that later.

I had to disable openssl support because openssl only built static libraries, but other than that, Rudiments built cleanly. SQL Relay had trouble with Perl, and aside from not having any database API's to compile against, built fine.

Obligatory screen shot of being able to access Oracle:

solaris 7 x86 - 7. sqlrsh

I did have trouble with CVS hanging while accessing my local server for some reason, but it had no trouble with sourceforge. I'm not sure why. Man, I need to migrate to GIT or something though. Just typing "CVS" makes me feel old.

Quirks

Or maybe I should call them "endearing features"...

  • You have to use the Delete key rather than Backspace on the console.
  • The default shell doesn't understand ~/ but does understand $HOME.
  • Filesystem performance is not so good, untarring and rm -rf'ing take a while.
  • Setting the domain in /etc/resolv.conf uses the domainname keyword rather than domain.
  • Still though, rpckeygen and sendmail don't know the domain name is, and there's no obvious reason why.
  • The command line ftp client is in text mode by default but REPORTS binary and corrupts files unless you explicitly set it to binary mode before downloading.

It turns out Solaris 8 has that same ftp problem. I kept downloading files and getting CRC errors gunzipping them. It took a while to figure out why.

The most significant quirk though is that VMware doesn't detect the Solaris 7 idle loop and it makes the host CPU run at 100%. Electricity isn't free. I wonder if there's anything that can be done about that. VMware detects "Solaris 7" during installation, and sets the Guest Operating System type to "Solaris 10". I tried switching it to 8, but doing that rendered the system unbootable. Worse, it appeared to corrupt something because after setting it back, the system was still unbootable! I ended up having to reinstall completely to get it to work again. There might be some solution there, but I'm kind-of scared to try again.

So, alas, I can't put my shiny new Solaris 7 system in my build farm.

Oh well, I guess you can't win 'em all.

No comments:

Post a Comment