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!
The cu command is used to call up another system and act as a dial in terminal. It can also do simple file transfers with no error checking. cu is part of the UUCP source but has been split into its own package because it can be useful even if you do not do uucp.
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.
This assumes that a 25-year-old 5.25" floppy drive still works, not to mention that the floppies are actually physically and/or track-compatible with anything he might have around. Both may be quite a leap.
Hmm, well 'Xenix' is actually an old SCO product which SCO originally bought off Microsoft, but it was then licensed to several other vendors - but as has been said here, your best bet is the serial port. Either use UUCP, or if you have a compiler on the host - compile up a simple xmodem/ymodem/zmodem binary and transfer like that. Worst case scenario, tar up all the data, compress it (it would have old style unix compress -.Z), uuencode it (if you don't have uuencode, you can download it -it's just a shell script I recall), split it up into chunks, then just cat each individual chunk onto another host and reverse the process to decode it all back into a tar file. You might want to checksum each bit too (sum should be on old Xenix systems).
I think removing the disk and mounting it on another host should be your absolute last resort.
If the system isn't bootable, and you have the right drive controller, carefully connect the old drive to a new system and use something like "ddrescue" ( http://www.forensicswiki.org/wiki/Ddrescue) or "dd_rescue" ( http://www.forensicswiki.org/wiki/Dd_rescue) to take a disk image. Both those programs try to recover from bad blocks, whereas standard dd usually will error out. (Personally, I'd make an image even if the system is bootable.)
With the disk image extracted, you can pack the hardware away or do whatever with it. Then you can focus on finding (or writing) tools to read the disk image. If you find that there is a Linux filesystem driver, you can use the loopback behaviour (see the man pages for "mount" or "losetup") to treat the disk image as if it were a drive. If you don't find a driver, perhaps you'll find some specialty command-line tools that can extract information, or documentation to write your own. At worst, you could use the "strings" command to read any text found on the image. Since you're working against an image, you can take your time, experiment with ad hoc techniques, make mistakes (remember to make backups), and try again and again.
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!
This takes me back....
Firstly, I'm sure that there were never 10MB IDE drives. The drive will either be ST506, ESDI or possibly even SCSI.
Secondly Xenix would create several filesystems within the Xenix partition, using its own separate partition table. As far as I'm aware no mechanism to read these tables was ever added to the Linux kernel.
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.
Screendump.
"WTF?"? Assuming most of the data is ASCII/ANSI, cat it to the screen, preferably with pagination (it will ease the conversion if pagination is used). Place a high res camera in front of the screen and photograph/video record the data then run the photos through OCR...voila! (of course if video is used you'll want to just grab 1 occurrence of each page...if you've just done a cat without pagination this is going to make the conversion a lot harder).
Of course the above sounds stupid but with hardware that age you want to do everything possible to capture the data as fast as possible. Depending on how much data you're talking about you might be able to do the above faster than transferring the data via serial.
Oopps, time for me to climb back into my box.
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.
The porn from that era just wasn't as good as you remember it to be. Perhaps you're better off with the good memories that you have. The reality can only diminish them. Leave the data on that old machine and you'll be happier.
Fascism trolls keeping me up every night. When I starts a preachin', he HITS ME WITH HIS REICH!
I worked on these way back when. I'm surprised it still works. I agree with the above, you have two options:
1) tar up the whole filesystem (if it will fit), and use uucp to move it via serial port. Make a null-modem cable and ship it across. Be careful to get the flow control right. Some of the old machines had serial ports that couldn't keep up with 9600 baud, so needed RTS/CTS or DTR flow control to avoid overruns.
2) It should have the ability to make FAT format floppies. Do it piecemeal, if you can find a 1.2 MB 5-1/4 drive for a PC anymore.
The filesystem is XENIX format, not FAT. If I recall, it's similar to the original SVRX filesystem. It MIGHT mount under Linux, but I'd be more afraid of an incompatible controller frying the drive. I don't recall these machines used IDE, I could have sworn they predate IDE, and the drive would have been either the old Shugart interface, or some kind of SCSI. The Altos machines I used had either a 10MB or 40 MB Shugart, and those were the BIG sealed units. IDE didn't come in till 3-1/2" drives, and I believe the later Altos machines had at best 5-1/4 drives either ESDI or SCSI.
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.
You can try porting the entire system over to a virtual machine, using dd to copy the entire system, then booting it up in qemu... Here's a link to someone who's had success with this approach... http://virtuallyfun.blogspot.com/2007/05/running-xenix-on-qemu.html Good luck!
Sometimes the light at the end of the tunnel is the headlight of an oncoming train.
these people are all wrong...just take it to Best Buy! the Geek Squad could save the data for you fo' sure!
Uh, you would have to uuencode it first, so
tar | compress | uuencode > /dev/serialportdevice
should work
My ism, it's full of beliefs.