koko: sustaining Dell UNIX
“Genghis Khan and his brother Don
Could not keep on keepin’ on”
(1971) “You Ain’t Goin’ Nowhere” – Bob Dylan
[update December 2020: Dell Unix on 86Box “Today let me present Dell Unix more properly, with 1024×768, 256 colors video and proper networking using emulated VGA and NIC.”]
Dell UNIX originally ran on hardware from almost 30 years ago, with almost all peripherals dependent on the (now long defunct) ISA bus. Though such hardware is still available on eBay, from recyclers and others, the door is closing on sustaining Dell UNIX on bare metal. Thanks to Antoni Sawicki’s Qemu/Bochs & Virtual Box efforts, perpetuating Dell Unix on virtual machines is much more practical. However, SLIP will never cut it for network access when even 10BaseT seems painfully slow. For several years I’ve been intending to try to get an Ethernet driver for a card supported by Virtual Box emulation, probably an AMD Am79c970.
Though I was the leader of Dell UNIX efforts, I never was involved in builds or device drivers. The last time I did anything substantive with device drivers was over 30 years ago, for Roland MPU-401 support for BSD 4.3 for RT/PC. (The MPU-401 was once the most important MIDI controller and lives on in emulated form in modern MIDI interfaces.)
Adding a device driver shouldn’t require building the entire system, but since no one has been building Dell SVR4 for years, I thought I would try to do a complete build first.
“UNIX” on SmartVU on 450 DE/2 DGX JAWS
Previously, I’d mostly used Dell SVR4 on my pre-production JAWS instance of the 450 DE/2 DGX. It seemed imperative to figure out how to do things on more generic hardware. It also seemed plausible to use most any PC with the supported SCSI and Ethernet controllers.
So I put SVR4 on a 1999 Dell Optiplex GX1 with Adaptec 1542 SCSI and SMC 8013 10BaseT. (I’d like to use newer IDE/PATA drives, with larger capacity than the SCSI drives I’m using, but the system firmware doesn’t seem to support anything larger than 504M, and even operating systems like Dell UNIX that don’t use BIOS still seem to get geometry information that the firmware stores in non-volatile memory.)
Even though I have the source, I realized that install didn’t have critical binaries that the build scripts need, particularly RCS co (check out). And, at first glance neither did the JAWS machine. Fortunately, in 1993 I’d made a comprehensive tape backup of my SVR4 machines and in 2003 I’d made a convenient disk copy of that tape, and preserved that copy as well as the tape. Not only was I able to get all sorts of missing binaries from the tape image files, I was also able to find configuration settings for X on JAWS, etc.
About this time, I urgently needed to repurpose the power supply in the GX1. I used to have many similar machines but had pruned inventory to my first GX1 and my first Optiplex GX110. Last year I loaned the GX110 to a client attorney. As he was preparing for a deposition, the GX110 power supply failed so I substituted the GX1 supply in the GX110. I paused the Dell SVR4 efforts as a result. I’m still paused — the replacement supply I ordered was defective and I’m waiting on another replacement.
Update July 16, 2019: After getting timbl’s browser working as well as it is likely to (https://notes.technologists.com/notes/2019/07/01/koko-reviving-timbls-worldwideweb-browser/), it seemed time to get back to Dell SVR4.
Previously, I’d tried to use NFS exports from Fedora 1 to provide the rcs repositories that the build script assumes are on various file servers. However, I couldn’t get write access for SVR4 with those exports — still don’t know why. In any case, NFS across 10BaseT seemed likely to be slower than the 9G disks I have (IBM DCHS-09F Ultrastar 2XP https://www.cnet.com/products/ibm-ultrastar-2xp-hard-drive-9-11-gb-fast-scsi/).
The main efforts were changing the build script to use appropriate local paths instead of the NFS paths, and eliminating a few rlogin and rsh instances. It wasn’t hard to get a grasp of the process — I assume Kendall and DonnB were responsible for making it understandable without documentation.
After a few false starts, I started a build Saturday night that completed roughly 12 hours later Sunday morning. (This is on an Optiplex GX1, 450MHz Pentium II with 768M memory.) There was one rsh instance I’d missed, but doing the local equivalent after the build seemed likely sufficient. However, I didn’t really know what to look for in terms of positive results — lack of fatal errors was encouraging but not persuasive.
I found a cpio archive that seemed like it was the primary install image, that I could put on DAT and try to install that way. However, if that wasn’t the right image, or if there had been unknown problems in the build, I was averse to repeatedly creating tapes and trying tape installs.
I’d never tried a network install, but I assume that most people actively working on SVR4 at Dell primarily used network install. The terminology of “code server” and other things unexplained seemed a little daunting, but I surmised that probably all that is needed is getting the install process to find the cpio archive on an NFS export. That turned out to be true. Again, I’m thankful that the process is understandable without documentation.
After one attempt failed because of disk errors and another failed because I’d omitted a path component, the next network install succeeded quickly. Up until now what I’ve been using is “issue 2.2”, but what was built is the final issue, 2.2.1, so the banners are slightly different and there is a little more info presented about device addresses and IRQs. Cursory testing has been positive, so for now I’m assuming all is OK.
Now it seems time to try to focus on adding an Ethernet driver that makes sense with VirtualBox. If I can get that working and included for the network install process, then installing and using Dell SVR4 on VirtualBox should finally be useful.
You must be logged in to post a comment.