Slashdot Mirror
Need Help Salvaging Data From an Old Xenix System
Milo_Mindbender writes "I've recently gotten ahold of an old Altos 586 Xenix system (a late '80s Microsoft flavor of Unix) that has one of the first multi-user BBS systems in the US on it, and I want to salvage the historical BBS posts off it. I'm wondering if anyone remembers what format Xenix used on the 10MB (yes MB) IDE hard drive and if it can still be read on a modern Linux system. This system is quite old, has no removable media or ethernet and just barely works. The only other way to get data off is a slow serial port. I've got a controller that should work with the disk, but don't want to tear this old machine apart without some hope that it will work. Anyone know?"
Even if it would take weeks. You're handling a historical relic, don't want to mess it up.
Emotions! In your brain!
It'll take a few hours at 9600 baud. It's your best bet. Let it run over night and the job is done.
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
if the thing has a pc speaker you can (with a bit of work) and a noisy export via modulated audio.
of course if you have access to a serial port controller that's easily the simplest method.
~.~
I'm a peripheral visionary.
Xenix used their "sco xenix" filesystem. The Xenix filesystem is supported under the mount utility in modern 2.6 linux kernels
by Anonymous Coward
Seriously, don't go there, not until you get the data off via the serial port (or flatly establish that you _can't_).
You are dealing with a system that is lucky to be functional _at all_ after 25+ years, and presumably got heavy use while it was active. Corrosion, brittle plastics, dust worked into dangerous areas, etc..
If it's working now, taking it apart stands a good chance of breaking something that is difficult or impossible to fully repair, and you don't want to go there until the information is preserved.
It's Xenix. Ancient Xenix. Kermit wasn't commercial software, it was (and is) freeware. (http://www.columbia.edu/kermit/) Finding a way to compile and transfer Kermit to such an ancient system would take some serious archeological research, and some luck, because I certainly wouldn't expect to find it in Xenix from the days when Microsoft published it.
Given that it's only 10 Megabytes, "cu" or "uucp" it over the serial port twice and compare the results. Then, when you're entirely confident, consider using your controller in a newer system to do a modern Linux or UNIX "dd" of the entire disk image. I'd be fascinated to know what filesystem that ancient OS used, and if there are drivers available in a modern Linux to actually read it directly. Perhaps someone here or on an old Xenix support group would know.
There's also an odd source of SCO expertise that may be helpful, since SCO took over Xenix: the forums over at www.groklaw.net.
What a great machine. The Altos 586 was the first machine I used to run my BBS (which has run nonstop since 1988 and is still online today) before SCO Xenix and later Linux arrived on the scene. It was an insanely cool computer.
Anyway, even if there were an operating system available today that is still capable of parsing the Xenix filesystem, you wouldn't be able to get to it because the disk is attached to the system I/O board using an ST506 controller. Good luck finding a modern computer with one of those in it.
You're going to have to move that data off the machine the way we did it back in the days when an Altos was a modern computer. Plug a null modem cable into that serial port and use UUCP to get the data moved. Or if the machine has rzsz installed, you might be able to get away with using Zmodem instead.
Tired of FB/Google censorship? Visit UNCENSORED!
Actually, the floppy drive has a higher probability of working than the hard drive, although it will need some cleaning :)
The floppies can be anything... hard sector, soft sector... You'll have to verify it (xref the floppy mfg number to the manuals).
Given patience, you may even make hard sector floppies from old softsector ones.
The hard drive however is NOT an IDE drive. IDE wasn't designed until 1986, and wasn't widely marketed until a year or two later. The drive is either an MFM or RLL drive. Fifteen years ago you might have found an abundance of controllers that could handle these drives, but you'd still be hard pressed reading the data.
I recommend that you get the Altos up and running, and transfer via the serial port to another machine. You should be able to get 9600 baud, and with any luck (although I'd doubt it) you might be able to push it to 19200.
This signature is DRM protected. By the DMCA, you are not allowed to counteract or oppose to it.
If the information was in a "public" forum, one visible with the access level generally granted to members of the general public, it's probably considered a "publication."
If they were "published" prior to March 1, 1989 but not registered with the copyright office AND not marked (c) they might be in the public domain. See a lawyer.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
Setting up UUCP on Xenix
Setting up UUCP on Linux
If you really want to try to read the disk it is probably UFS which you can read from Linux.
Hope this helps.
... However, as I remember from back when I worked at SCO (years before the name and some assets were sold to the lunatics from Utah), Xenix filesystem and partition table support was rolled into SCO UNIX SVR3.2/386. And Open Desktop. And ODT came with a proper working TCP/IP stack. It's probably overkill, but once you've tried using uucp to get the files off the BBS, you might want to pull the ST506 drive (presumably an MFM-encoded one, not RLL-encoded) and stick it into a shiny new 386 with, say, 4Mb of RAM and a 40Mb disk with SCO UNIX installed. That should enable you to mount the filesystems and export them via NFS. It's a lot of work, though.
Ah, the Altos systems. 8800 series, then 486, then 586. They used up numbers years before Intel got to them (the Altos 486 had an Intel 80186 in it, and 4 serial ports). Often paired with Wyse terminals. Anybody else remember "business basic"?
It's almost certainly an ST506 drive; you will be very hard pressed to connect it to a PCI era system; probably can only get as far as AT bus machine.
In any case, if you do manage to image the drive, the filesystem will be based on either Unix version 7, Unix System V, or the Berkeley Fast File System. It wasn't until Linux rolled along that we started to seriously fork into lots of file system variants. It's most likely the basic System V file system, which is well documented, and pretty simple stuff.
The posters above are correct, however. You really should try the serial port approach first. I'd go for cu over uucp - getting uucp running can be quite an exercise in itself. And you'll want either tar or cpio; probably tar, but watchout for version and format incompatibilities there as well.
You can also just cat the data out a serial port, and capture it as a session log on the other end. That's likely to be the easiest solution, and perhaps more reliable than any other.
You haven't said what the nature of the data is, but after this much time laying dormant, you are likely to have substantial challenges at the application level interpreting the data as well.
You can use tar and serial ports.
Once you get the systems connected via serial, you can do something like this on the Xenix box:
tar cf /dev/serialdevice0 /home (or whatever directory you want to move)
then on the Linux box on the other end:
tar xpf /dev/ttyS0
will unpack the data. Tar hasn't changed much in decades, and works very well through pipes like this. Good luck. :)
IMHO you should use the serial port to move whatever data you want moved. Your chances of success with other methods are low.
I worked with a lot of MFM (ST506 interface) drives back in the day, and from my experience it was very unlikely that different models of MFM controller cards could read the drives from one another. If I installed a newer MFM disk controller card in a machine or moved the drive to a different machine with a different MFM controller, I would almost always have to re-low level format the drive before I could even run DOS format. (And mine were just FAT16 so the file system was never the issue)
So even if you have another MFM controller card, unless it is the exact same model of card it is unlikely that you could read sectors off of the drive. Their underlying low-level formats seemed to differ.
I also actually had the pleasure of briefly using an older model Altos 8600. That model had a bunch of serial ports for dumb terminals, an 8 inch floppy drive and an *8 inch* 40 meg Quantum Q2040 hard drive. I still have the 8" Microsoft Xenix floppy disks.
Fairly recent Xenix binaries of Kermit exist: http://www.columbia.edu/kermit/ck80binaries.html#sco
.sig withheld by request