Luckily there is a workaround. Go into the ‘edit settings’ screen for the Solaris guest and click the options tab. Change the Guest Operating System Version to Solaris 10 32 Bit, instead of 64 bit. Then the boot goes more like this:

I made a screen cast of the slow boot as well, but it literally is the same thing as above, except it just goes on for 5 minutes. It could be the most boring video on the internet. The fast boot video above is probably the second most boring video on the internet! It’s just a hard problem to explain in words.

This setting doesn’t mean that you’ll be running a 32 bit OS or anything either – as far as I can tell it doesn’t do anything besides fix the slow boot problem!

All this change has thrown up some new problems however. For each of the installs I was doing, the system would hang when trying to install DB2.

When there is a problem with the db2 install, the first place to go is the /tmp/db2setup.log. Inside that it seemed to be hanging on the instance creation step.

Looking through the output of ps -ef | grep db2, I saw a suspicious process called UpdateAutoRun.sh.

I couldn’t find a DB2 specific technote for this error, but a bit of searching brought up this one from Tivoli Monitoring (ITM). Apparently DB2 installs an instance of ITM along with DB2 – I’m not sure what it is for. Anyway, there seems to be a dodgy script inside the ITM that relies on the venerable text editor ‘ed’. Without ed installed the log file /itma/logs/UpdateAutoRun.log keeps filling up with the line:

Installing ed in (even while db2setup is running!) allows this script to finish and the rest of the install to complete successfully.

The first thing to do when debugging a WAS install problem is to look at the logs in ~/waslogs . These indicated the following problem:

My system had heaps of space on it! Surely the installer wouldn’t even run if there was 0 MB free! The method that the installer used to determine how much disk space was free was failing. But how does the installer figure out how much disk space is free? After lots of poking and prodding around I stumbled on dtrace. I had heard of it before, but never had the opportunity to use it. Dtrace is a mechanism to instrument and probe the tiniest little interactions on a Solaris/BSD/OSX machine. Being so powerful, it has a steep learning curve. This collection of handy dtrace oneliners was really helpful.

I kicked off the WAS install portion of the Portal install and ran this dtrace command in another window.

It captured each file interaction that occurred when running the install. Luckily the WAS install failed after about 30 seconds, so there wasn’t too much data to wade through.

Here is the dtrace log (trace.log from the command above). Something called gushellsupport.sh is calling df (standard unix disk free command). This must be how the installer determines how much disk space is free. The column on the left is the pid of the install process (which is java) . The library files on the far right are what is being called by each executable; the next column over to the left.

This script, gushellsupport.sh, is owned by InstallShield so I can’t publish the contents of it. But it has a diskcheck function in it that relies on ‘/usr/xpg4/bin/df’ which I didn’t have installed. Solaris has many different versions of the same tools that are left behind for backwards compatibility. When installing this system initially, I used the “Core System Support” option in the Solaris install to build a lean, quick machine. Unfortunately it didn’t come with this legacy version of df.

df belongs in a package called SUNWxcu4. To install it, mount your Solaris CD and go to the directory Solaris_10/Product/ . In there, copy the subdirectory ‘SUNWxcu4′ to /var/spool/pkg and run

If you rerun the install again it’ll work since gushellsupport.sh is calling the correct version of df. Talk about obscure huh?

But I had a problem connecting to it. It would load a java applet and then Java would die when initializing with the following error. I’m running the latest Sun Java 6 u16.

It’s about identical to this unsolved post at Ubuntu launchpad too. The certificates for a simple client JRE are stored in the cacerts file which lives in jre/lib/security/cacerts . It looks as if the root certificate for AOL is too long or recently updated or something and it’s not playing nicely with MetaFrame. So somehow we have to ditch that root cert. It would only really be a problem if we are unlucky enough to have our certificate signed by that root CA.

I assumed that MetaFrame worked on older jres and that the problem is that I am using a brand new one. So luckily Sun keep an archive of old JDKs and JREs here. So it is quite simple, download an install an old JRE (I got 5u1) and rip the cacerts file out of there and dump it into your new JRE’s directory and try it again. Worked like a charm for me. You probably don’t want to do this permanently (I guess they updated the cacerts file for a reason?) but if you really need to log into MetaFrame, it’ll do.

Well, I finally did it.  After months of thinking about it I’ve finally set up a tech blog to post solutions to problems I encounter during my day. I work at IBM (in System Verification Test) on a product called Lotus Web Content Management. Most of my job is devoted to setting up and configuring servers so other people can test upcoming versions of our product. There’s a pretty wide range of stuff I get to play with, so expect posts on Linux, Unix (HP/Solaris/AIX) , z/OS , z/VM, DB2, Oracle, SQL Server, LDAP (all different types) , and of course Websphere Portal and Lotus WCM (or just WCM; wick-em as we say around the lab).

Starting the blog is the easy part, of course. Now I just need to keep (or start, rather) posting to it.

Just trying to give back a little to the many other blogs and forum posts out there that have helped me overcome insurmountable problems. It’s really the least one can do.