The XENIX 386 2.2.3 Mystery

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.

XENIX 386 2.2.3

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.

This entry was posted in 386, Xenix. Bookmark the permalink.

9 Responses to The XENIX 386 2.2.3 Mystery

  1. Jim Leonard says:

    “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.

  2. michaln says:

    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.

  3. michaln says:

    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…?

  4. Wack0 says:

    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

  5. wow I wonder if you strings the kernel if it has enough logic to panic if it was a 32bit SW MUL bug chips….

  6. michaln says:

    Yes, that logic is there. Documented in the manual, which explains those double-sigma branded chips etc.

  7. michaln says:

    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.

  8. Pingback: Oldest Surviving 386 PC OS? | OS/2 Museum

  9. Pingback: What a Coincidence | OS/2 Museum

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.