Venix and Aurora/75 Videographics System
Part I - Venix recovery
In the beginning...
This all started with a challenge by Tenox, again on virtuallyfun. In short, the challenge (that I failed to win, btw) consisted of him providing 10 FDD images (1 360K and 9 1.2M) along with some information about their contents. The first (labeled XFER) was obviously boot (and install) floppy for Venix/86 and the others seemed like tar archives written directly to disk and were said to have contained backups of a running Venix/86 system. The request was to get the system up and running in an emulator and run aclock on it.
First I wanted to know a little bit more about the Venix system. The Wikipedia page on Venix got me the first information about the system. Then, I found the excellent Xhomer emulator and had the opportunity to experience a working system.
First tries and some false starts
The XFER would boot fine on PCEm emulating a 386 as well as on real hardware (286). Using a resoanbly sized HDD, it would partition without any problem, however the installation process using the BACKUP images would fail with "Soft error".
After looking through the image files (and learning in the process that tar only has checksum for header info, not for data) I arrived at the conclusion that seemingly the archive is recoverable only from one side of the FDD image (i.e. dropping every other 15 sectors would make a valid -if incomplete- archive).
My post first post on the challenge page: [...]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.
First partial succes
After that Tenox posted an update and my further comments there seem quite funny in retrospect. I read the update in a hurry, he did describe the backup floppy format but I only read up to the point "The disk images are not corrupted, the disks only use a different track arrangement." I somehow missed the actual arrangement but nevetheless was very glad discovering that on side 1 the archive was continuing from thack 79 to track 0. I wrote anothe quick and dirty program to rearrange the images and indeed tar extracted them without a hitch.
Ok, fine, I now have the full backup in a directory on my machine, what to do next? This is where I made the wrong decision. Instead of continuing to study the install process I had a bizzare idea to try and write into the Venix filesystem that the installer created.1 It shouldn't be too complicated and some of the structures were already available from the backed up /usr/include files. I did write a rudimentary FAT "driver" in ASM many years ago so it didn't seem quite that difficult. However, FAT is nicely documented, while on Unix filesystems I had only vague ideas, so this would take a while.
Someone else got there first and a change of plans
In the meantime someone else solved the challenge. This stopped my approach, since it was unlikely someone else would have written a filesystem driver in such a hurry. It seemed probable that there was another possible approach. I am very glad that Jim did not mention the solution immediately, but only posted proof of result.
His success got me thinking again about the boot/install process. I have already tried writing the XFER and BACKUP1 images on real floppies (360K and 1.2M respectively) and confirmed that on a true 286 machine installation will fail with the same "Soft error" message, but I did not pursue this further at the time. I just thought that the XFER is made for install media, not those backups. Besides it looks quite confusing, when getting into the shell and typing mount it would show both partitions as mounted (and several times at this!)
One other issue is that PCEm doesn't know how to handle different formats in the same drive. If the FDD is configured as 1.2M, when loading the 360K XFER.IMG file it will no longer boot. I converted XFER.IMG to 1.2MB (padded each "track" with 6 more sectors and added 40 more full tracks at the end) and solved this problem.
I can see the light
Only then I realised that "back in the day" there were separate /dev entries for various floppy formats. It should have been obvious! The install program expected 360K floppies and used the corresponding /dev entry. The images were 1.2M, so of course it would have failed when reading them as 360K. And of course, there were two "floppy" entries in /dev: rf0 and rh0. rf0 was used by the install program, I assumed that rh0 is high density.
Fortunately, the installer shows the commands it's using, e.g.:
tar xf8 /dev/rf0
for installing /usr. I assumed that the 8 represents the number of diskettes. /dev/rf0 is obvious, of course. I already know that backup disks 1 to 7 only contain /usr on them. The system is on BACKUP8 and BACKUP9. I went and searched the XFER.IMG file and found the tar command that I modified to:
tar xf7 /dev/rh0
The command to copy the system partition found a little further on (tar xf5- /dev/rf0) was replaced with tar xf2- /dev/rh0.
Finally, with huge satisfaction I went through the install process without errors, using BACKUP1-BACKUP7 as USER1-USER7 and BACKUP8 & 9 for SYSTEM A & B. And then the system booted from the HDD for the first time!
On first boot the system complained about a missing secondary HDD, but the rest seemed fine. A quick loook revealed a slight problem - everything that should have been in /usr was in /usr/usr (because the backup archives contained the full path). No mv * ../ and no for i in * ; do ... so 13 mv commands later everything was (almost 2) fine.
In order to get rid of the message about missing secondary HDD, /etc/checklist has to be modified and the line:
/dev/w1.usr:User Area:
removed. Good thing this system included vi.
Part II should follow soon.
1 At first I tried the obvious routes: trying to mount it from Linux using the loop device and all sorts of old Unix filesystems I could think of. I also tried using the Xhomer emulator but it didn't include support for 2 HDDs, and anyway the partition structure is different.
2 Since these are backup and not installation diskettes, the separation between /usr and the rest is not on diskette boundary. This means that BACKUP8 still contains some files from /usr. This is solved by umounting /usr removing the files now visible under it, remounting it and extracting BACKUP8 again. Or, alternatively, moving the files in a temporary folder on the system partition and moving them again after remounting usr.
Published 2015-09-14 by Mihai Gaitos - contacthawk.ro