On the Internets, one may find a package labeled as SCO XENIX 386 version 2.2.3 or similar, sometimes mislabeled as version 2.2.2. This is one of the very oldest operating systems designed for 386-based PC compatibles, released around June 1988 (years before 32-bit OS/2 and Windows NT, or Linux and 386BSD for that matter; note that the first release of XENIX 386 probably happened sometime around mid-1987). Based on AT&T’s System V Release 3.2, it’s also one of the hardest operating systems to get running, for several reasons.
The core operating system (the ‘N’ floppies) is version 2.2.3c, though the rest, i.e. the basic and extended utilities (the ‘B’ and ‘X’ floppies) is version 2.2.2c. That may explain the occasional mislabeling.Now as for running this beast… that’s where things get complicated. The OS is extremely picky about the hardware and BIOS and won’t boot at all in many virtualizers. It also contains an interesting bug in the AT disk driver (called ‘wd1010’ in this XENIX kernel version) which causes the system to hang if the controller, or more likely an IDE disk, responds “too fast” to the Set Drive Parameters command.
If and when all those hurdles are cleared, the initial phase of disk installation can be performed. Since the available package came on 720KB disks, the first hard disk boot is rather interesting. The boot loader is run from hard disk, but the OS kernel is loaded from floppy, mounting the root file system on the hard disk again. Once the kernel displays ‘Z’ to indicate that it is fully initialized, the system hangs, reading the same few sectors from disk over and over. These appear to be the data segment of /bin/sh.
After much head scratching and trial & error, it turned out that the /etc/init binary is somehow corrupted. Replacing it with the version from XENIX 2.3.4 finally allowed the system to boot and continue installation. Unfortunately when attempting to install the entire OS, further errors cropped up, including directory checksum errors from tar.
On closer look, it’s pretty obvious that some of the installation disks are corrupted. A few sectors here and there contain garbage. But wait, there’s more…
Some of the XENIX 386 2.2.3 packages contain raw disk images, corrupted as mentioned above. Others (the original?) contain TeleDisk .TD0 images. Some utilities refuse to convert these .TD0 images to raw format or complain loudly. Analyzing the .TD0 images shows why.
For some unknown reason, some of the images contain one or two tracks with a very strange format. The disks are 720K, double-sided, with 80 tracks and 9 sectors per track. Yet some (apparently random) tracks are formatted with 12 or even 13 sectors per track. Some sectors are duplicated (e.g. sector with logical ID 3 might show up twice) while others are missing. The TeleDisk format can represent such weird disk structure, though raw images obviously can’t.
It is highly unlikely that the TeleDisk images would be corrupted, as the data is protected with CRCs and the file structure appears to be fully consistent. Just the contents are mysterious. It could be some form of copy protection, although that seems unlikely. SCO used serial numbers but copy protected media are not known. Corrupted disks aren’t an explanation either, since typical bit rot would never cause this kind of mutation.
So what caused this? That’s a mystery, for now at least. Perhaps some kind reader still has original media of SCO XENIX 386 2.2.3 which could be analyzed and the mystery explained.
On the upside, through hybridizing with XENIX 2.3 it may be possible to reconstruct a sufficiently complete hard disk installation of SCO XENIX 386 2.2.3; that is an ongoing project. It might also be possible to use a newer disk driver and perhaps console driver to avoid nasty hardware dependencies; that is currently an open question.
“Yet some (apparently random) tracks are formatted with 12 or even 13 sectors per track. Some sectors are duplicated (e.g. sector with logical ID 3 might show up twice) while others are missing.” Occam’s Razor? Sounds like the disks were corrupted before imaging.
A corrupted disk normally results in CRC checksum mismatches in sector data, perhaps entirely unreadable/missing sectors, but I can’t quite imagine a mechanism whereby random disk corruption would result in new sectors being created. What’s more, these ‘phantom sectors’ always seem to contain logical cylinder/side IDs that match the physical ones, which can’t possibly be a coincidence.
I double checked the TeleDisk image and none of the sectors are marked as having CRC errors. That makes it just about impossible that random corruption would be the cause. But then why would anyone do such a thing…?
I have a bunch of sco xenixes here (as floppy images!) that i downloaded quite a few years ago (maybe in 2005 or 2006), including “SCO Xenix 386 v2.2.2c” which is a bunch of teledisk images.
Here’s the hashes of all the teledisk images of this “2.2.2c”:
File: OSIS3.TD0
CRC-32: a92047cf
MD4: a7bbe2d35efe6df2b085143afbdd75b5
MD5: c78075b03c2a26255c158d4c77d19d53
SHA-1: f6baa2d97a98f7c03f4d66b45c871887079eb34d
File: EU1.TD0
CRC-32: 694eccc3
MD4: d26334c6bc85226944bb6204b4b8e29d
MD5: 695cf3c5a742262c45cdacbc23fbbd81
SHA-1: e179286712c0b7f969d5468a70030a0e65bec510
File: EU2.TD0
CRC-32: 255e9706
MD4: a299a6aadf91d2be3ed6f61cde23f0be
MD5: a85532d6b53b18fe96fc652b05259b49
SHA-1: d43216716a55da97ee549e4a1739a4083273f734
File: EU3.TD0
CRC-32: c2bf2db7
MD4: 0addb41b6e626e01a71ca08512dc56de
MD5: 4096fb247f4bff455e006d09027a683a
SHA-1: b78aa9a9be3d69cc5021b02c7d9aa7ffc39c8f06
File: EU4.TD0
CRC-32: f47c9517
MD4: 9c5b52206b7c95b2c867e224377608a9
MD5: f44eed1390a18816aa2c03ef034c45da
SHA-1: 13ca21a06e129b0b7a15b205af030e910199060c
File: EU5.TD0
CRC-32: 033d9960
MD4: 23fa965f000f5f66f403fa2713343b6b
MD5: d2b645981aef7908fb7b99899fb91e14
SHA-1: 6a8f9e543e0a44774a8e31a0ebb7f8cc6d296718
File: GAMES.TD0
CRC-32: 80ce48fe
MD4: d992942b90a862af39538bbe04e92178
MD5: cec06b01d31010c3db8f65db710cbacc
SHA-1: 699051bab2730c4016e7947327ca1059fec12717
File: OPS1.TD0
CRC-32: c5e18c60
MD4: d1861a8d406629f33192cf68751a7b36
MD5: 0e1d05abaaed186f529968e3e7dd1647
SHA-1: bfd939761dd0a6abd2e8b2275c0c0b57808b6367
File: OPS2.TD0
CRC-32: 63cb4bc2
MD4: b0f02b113ff4962ac260646b199d131f
MD5: 494644df319357c6ed64e5278c3bc64d
SHA-1: 8e3476f20bdc64f73b45797554dac38bfc28b6e1
File: OPS3.TD0
CRC-32: 0047fd94
MD4: 9a6a8af0357ead917895fe21d8709e56
MD5: 321feae661cc05462a36c0ff1a3e930c
SHA-1: 5f7d6d7bd955981f63fe707e4c9fcf1c52b12b4e
File: OPS4.TD0
CRC-32: 226e1e04
MD4: 95d0a5bdbaae47a7e3151afb4da7293b
MD5: 68570892828e6255ed12b88f2298e958
SHA-1: 8f97903a220b811b730f549a939df0d70b70a36e
File: OPS5.TD0
CRC-32: 8452bbbb
MD4: 97e1ab44055569e6c045761ff78a801e
MD5: 367af4f3c679da6f045039b89dfe8705
SHA-1: 6f62f7f4f29e0a57d6c8e4e75284dec52e349908
File: OPS6.TD0
CRC-32: ea8d6833
MD4: 603527a59a09bc8d188cc32f11914322
MD5: 4e8e56849f3db7b949bd4ff3db66f90b
SHA-1: 34a2b36dccd4674229ca4866bd0caa11fb0120e0
File: OSIS1.TD0
CRC-32: 3f17330c
MD4: cc854456d2bc2287fc08ddc1915fe4fa
MD5: 08f921afaf92bb58b14c725e07f8372f
SHA-1: 37b85702001d251bc7fc6ab46da8afa906843cac
File: OSIS2.TD0
CRC-32: 6fc36391
MD4: 10e01f54f8bcf4584c6e2bc1b5b5e9d2
MD5: 1033c6ebfb5651b23bda26fbc5a31e02
SHA-1: 9ca8ee38a0649b84593d32893ce1c133ba1f6091
wow I wonder if you strings the kernel if it has enough logic to panic if it was a 32bit SW MUL bug chips….
Yes, that logic is there. Documented in the manual, which explains those double-sigma branded chips etc.
Yes, that’s the one. As I explained in the article, the core OS is actually 2.2.3, even though the surrounding bits are 2.2.2. OPS1/2 are the kernel + root FS disks.
Pingback: Oldest Surviving 386 PC OS? | OS/2 Museum
Pingback: What a Coincidence | OS/2 Museum