(this is a guest post by Tenox)
I’m extremely busy with some matters and unable to spend much time with computer archaeology. I would like for some much overdue projects to progress independently of myself, so hopefully the community can participate and help out.
Let’s start with Venix/86 which has been awaiting my attention for a while. I have been recently contacted by Alex aka uav1606 who wanted to get it to work. I have since decided to open this up to anyone else interested.
To my knowledge actual install media did not surface so far. However a while ago I came in to possession of a boot disk and a backup of a live system, in form of nine floppy disks which look like a tar archive. In theory it should be possible to boot the xfer disk, format a hard disk and restore the backup system to get a working system.
I’m offering $100 prize via PayPal to the first person who will run Venix/86 on an emulator of any kind (PCE, PicoXT, QEMU, Bochs, Vbox, MESS/MAME, etc NOTE: it doesn’t have to be strictly XT emulator as long as the system works), compiles Aclock and sends me a binary + complete working virtual machine. I will also of course publish it on this blog featuring all your hard work! It will be awesome to see your progress and collaboration in the comments 😉
Everything I have is here: http://www.tenox.net/get/venix21.zip
Update #1: From Frode van der Meeren who is the owner of the floppy disks: “The disk images are not corrupted, the disks only use a different track arrangement. The disks image format arranges the tracks by cylinders, storing head 0 and then head 1, while the actual disks arrange tracks by all cylinders on head 0 then all cylinders on head 1. If you want to mount the images into something else than Venix/86 then you need to rearrange the tracks in the image file.”
Update #2: the competition has been won by Jim Carpenter! Congratulations! Jim has just received the $100 prize. I have received detailed install instructions and will post it in a follow up post 🙂
Update #3: The winning entry, how to install Venix/86 on MESS/MAME
It was a real pleasure to see great community response, participation and most importantly to see Venix/x86 run again!
Stay tuned for another one 😉
This running on emu, untared with ancientfs, but cannt mount anything.
Indeed, xfer worked no worries in PCEm.
Sadly I couldn’t see a way of mounting the second floppy from xfer, which would have made life a fair big easier.
If you prep a hdd image with the xfer disk, then somehow mounted the hdd image, you could then untar the backup to it.
soviet-pc. narod. ru (remove spaces) here are PC AT & XT emu with possibility to mount two images at time, floppy or hdd, but while xfer was running it’s mount tells only “. not found” & so on. Also it “can” mount a directory like a hdd, but in RO-mode. i stopped my experiments after ancientfs crashed my mac in to “gray stop sign”.
Whoa a contest! And I’m moving aaaaargh!
.I’m really the next process down
.This space for rent
.Singin’ in the rain….
.I am but a Cog in the Wheel of Life
.Look out!!! Behind you!!!!!
.Looking for a good time, sailor?
.I don’t get NO respect…
.Augghh! You peeked!
That leaves you $%d in debt
that leaves you broke
— You are now Solvent —
I can’t understand that
panic: bad monopoly descriptor: orig = %d
Seems the backup is broken. I can bruteforce the untarring of the data from the xfer boot disk, but I guess that the data is too much corrupted, or something like that. I might also be using that tar command wrong.
Here’s something I did:
mkfs /dev/w0.sys 55456
mount /dev/w0.sys /mnt
tar xf9 /dev/rf0
The commands I copied from the wizard thing, the number in mkfs is what was suggested by the Winchester hard disk utility. Basically, I was able to one-shot make a FS, mount it, then using tar in it.
The result is the same than if you follow the steps in the wizard.
Here’s the steps I follow with the wizard, parts in brackets are elided or comments:
Do you wish to prepare the winchester hard disk […] y
Are the default winchester partitions acceptable? y
Do you wish to create the user area? y
WARNING: There is a VENIX file system already on the user area. Do you wish to continue? [If you retry] y
Do you wish to check for bad blocks on the user area? n [It’s just slow]
Remove the XFER floppy and insert USER 1 floppy in drive 0.
Press ‘return’ to begin the tar extract to the winchester.
Here is what I’m doing, and it’s possibly wrong: Insert BACKUP1.IMG, press return, hit a SOFT ERROR, press I until it beeps and asks to insert floppy 2. Repeat for every floppy disks it asks. Here’s the number of times I had to hit ignore: (1: 29, 2: 4, 3: 0, 4: 2, 5: 2, 6: 1, 7: 2, 8: 15).
It should have asked for a total of 8 floppy disks.
Then, insert back XFER as asked.
The user area should be complete.
Do you wish to create the system area? y
Remove the XFER floppy and insert SYSTEM A floppy in drive 0.
Press ‘return’ to begin the tar extract to the winchester.
Well, here’s where it’s a bit weird. You do the same dance, try to extract stuff… It asks for SYSTEM A, then for “floppy B”, which I’d assume would be “SYSTEM B”. If you do the math, BACKUP 1 through 9 makes 9 disks. We used 8 for User, then are using one for SYSTEM A. There is no SYSTEM B. Just for fun, I continued using the same floppy, to see how many SYSTEM disks it wants. It wants A through E; 5 floppies.
If I understand properly, and the backup was not full of soft errors, we’d need 13 floppy disks.
I looked at the floppies, it seems that 1 through 8 are for the user area, and the last one, 9, looks like it could be any one of the 5 system disks.
Here’s a random thing I did, looked at the first couple of bytes in all floppies:
BACKUP1.IMG has a ./ directory entry, but looking, with xxd still, at the file, it looks like all directory entries are for /usr.
BACKUP9.IMG might not be SYSTEM A, but another one as, I might be wrong, I believe the first volume from the archive would also have the ./ directory entry. It also does not have the ./bin/ directory entry, but has many entries under it. It has ./lib/ and ./dev/ with a couple device nodes.
There is also a crude file listing in the gist. I think, though I could also be wrong on that matter, that entries in the tar files are all aligned, this alignment makes it easy to peek without parsing the file at the filenames.
It might be possible to salvage many things from the backups, they might not even be broken, it might be the emulation that does weird stuff. I just wasn’t able with PcEM to do anything with them.
Oh boy was that a ramble. If you need more infos about what I did, do ask, I’m mainly grasping at straws here.
Closing notes, or: TL;DR:
Even if the backups were good, it seems we’re missing 4 backup disks from the system files. We seem to mostly have the 8 backup disks from /usr/.
I am pretty sure the number in the tar command is the amount of disks to process, and when followed by a dash, the tar output will use letters instead of numbers.
When manually untarring the data from the backups with the xfer disk, I has a couple files. I believe they were mostly the same files I had when untarring using gnu tar or bsdtar on my linux box.
check the bios configured floppy types… or that is my guess on the soft fail. Or you may have to look for some kind of override on the disk type, like in Xenix.
see update #1
The backup images are either weirdly interleaved or somewhat corrupted (or both): between valid data blocks, there are blocks of constant 0xf6 and block with “pieces” of :”something” that contains microemacs-like commands.
see update #1
Ever so slightly weirder: the disks are written on head 0 from track 0 to track 79 and then on head 1 back from track 79 to track 0.
They seem to be interleaved; upon dropping each second 15 sectors (halving the files) everything (that remains) seems to be aligning nicely. Of course this doesn’t mean that the file contents are correct, just that the next header is in the expected position. Nevertheless, that is *very* strange. At first the impression was that maybe that version of TAR would first fill-up one side of the disk and then the other. Alas, no.
I have written a quick and dirty C program just to check the tar format alignment, and so far, besides the few bad tracks the interleave seems to be the biggest problem.
did you see update #1 in the post? 🙂
I posted that comment last night (EET), it took a while to appear (the update was not visible at the time). I’m glad that my intuition proved correct, however, the trouble is that the second side doesn’t seem right. I havent’t tried running on emulators, just looking at .IMG files. I can extract all but the last file from side 0 of each disk, and at least the text ones look right. I can’t check the binary ones, of course. However, if I try continuing on side 1 they don’t look right… I think I got it!
(answer in next post, I have to check!)
That’s it! The pattern is all the tracks from side 0, then *backwards* from track 80 from side 1. It makes some sense, why move the heads 80 tracks in the middle of the operation?
So yeah, I can confim that the backup disk are fine, everything can be extracted using regular tar from the images, once they are properly arranged.
Thanks for the great challenge. Now, if I would only know the filesystem structure, I could build the virtual harddrive without bothering with XFER 🙂
By the way, @samueldr – as was stated in the first message, this is not a software distribution (or installation kit), but only a backup of a running system, I believe that XFER is having trouble with that.
I’ve got a virtual hard drive properly partitioned and booting. All backups restored perfectly. And aclock seems to be running flawlessly.
Some quick pictures: (hope I got all the links right)
If Tenox would shoot me a private e-mail I’ll get the HD image and aclock binary to him.
This was fun.
Congratulations on beating me to it 🙂
Good thing you didn’t mention the solution – I’m glad to have found it on my own, if a little late. Some different screenshots:
we also have games:
(pcem1.png is not yet public, as it shows what was needed to solve the challenge)
Can you tell, how you did this? Do you have full installation kit of Venix? Maybe you can share it (for me or for all)?
Nice work! How’d you do it?
Added aclock as well (source transferred via virtual floppy)
@Tenox, will it be all-right for me to make hdd image public later on?
OT, but has something to do with virtualization – the proof there may be a god, for ESXi finally has a HTML5 (no Flash!) client… and it doesn’t even need vCenter!
You can always talk to ESXi without vcenter, but a client that doesn’t need flash?!? Now we’re talking!
Too bad the site is down, maybe it’ll be fixed later.
No installation kit is required. All that was needed was in the original archive. It did require some small modifications, though.
A small hint is here:
(not the fact that it’s CGA; by the way, an AT class computer is required for restoring – backup floppies are 1.2MB and XT didn’t have that)
Unfortunately, after “Part I” I always get this message (on PCEM, on real XT, AT…):
“Are the default winchester partitions acceptable? Yes
System = 64776 blocks
Swap = 750 blocks
Temp = 0 blocks
User = 0 blocks
AT Timeout waiting for 80 to be 0
At drive failed to go not busy
Error on the Winchester, unit 7
AT Drive never went ready
while writing block number 0. Status 00
Probably the hard disk controller type, maybe CGA 286 with an XTIDE controller?
On PCEM generic 386 with ~33MB HDD (CHS = 512,8,17) it doesn’t have any trouble there. On real 286 with 80MB Caviar I partitioned it without trouble (during my experiments; I did not yet install it on the real HW).
It seems that VENIX uses BIOS for HDD access, so unless you go crazy with disk size (30MB is quite enough) there shouldn’t be any problems on that side. Indeed, on QEMU it doesn’t work, but on PCEM it works fine. I have not tested other emulators.
As I said, CGA was just because I didn’t bother to download VGA roms at that time; it’s not relevant. You do need an AT-class computer (real or emulated) because the BACKUP disks are 1.2MB and XT didn’t have 1.2MB drives.
Guys I’d like to thank you for your participation and great response. Again congratulations to Jim. I will be posting detailed install instructions in a follow up post.
It’s the next version, and ~7 years later, but I just found, imaged, and archived Venix/386 – installable on actual or virtual hardware. Not sure if that qualifies for your bounty, but still 😉 I have it up and running on a 386 with 8mb ram and a 256mb CF card for HDD.
WOW! Thank you so much for this. I think the challenge is long over for Venix/86 but this definitely deserves a gold medal of some kind! 🙂 I will see if I can install it on Qemu or 86box. Thanks again!!!