Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site cornell.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!vax135!cornell!george
From: george@cornell.UUCP (George R. Boyce)
Newsgroups: net.unix-wizards
Subject: MicroVAX II bootstrap program
Message-ID: <1366@cornell.UUCP>
Date: Wed, 4-Dec-85 18:13:27 EST
Article-I.D.: cornell.1366
Posted: Wed Dec  4 18:13:27 1985
Date-Received: Fri, 6-Dec-85 06:23:58 EST
Reply-To: george@cornell.UUCP (George R. Boyce)
Organization: Cornell Univ. CS Dept.
Lines: 27

This is actually a hardware question which I assume is independent
of the operating system... But I'll word it in Un*x terms.

The documentation on page 2-6 of the 630QB (MicroVAX II) tech manual
says that the primary bootstrap program "searches in order of
increasing unit number for a bootable unit...". Now I assumed
that means it should *stop* when it finds one but this does
not seem to be the case. Since 'newfs' by default puts a bootstrap
onto section a of a disk, I had my systems trying to boot from ra2a
and failing until one day I placed the boot program into the root
file system on ra2a. Now I know *why* all the documentation says
you *have* to type 'B DUA0' at the '>>>' prompt. I quickly used 
'installboot' (from a BSD4.2 distribution) to copy from /dev/null
to the bootstrap areas on ra1a and ra2a. Only then did my systems
reboot automatically (or with a 'B' command at the console prompt).

Question, is this a bug? It certainly seems so. How do I set up an
alternate root file system from which the system boots automatically
if the primary disk (ra0) goes offline? It would seem like I would
have to exchange the file systems on ra0 and ra2 but Ultrix treats
ra0 in a special way, right?

I asked this of the colorado support people and the last thing I heard
the guy mumble was that it would be a couple of weeks before he got
back an "i dunno" answer from the guys "back east". Well, it has been
a couple of weeks and I've not heard back from csc...