Need Help Salvaging Data From an Old Xenix System 325
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?"
Use the serial port ... (Score:2, Informative)
cu (Score:2, Informative)
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.
Re:cu (Score:3, Informative)
He needs to use uucp, not cu. UUCP stands for "Unix to Unix Copy" and it means exactly what it says. Yes, there is a uucp command in the UUCP package.
Comment removed (Score:5, Informative)
yeah (Score:5, Informative)
Xenix used their "sco xenix" filesystem. The Xenix filesystem is supported under the mount utility in modern 2.6 linux kernels
by Anonymous Coward
Re:cu (Score:3, Informative)
There is a pretty good chance that kermit is available for that system. I would go with kermit file transfers over uucp any day it being easier to set up, has decent error detection and better feedback for the average user.
Serial port. (Score:3, Informative)
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.
Make a disk image (Score:2, Informative)
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 [forensicswiki.org]) or "dd_rescue" ( http://www.forensicswiki.org/wiki/Dd_rescue [forensicswiki.org]) 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.
Altos 586 (Score:5, Informative)
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.
Reading the disk will be tricky. (Score:3, Informative)
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.
Re:No Removable Media? (Score:4, Informative)
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.
Pre-March 1989 publications may be easier (Score:4, Informative)
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.
Google? (Score:1, Informative)
Have people lost the ability to Google for answers before pestering other people? After about 5 seconds I found this:
http://aplawrence.com/SCOFAQ/FAQ_scotec1linuxfs.html [aplawrence.com]
You're welcome. =P
UUCP info you need (Score:5, Informative)
Setting up UUCP on Xenix [wb.nic.in]
Setting up UUCP on Linux [faqs.org]
If you really want to try to read the disk it is probably UFS [wikimedia.org] which you can read from Linux.
Hope this helps.
My two cents (Score:3, Informative)
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.
Re:Use the serial port ... (Score:3, Informative)
Given the speed of hard disks from that era, I'd imagine that removing the disk, putting it in another machine, copying it, and then putting it back would take about as long as copying via the serial port. It's also worth noting that the machine has 5 serial ports, so if you're really in a hurry you can probably dump different bits of the filesystem in parallel over several ports (if the disk will handle that concurrent reads even at serial line speed).
10MB is a really small amount of data to copy via a serial link. Back in the early '90s I had an 8086 PC with 5.25" disks and my father had a 386 laptop which took 3.5" disks. The only way of copying games between them was via a serial link. The 8086 machine could handle 115Kb/s, meaning that the entire transfer would only take about 10 minutes. We usually ran it at about half this speed though, because our crappy serial cable didn't have the hardware error checking pins connected, so we needed to use software parity and reducing the line speed made things more reliable.
File systems were simpler back then (Score:4, Informative)
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.
tar over serial? (Score:5, Informative)
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. :)
Re:UUCP info you need (Score:2, Informative)
Comment removed (Score:3, Informative)
Re:My two cents (Score:3, Informative)
I worked on equipment of that vintage. It is possible it has mtools installed on it to read and write FAT
floppy disks.
You could create one big tar file, then use split to chop it into floppy sized pieces. Then the trick would be
finding a 5 1/4 floppy drive and matching controller to plug into a modern machine.
I had the dubious pleasure of working with Trusted Xenix, which resembled SELinux today. It required a '286 or above
because it depended on 286 protected mode and took up about 12 MB on the hard drive.
Are you sure it's an IDE drive? More likely MFM (Score:5, Informative)
IMHO you should use the serial port to move whatever data you want moved. Your chances of success with other methods are low.
Re:File systems were simpler back then (Score:3, Informative)
Re:cu (Score:5, Informative)
Re:cu (Score:3, Informative)
Except it's early 80's (1983,) and it appears to be [classiccmp.org] Version 7.
Which is Ancient Unix, although barely.
Re:Use the serial port ... (Score:4, Informative)
Geepers, people...a non-Compaq 8086 system from that era would almost certainly have an ST-506 interface hard drive, not IDE! Those old hard drives were built like tanks, and tend to keep their data. If you can't get the system running, you can probably dig up some old 286 system, or even a *Pentium* system, and plug an 8 or 16 ST506 hard drive card, like the old Western Digital W8006, and access the data that way. A ST-506 drive will have three cables connecting it...one for power, one (the fat ribbon cable) for control, and the last one (skinny ribbon cable) for data. JUST MAKE SURE THAT THE PIN 1s LINED UP OTHERWISE YOU CAN BLOW THE DRIVE, CONTROLLER, AND MAYBE EVEN THE COMPUTER. If the cable is not "keyed", that is, has a vertical piece of plastic to make sure pin 1 connects to pin 1 on the edge connector, you have to figure out which is pin 1 on the cable...If it is a grey cable with a red strip on one side, that is pin 1, which should connect to the edge connector side that has the notch in it. If you have a braided, multi-color cable...sorry, you will have to figure it out yourself.
Of course, if you really want to be paranoid, and have the money, contact an old hard drive recovery company like On-Track, and they should be able to hoover all of the data off for you, and give it to you in an easy to read format.
ttyl
Farrell
Another interesting way to skin this cat.. (Score:2, Informative)
Re:I'd do it the slow but secure way. (Score:5, Informative)
A 16550 in the early 1980s? I'm sorry, but I think not.
I wrote a lot of serial comms drivers back in those days, and I don't think I even /heard/ of a 16550 until the very late 80s. First one I actually met was probably in my brand new 486DX33 box I got in 1992, although to be honest I don't remember for sure. I didn't code for one until about 1994, and that was on an embedded system, as you still couldn't guarantee that all PCs would have them rather than 16450s or even 8250s.
Also bear in mind that the original 16550s were broken so you couldn't use the FIFO feature (which was the whole point of the thing) properly; that wasn't fixed until the 16550A came along.
Wow; lots of people who don't know what they're on (Score:1, Informative)
about.
Oh, wait. This is Slashdot.
The filesystem is going to be BFFS or Xenix format, and you could, in fact, mount those, *if* you have a controller that a) has drivers in Linux (the last one I remember is the WD 100...3? 7?) b) for which you have a bus slot.
The xda drivers haven't been in the kernel since, I think, 2.2; maybe 2.0.
But the *real* problem is that Xenix is going to have wrapped the actual filesystem partiiton inside a "division", with a divvy table, which is *then* further inside the disk partiiton.
To the best of my knowledge, Linux has never had divvy table handling; you could mount Xenix filesystems, but only if they'd manually been made on an entire partition, instead of inside a division -- I had to do this a couple times, during conversions.
If you have a working ethernet adapter and the TCP stack, by all means, FTP the entire raw division image over to a Linux box, and then loopback mount it there. If not, then UUCP it over the serial port.
Once you *do* have it in a file on a current linux box, you should be able to mount it, though you may have to rebuild some things into your kernel that aren't there by default.
If you need details, I have a complete set of SCO Xenix manuals, including development and, I think, TCP, on my shelf, ca 2.3.4 timeframe; let me know.
(I would sign in, but Slashdot won't let me from the laptop for some reason; jra/5600)
Re:Altos 586 (Score:3, Informative)
Even if you could find a relic ST506 card, it would be ISA. You can't find that either. Then try to find a driver...
Re:NO DISASSEMBLE ALTOS! (Score:3, Informative)
Hard drives almost always die due to bearing failure at this age, more specifically, lubricants turning to glue essentially.
If that hasn't happened, he's probably pretty safe, its probably all gone!
Either way, removing the drive to put in something else most certainly increases the chances of problems, and while unlikely, the Xenix driver in Linux may have some quirks dealing with an FS that old. The Xenix driver certainly isn't one of the more well tested fs drivers.
With what really is an archological find from a geek perspective, I wouldn't take any risks at all, and like everyone else suggests, if the system is bootable, serial it off FIRST, as an image if at all possible. Verify the image is valid and consistent on a Linux machine before you do anything else to the original hardware.
What actually hasn't been hit on yet and to me is a big one ... if it boots, don't turn the damn thing off!
Get some of the hard disk lube moving around, or start working some dry capacitors and you're likely not to have a high number of boots left, especially if this thing has been sitting for an extended period of time.
Re:I'd do it the slow but secure way. (Score:3, Informative)
Yup. 2-3 hours is about right.
Data volume for 10MB = 83886080 bits
10 Mega Bytes * (1024 Kilo Bytes / Mega Byte) * (1024 Bytes / Kilo Byte) * (8 bits / Byte)
Time to transfer 83886080 bits at 9600bps = just over 2.4 hours
83886080 bits / (9600 bits/second) / (60 seconds/minute) / (60 minutes/hour)
Re:I'd do it the slow but secure way. (Score:5, Informative)
exactly, 10mb at 9600bps will take only 2-3 hours.
Yep, and since your computer is a 586, there's a good chance the serial port will do 192kbps which even faster still. If you want to transfer binary files, I'd suggest using the zmodem protocol. Since your Xenix system was running a BBS, it almost certainly has software installed that will do zmodem file transfers.
Re:I'd do it the slow but secure way. (Score:2, Informative)
Re:Pre-March 1989 publications may be easier (Score:2, Informative)
No need to bring a lawyer into this. Everything is still copyright unless explicitly put into the public domain. The Berne convention(s) went into effect 1971.
The Berne Convention went into effect in the United States in March 1989. I just assumed the BBS in question was US-based.
Re:I'd do it the slow but secure way. (Score:2, Informative)
Yep, and since your computer is a 586.....
The model is 586, but that's not the cpu in the beast. I know it's asking a lot but how about RTFA? Or even taking note of the date - late 80s. And when was the Pentium cpu (aka 586) first manufactured? 1993. Turn in your geek card fool!
Re:I'd do it the slow but secure way. (Score:2, Informative)
The Altos 586 was called that because it has five user ports and the processor is an 8086.
Yes. Microsoft produced a version of Unix that supports 5 users in 512K of memory. That's how much my Altos 586 has.
I am elated to see the Altos 586 featured in an article on Slashdot.
Re:Xenix had tar (Score:3, Informative)
Uh, you would have to uuencode it first, so
tar | compress | uuencode > /dev/serialportdevice
should work