Over the past couple of weeks I’ve had the good fortune of finding a slew of various compact Sun “lunchbox” computers on eBay. While I’ll always be a #1 fan of the pizzabox form factor for UNIX machines, the lunchboxes are nice and compact and they stack neatly with a bunch of other Sun accessories (CD-ROMs, external hard disks, tape drives, etc.)

None of these machines were particularly very fast, but they were solid mid-range machines in their era.

* Unofficially, these machines can accept 128MB of RAM by using 16MB SIMMs in the first bank.

I have managed to get one of each of the above machines except for the ZX. This machine came with the rare/expensive ZX graphics card that even today sells for around $200 - the original price of the card alone was closer to $12,000. Other than the fancy graphics card these machines were otherwise identical to the SPARCstation LX.

The early machines (IPC, IPX) are from an era which suffered greatly from the capacitor plague problem of the early 90s. The two machines I have both needed extensive power supply service involving replacement of all the output filter capacitors. The later machines don’t have the same issue fortunately.

Additionally, machines of this age came with Seagate disks that time hasn’t been kind to. All of the disks in the machines I’ve received are in bad shape and I’ve removed most of them. I only have one SCSI2SD (they are kind of expensive) so the rest of the machines are limited to booting from the network. It’s not a terrible situation though, booting off the network is faster than you might think. I run a boot server on a Solaris 10 VM running on my main x86 workstation with SSD-backed disks, so performance is pretty good even though it’s getting throttled down to half-duplex 10Mbps on these machines. Local disks are still faster but diskless booting is way more reliable.

One of the main goals I had when I bought my SPARCstation IPC was to install SunOS 4.0.3c, the earliest supported OS on this system. The build date is 25 May 1989, which makes it the only 1980s UNIX any of my machines can run. Unfortunately, my IPC has slightly newer hardware than was available when 4.0.3c was released (it was originally targeted at the SPARCstation 1), and the newer SCSI controller causes errors with the version of the esp (Emulex SCSI) driver included.

This post details how I managed to install 4.0.3c onto my IPC starting with unpatched media.

According to Sun Patch ID #100204-01, there is a very simple mod to the SCSI driver that allows this older OS to work on the IPC (aka Sun 4/40). The problem is that the boot disk (MUNIX) uses this driver to to copy the miniroot to the disk, which in turn also contains its own unpatched kernel image, when then installs the distribution which contains an unpatched kernel, so some care has to be taken to patch kernels along the way. As noted in the patchnote, at least a patched tape 1 (which contains MUNIX and miniroot) was available from Sun, but I haven’t been able to track down an image or a physical tape of it.

The starting point for the install is the SunOS 4.0.3c 23-floppy distribution (readily available online). There are four boot/install floppies and 19 SunOS floppies in this set. The first floppy contains a 4.2BSD (aka FFS) filesystem containing the bootloader (boot.sun4c) and the MUNIX kernel (vmunix), along with a copyright notice. This disk also has the bootblock (blocks 1-15) populated so the boot PROM can load/run the bootloader. The second disk has the MUNIXFS filesystem on it that is copied into a special ramdisk device by the rd driver in the bootloader.

MUNIX exists only to allow one to run format to label disks and then to copy the installer miniroot image to the swap partition on the disk. The third and fourth floppies contain the miniroot filesystem, compressed (.Z) and split over two disks. The rest of the floppies contain the install distribution sets stored as compressed tar archives stored raw on the disks (no filesystem).

Standard 1.44MB floppy disks have 80 cylinders, 2 heads, and 18 tracks per block. The last cylinder (182512 bytes = 18kb) of each floppy contains a copyright notice, a table of contents and a volume indicator. The TOC is in a binary format called XDRTOC that details the volume number and distribution file names, offsets, lengths and formats.

The following will read the TOC off any of the SunOS floppy images (as run on a SunOS 4.1.4 machine):

phoenix% dd if=sunos_disk_1.img bs=512 skip=2848 count=31 | /usr/etc/install/xdrtoc
SunOS 4.0.3c 702-1080-10 Rev. A of Fri May 26 14:02:47 PDT 1989 from Sun Release Engineering
ARCH sun4c
VOLUME -1
 Vol File             Name       Size   Type
   0   -1           XDRTOC       4096   toc
   1    0             root      50996   tarZ
   1 51200              usr    8673675  tarZ
   6 1444352              Kvm    1203581        tarZ
   7 1191936          Install     580357        tarZ
   8 316416              Sys    1562532 tarZ
   9 422912       Networking     430105 tarZ
   9 853504        Debugging    1163963 tarZ
  10 561664    SunView_Users     660647 tarZ
  10 1222656 SunView_Programmers     739709     tarZ
  11 506368     SunView_Demo     224229 tarZ
  11 730624             Text     361971 tarZ
  11 1092608        User_Diag     691869        tarZ
  12 328704          SunCore     798787 tarZ
  12 1127936             uucp      91129        tarZ
  12 1219072         System_V    1962535        tarZ
  14 269824           Manual    2229955 tarZ
  15 1043968             Demo     851617        tarZ
  16 439808            Games    1605084 tarZ
  17 588800         Versatec    2392875 tarZ
  19 69632         Security      97371  tarZ

In the table it outputs, “Vol” is the floppy number, “File” is the byte offset of the start of the file on the disk, and “Size” is the total length of the file. The file start offsets are all aligned to 512-byte boundaries on the disks. Obviously a number of the files span disk boundaries; in this case each disk is read until the end, continuing at the beginning of the next disk until the entire length is read. In the above TOC we can see that ‘usr’ starts on disk 1 at byte 51200 and the next file doesn’t begin until byte 1444352 on disk 6. In this context, the “end” of the disk is the end of the 79th track (2844 512-byte blocks) - the 80th is always the copyright/toc/volheader, so care must be taken to skip the last track when trying to manually extract the tars from floppy images.

In order to apply the patch while installing the system from unpatched media, a disk with a working install of SunOS (e.g. 4.1.4) is necessary. In my case, the SunOS 4.1.4 disk is at SCSI ID# 3 and the target SunOS 4.0.3 disk is at SCSI ID# 2. The target disk must already be labeled (with format) prior to beginning this process. Make sure the a and b partitions (root and swap) are sized properly before continuing; they can’t be resized during the install process.

Because the MUNIX kernel on disk #1 is unpatched and won’t be able to properly copy the miniroot to disk, we need to bypass this by extracting the miniroot image with dd. The miniroot disks start with 4 blocks containing a copyright notice, another block which has a label with the volume letter and length (in bytes, in ASCII). We can use dd to read the lengths and use that to recreate our miniroot image:

phoenix% dd if=install_disk_c.img bs=512 skip=4 count=1
C 1472000
phoenix% dd if=install_disk_d.img bs=512 skip=4 count=1
D 1248982
phoenix% dd if=install_disk_C.img bs=1 skip=2560 count=1472000 > miniroot.img.Z
phoenix% dd if=install_disk_D.img bs=1 skip=2560 count=1248982 >> miniroot.img.Z
phoenix% uncompress miniroot.img.Z
phoenix% ls -l miniroot.img
-rw-rw-r--  1 taco      6152192 Aug 26 15:12 miniroot.img

Once the raw miniroot image has been obtained, write it to the swap partition on the target disk:

# dd if=miniroot.img of=/dev/rsd2b

Once the miniroot is copied, we can mount it as a filesystem and apply the patch:

# mkdir /miniroot
# mount /dev/sd2b /miniroot
# adb -w /miniroot/vmunix
esp_phasemanage+7c?W 1000000
^D
# umount /miniroot
# rmdir /miniroot

With the patch applied, reboot into the 4.0.3 miniroot:

# sync && fasthalt
ok boot sd(0,2,1) -sw

The miniroot should boot successfully, and running suninstall at the prompt will begin the install process. Pick [fd0] as the install source and be prepared when it prompts for the 19 floppy disks. When the install completes, however, you have a filesystem with an unpatched kernel on it. It will be necessary to patch the kernel before booting into the new system. Press STOP-A and get back to the PROM prompt and boot back into the 4.1.4 disk:

ok boot sd(0,0,0)

Then login and mount the 4.0.3 root filesystem, then mount the usr partition inside it to apply the patch:

# mkdir /a
# mount /dev/sd2a /a
# mount /dev/sd2g /a/usr
# adb -w /a/vmunix
esp_phasemanage+7c?W 1000000
^D
# adb -w /a/usr/sys/sun4c/OBJ/esp.o
esp_phasemanage+7c?W 1000000
^D
# umount /a/usr
# umount /a
# rmdir /a

This patches the GENERIC kernel that is installed by default plus the esp.o driver file in case you want to rebuild a custom kernel later. This completes the patching process, so you can shut down SunOS 4.1.4 and reboot into the 4.0.3c disk:

# sync && fasthalt
ok boot sd(0,2,0)

After all this, you should be met with a login prompt and a working SunOS 4.0.3c system. During boot the kernel complains about an unrecognized system ID in the PROM but this doesn’t appear to affect functionality. This OS is primitive by modern standards but it still has the ability to connect to a modern ethernet network and communicate via TCP/IP, mount remote filesystems via NFS, etc. DNS is another matter and will require some investigation. SunOS 4.0.3c has a proprietary windowing system included called SunView; there’s no OpenWindows or X11 here (it was sold separately and I haven’t been able to locate the tape for it).

That said, it’s still very much a BSD UNIX, includes a compiler and many older versions of familiar software will compile without a lot of hassle.

As a follow on to this, I’d like to attempt to build new install floppy images and possibly tape images to ease installation in the future. The floppy install should be easy, it’s just a matter of creating a new boot disk #A, new miniroot disks (C and D) and patching the Sys tarfile, then creating a new xdrtoc to place on all of the floppies. The tape may be a more complicated matter as I think the MUNIX and MUNIX root may be different on the tape than on the floppies. Also, it should be possible to fit the entire distribution on one QIC-150 tape since the OS originally came on two QIC-24 tapes, but a new xdrtoc needs to be created to indicate that to the installer.

I’ve been away from home for a while but when I’m home I definitely like to spend my off time working on my UNIX collection. I’ve had a few scares and disappointments when it comes to vintage hardware, it just comes with the territory. This stuff doesn’t last forever, especially the mechanical parts.

My SPARCstation IPC came with a Seagate ST1480N SCSI HD. It holds a whopping 426MB and it appeared to be working perfectly when I finally got the machine running. I installed an OS on it at least twice and had it running for several days without issue. After leaving it off for a week I came back to it and powered it on only to be met with an angry clicking noise a few seconds after power-up. It clicks loud and spins down immediately and doesn’t spin back up. I have heard some issues with old hard drives having rubber/plastic bump stops that become sticky over time that may cause this problem so I may crack this thing open and see if I can do anything, but for now it’s dead in the water.

To get around this I put my SCSI2SD into the machine instead of the HDD. I picked up an el cheapo 4GB microSD card at Fry’s for $5 and sectioned it off into 3 SCSI IDs:

• 2.1GB disk for SunOS 4.1.4 on SCSI ID 3
• 1.3GB disk for whatever on SCSI ID 1
• 535MB disk for SunOS 4.0.3c on SCSI ID 2

I removed the SCSI CD-ROM from one of my SPARCstation 20s and jerry-rigged it into one of my external SCSI enclosures and managed to install SunOS 4.1.4 onto the 2.1GB disk without a hitch.

One of the pieces of software I’ve wanted to check out for a while is Xerox GlobalView, which is basically the final resting place of the software originally developed for the Xerox Alto computer. They made several versions that ran on SunOS 4.x, so I installed version 1.0.5 on my IPC. This version claims to only run on SunOS 4.1.4. After I installed it I couldn’t get it to launch, and in a state of frustration I called it a night and shut down the machine.

In the morning I woke up and powered on the machine again but it refused to boot - no console, no power LED, no anything. Did I fry it?

I started removing hardware to isolate the problem. I removed the GX graphics card (which I swapped in the day before for the slow CG3 that came with it) and everything else connected to it. I plugged in the serial port to my Mac so I could see the PROM diagnostics. All I was getting was:

using nvramrc
Memory

and it just hung there indefinitely. Did I brick this machine inadvertently? Did I zap the RAM with static or something? I pulled half of the RAM, swapped RAM between banks, etc, and no change. Did all of the memory suddenly go bad?

It’s hard to know for sure, but I think installing GlobalView may have inserted some commands into the nvramrc which caused the problem. I know at minimum that the GlobalView installer recompiled a custom kernel, so I wouldn’t put it past it to insert a custom program into nvramrc. nvramrc is an optional set of Forth commands stored in the nvram which are run at boot, and it looks like whatever was in there was preventing the system from booting at all. Maybe GlobalView is not compatible with machines with an old PROM version like my IPC.

Eventually I found an article online that suggested an extreme workaround: pull the NVRAM chip from the mainboard and power on the machine, then carefully reinsert the chip while the machine is running and reset to defaults. This worked! Without the NVRAM chip it went into diagnostics mode, verified that all the hardware was working (except for the NVRAM of course), and dropped me to the normal PROM prompt. I carefully reinserted the NVRAM and ran set-defaults to program the default values into the PROM, then I followed the usual instructions to re-program the ethernet MAC and system type into the NVRAM. After a couple power cycles I confirmed that everything was operating properly again.

I reinstalled SunOS 4.1.4 completely to flush out whatever mistakes had been made and all seems to be working properly. Now that I’m back to where I started, on to the next challenge: installing SunOS 4.0.3c.