Installing Solaris 8 in VirtualBox

Preamble – Why on Earth…?
Before we start, I guess I should explain why the heck I wanted to do this… I have a smallish set of self-developed libraries, utility and server software developed in C (C89 of course, none of this modern rubbish like automatic VLAs, complex numbers, etc) which is highly portable (covering targets from DOS, Win32, SunOS, Solaris, AIX, NetBSD/FreeBSD/OpenBSD, VMS, Irix, Ultrix, BeOS, Linux, et al – on all CPUs supported by those systems). Building binary distributions for that lot could be a royal nuisance, so I thought that creating a virtualised build farm would allow me to script a “most targets” build run from a single pushbutton.

Solaris 10 and 11 use the “Image Packaging System” (IPS) as their native packaging format, but for small simple self-contained packages that is massive overkill. Fortunately, they still support the older SVR4 “pkgadd” format which allows a (careful) build on an older Solaris to also be suitable for newer Solarii. Also, SVR4 packaging has better “relocatable” support – allowing the local system admin to decide exactly where to install, and which exact pieces they need. As you might have guessed, I’m not sold on IPS yet.

So, a virtualised networked Solaris 8 x86 can provide binary packages suitable for Solaris 8, 9, 10, 11 and OpenSolaris. Not bad.

Solaris 8 Licensing:

Why not go the whole hog and use Solaris 2.5? Unfortunately, that would require an explicit licence from Oracle, and I do not have the install media. Solaris 8 was for a while offered under a free-to-use licence for single-processor systems, and I have the install media for it, downloaded in January 2001 whilst that licence was in effect (the free-to-use licence was withdrawn in late 2001). This is Solaris 8 Update 3. Bear in mind that the (final) Solaris 8 Update 7 is not available under a free-to-use licence.

One possible problem with that licence is that it did not cover virtualised hardware or multi-core single-socket CPUs – because there were none at that time. How does it cover running on a single virtual CPU hosted by a multi-socketed multi-CPU system? Or even more difficult, a single virtual CPU hosted on a single-socket multi-core CPU (Core 2 Duo E6600)? I makes my head hurt just thinking about it.

Difficult Days – The Device Configuration Assistant:
Back in the day, installing Solaris on real PC hardware could be a bit of a journey, due to somewhat variable hardware capabilities and hardware bugs and undocumented “limitations”. Thus the Solaris installation-boot process started in 16-bit real-mode, running DOS-like programs to setup a basic workable in-memory environment to be able to run a mini-Solaris that could complete the installation of real Solaris software. Some PCs of the time could not even boot from CD. Thus Solaris also came with a DOS-mode bootable diskette called the Device-Configuration Assistant that setup a CD-enabled in-memory environment beforehand.

VirtualBox Emulated-Hardware Settings:
So now to VirtualBox. You need to pick VM settings that represent late-90s PC hardware and available Solaris drivers: VM OS-type = Other/Unknown, PAE=off, IO-APIC=off, network card = AMD PCnet-III, main memory between 128Mb and 256Mb, hard-disk controller = IDE, hard-disk as primary master, CDROM as secondary master (not primary slave). As a precaution, I also chose Audio = disabled and USB = disabled, as I will not be needing them.

Booting the Wrong Way:
At first I thought I should use the x86 DCA diskette-boot method, using a diskette-image file (carefully prepared on my SPARCstation-10 – which at least has a diskette drive!). The diskette-boot method just would not work, no matter which variations I tried – always got the fatal error-message “could not read fdisk table”.
I even installed a temporary OpenSolaris VM (that’s a whole other story) just so I could put an FDISK table on the hard-disk image I was going to use for Solaris 8 – no joy, same error.

Booting the Right Way:
After a couple of days, I remembered that as VirtualBox can boot direct from CD, perhaps I should do that – doh! This was much better, now I got the DCA menus. However, I could not get the secondary boot from CD (which launches the mini-Solaris) at all – it just errored hard every time. It turned out that you need to enable the VirtualBox “passthrough” option on the virtual CD drive, because the mini-Solaris kernel issues direct ATAPI commands to the drive (to set 512-byte block-mode etc) – which VirtualBox does not emulate itself.

Success at last? Not quite… a detour into DMA settings:
So now the secondary boot worked, a Solaris kernel started and ran – up to the point where the traditional Solaris “Configuring /devices and /dev” process executes. Nothing at all seemed to be hapenning for quite a while, then eventually console error messages appeared – “timeout: reset bus, target=0, lun=0”, referring to the virtual hard-disk. It seemed that each 512-byte block was taking over 2 minutes to transfer – about the speed of a 1920s paper-tape reader! How the heck can a super-fast virtual disk-drive be causing bus timeouts? It turned out to be an unfortunate interaction between the VirtualBox IDE controller and the Solaris “ata” driver. Due to common broken PCI-IDE DMA hardware back in 1999, Solaris 8 by default disables DMA for PCI IDE controllers, reverting to PIO-mode transfers. Unfortunately, PIO-mode as implemented by the Solaris “ata” driver relies on accurate high-precision timing delays which the VirtualBox environment does not emulate with sufficient accuracy. The solution was to reboot, and in the DCA menus, take a detour to enable the “ata-dma” device-property.

Strangely, this is the exact opposite problem and solution that I encountered when installing Solaris 8 on a (real) Toshiba Satellite Pro 4000CDT: on that system the PCI IDE controller locks a huge area of physical memory (much larger than the transfer size) during DMA transfers, and thus if PCI IDE DMA is enabled, blocks CPU access to large portions of memory for quite a while, thus giving a very stuttering behaviour – mouse jumping, screen-shear, very slow keyboard response, and so on. For that particular hardware there are two choices: either disable the Solaris ata-dma property (so forcing PIO mode), or selecting to use the ISA IDE controller instead of PCI IDE controller… it is the same controller chip, but is “dual-ported” – appearing as two separate controllers, one accessed by ISA bus, the other directly by PCI. Wierd hardware! Presumably Toshiba did this so that operating-system software that did not support PCI could still be used…? On the Satellite using ISA IDE in DMA mode worked flawlessly and plenty quick enough.

Display Wrinkles:
When configuring the windowing system during install, Solaris 8 gives you a choice of a wide range of specific display-adaptor hardware, but not any generic VESA BIOS adaptor. Because VirtualBox does not emulate any of the specific display adaptors that Solaris 8 installer provides, you have to select the “basic VGA 640×480 16-colour” option. For myself, console access or remote X display access is sufficient, but for desktop use, the only option is to install the separate add-on “Xfree86 Driver Pack” for Solaris 8, which includes VESA drivers (I had to do this on the Satellite laptop as well, just to get 800×600 resolution). I still have that add-on package around somewhere.

Choosing Software to Install:
Back to VirtualBox – now the Solaris installer proper was up and running and working fine. Because I needed the Solaris header-files installed – to be able to build software on the system – I chose the “End User Plus Developer” cluster of packages to install. If I had picked the runtime-only “End User” cluster, then we would be finished, but some of the developer software packages are on the second CD, which leads us into…

It Gets Worse:
If you have selected software components that actually reside on the second CD, this causes a major problem: after the reboot, Solaris notices that some packages have still not been installed yet, and launches the graphical Java-based “Web Start Installer” to complete the process. Unfortunately, the Web Start Installer will not display properly in only 16 colours – in particular the “Next” buttons do not display, nor do the yes/no checkboxes, none of the textual labels and prompts are shown, and so on. So it is impossible to complete the installation, of even login to the system. Because it is an AWT-based Java-1 program, there are no keyboard shortcuts available either.

Given that the installer already knows what you asked for (from the stage 1 install – it records these on the hard-disk so that it knows what still needs doing), it is just darned silly that (1) a heavyweight graphical “just press the Next button several times” installation program is deemed necessary, (2) it provides no way to escape to a login prompt and rerun later, and (3) its “Web Start Installer” name gratuitously implies that it is HTTP or World-Wide-Web-based, or at least network-sensitive – when in fact it is nothing of the sort – it is a Java application that does not use the network or even care if one exists. That one has irritated me for years.

My initial thought was that if there was no working X configuration, that the Web Start Installer must fail and system boot could continue – so that I could install the necessary Xsun driver to get a 16-bit or 24-bit display. Unfortunately, this is a not an option. If Web Start Installer cannot start, it insists on rebooting the system immediately with no escape (but with an explanatory message – GRRR!).

So we have a problem of infinite regress – infinite reboots with no progress. The only way out of this is to resort to extreme deviousness: during the reboot select “single-user” mode, to get a shell-prompt. You then need to edit the file /etc/init.d/webstart, changing the line “CLI=” to read “CLI=yes”, save the file, and (sigh) reboot.

That change tells the damned Web Start Installer to run without any graphics at all, fancy or otherwise – just a ticking progress bar on the text console. Given that it can do that, why does the graphical version insist on forcing a reboot when it cannot initialise the display? Sure lt it should just fall back to the text-mode method immediately? Idiots.

For myself, console access or remote X display access is sufficient, but for desktop use, the only option is to install the separate add-on “Xfree86 Driver Pack” for Solaris 8, which includes VESA drivers (I had to do this on the Satellite laptop as well, just to get 800×600 resolution). I still have that add-on package around somewhere.

Final Thoughts:

Well, it works, complete with networking, but it was a bit more of a journey than I wanted. As part of a “buildbot” network, it is pretty good – very low resource requirements, and very fast (even when hosted on an Atom netbook), much much faster than newer Solarii and modern Linuxen.

I have exported this VM as a VirtualBox appliance, so that I can reset to the current state should I screw the installation up in future!