Installing 2.11BSD: Part I

With the MFM disks connected up, I thought I'd have a go at installing 2.11BSD Unix on the PDP-11. The distibution itself, along with many others, is available from the PDP Unix Preservation Society External link and can be installed using VTServer. The latter comes with a specially modified set of installation programs specifically for use with 2.11BSD as the originals of course don't support a virtual tape drive. As I already had VTServer set up, it was just a case of pointing it to the downloaded BSD files. This is explained in detail in the documentation accompanying VTServer, so I won't go into it here.

At first, it seemed like my previous experience with VTServer and RL02 drives was repeating itself. Try as I might, the disklabel program couldn't open the disk, complaining that it wasn't online. However, after reformatting the disk, things started to look better, and I was able to set up a few partitions. Next step is to run mkfs, then restore the root filesystem to disk. This also went without a hitch - it didn't take too long either, with the console running at 3.84kbps.

So with a fresh root filesystem, it was time to boot into Unix for the first time; quite a milestone, seeing as this was originally the whole point of getting the machine running in the first place. At the BSD bootloader's prompt, I tentatively typed:

: ra(0,0)unix

After a few moments, BSD started talking back:

2.11 BSD UNIX #115: Sat Apr 22 19:07:25 PDT 2000
    sms1@curly.2bsd.com:/usr/src/sys/GENERIC
 
ra0: Ver 4 mod 3
ra0: RD53  size=138672
 
phys mem  = 4030464
avail mem = 3806528
user mem  = 307200

Now, what's meant to happen next is that the init process starts, which in turn calls the autoconfig program and then starts a shell. The result should be a banner from init, a nice table of devices from autoconfig, then finally that all-important shell prompt. Instead the VTServer terminal spurted out a string of funny looking characters and ground to a halt. Between all the odd symbols, there was lurking what appeared to be the output I was expecting. Maybe switching to a real terminal would shed some light on the matter, but the disk wasn't yet bootable. Not to be deterred, I fished out the "ra" boot block from the BSD tree on the PUPS archive and used VTServer's copy program to write it to the start of the disk. It worked a treat! Booting with a real terminal, the results were much clearer:

June  8 21:24:50 init: configure system
 
hk ? csr 177440 vector 210 skipped:  No CSR.
ht ? csr 172440 vector 224 skipped:  No CSR.
ra 0 csr 172150 vector 154 vectorset attached
rl 0 csr 174400 vector 160 attached
tm ? csr 172520 vector 224 skipped:  No CSR.
tms ? csr 174500 vector 260 skipped:  No CSR.
ts ? csr 172520 vector 224 skipped:  No CSR.
xp ? csr 176700 vector 254 skipped:  No CSR.

Close, but no cigar. Interesting as it was, there was no shell prompt and therefore no running system. Most worryingly, however, the RUN light on the PDP's front panel had gone out. Supposedly the system had halted, but there were no error messages to suggest a cause.

Redumping the root filesystem didn't help at all; maybe I'd just had bad enough luck that something critical had coincided with a bad block on the disk? Nope, using the other RD53 gave exactly the same results, so why was that RUN light going out? It would flash off a couple of times during the boot sequence, but always came on again when something siginficant happened.

After much deliberation, I had a brainwave: maybe the system was waiting for an interrupt. As the devices seemed to be doing their stuff as far as interrupts were concerned, maybe I needed to look at the mother of all interrupts, as provided by the Line Time Clock (LTC). I remembered way back when I was running the ROM-based diagnostics that the clock test had failed. I'd shrugged it off at the time, but maybe I ought to look into it more thoroughly...

Back in the MXV11-B manual, I read over the bits about the clock signal again. As the module came with a wire-wrap installed to set its on-board LTC to a particular frequency, I'd assumed it was meant to be the source of this signal. I can now say it most certianly wasn't! Disabling the module's LTC by removing a jumper did the trick: the diagnostic test passed and I was feeling lucky, so I booted it up again.

Success was finally mine, confirmed by the following output:

erase, kill ^U, intr ^C
#

Next: Installing 2.11BSD: Part II >>