There are some recent postings which deserve some remarks, but instead
replying to each of them I'll put it all together. My excuses for lost
references and for quotes without author/context...

> The disktab for the RD53 also confused me.  There are so many
> overlapping seemingly pointless partitions.  Furthermore, the number of
> cylinders seemed wrong.  It was 963 instead of 1024.  Sectors per track
> should also have been 17 instead of 18.  Fortunately NetBSD itself was a
> bit smarter, so it detected and corrected the errors.

This (like other things i'll mention) is for historic reasons.
This is not meant as an excuse, i'm just stating a fact. (IMHO).

The /etc/disktab used in 4.3BSD tried to have on general setup
for all disks. They all used the same size for the root-partition
(15884 blocks, IMHO ways too small for today's systems), 'b' for swap,
'c' for the whole disk, and the additional partitions were meant
to support different layout policies, thus they're overlapping.
According to one's needs one would use this single disktab entry
to label all disks of one type and then newfs those and only those 
partitions which are needed...

Many of the disk in /etc/disktab are MSCP disks. DEC's MSCP protocol
is somehow similiar to SCSI in that 
1. disk's blocks are not addressed by a cylinder/head/sector triple but 
   by logical block numbers (LBN). From the driver's side of view the
   disk has no specific geometry, it's just a pool of disk blocks.
2. During formatting some sectors are reserved for internal information
   and there are some sectors reserved for bad sector mapping etc.
   Thus the logical size available doesn't match the physical size
   and geometry of the disk.
If one would still use the physical geometry for the disk label, then
one would lose some sectors since the reserved/hidden sectors are not
in cylinder-sizes. Thus is was common (and it makes sense!) to use
the prime factors of the available size and to combine them into some
"virtual geometry" in order to use all avaible sectors. 

> Then the trouble began.  References to ra(whatever) would just hang.  It
> didn't even touch the drives.  I had to figure out I needed to refer to
> mfm instead of ra by trial and error.

As ragge already mentioned the VS2000 uses the same disks which are
used eg. in uVAX-II, but the VS2000 has no MSCP-controler, thus the
above statements above MSCP and geometry don't hold for this machine.

VS2000's MFM-controller can't do LBN-addressing but only CHS-addressing
and thus relies on being given the correct physical geometry of the disk.
Since the name "ra" was already bound to disk connected to an MSCP
controler, a new name had to be used which was "mfm" in the beginning.
At these days it was unclear if the name "rd" will be used for Ram-Disks
or not. Once the name "rd" was known to be free, it was used for the
VS2000's MFM-disk in the kernel, but the boot program was not updated.

OTOH: Since the prompt displayed all the possible/supported names,
      at least one could guess which one to try/use...

> The installation process sucks.  The problem is, I guess, that they
> only get modified to suit the systems that the authors know about. 
> If you have developed a route for a particular system then knock it
> together and send it to ragge etc and I'm sure that they will add 
> the necessary stuff.

The original install instructions were meant to support installation
on machines supported at this time. Support to new machines was
added, and as long as the new machines are similiar to the "old" ones,
these install docs are still valid. If you compare the date of the
install doc with the approx. date support for a new machine gets
added you can guess if there might be differences or not...

Now esp. VS2000 and VAXstation in general are rather different from
eg. Q-Bus VAXen. Nevertheless most of the install instructions still
hold for these beasts! If we omit the trouble with "ra", "mfm" and "rd"
(BTW: this was my fault, sorry), I can't see big differences.

The disktab problems mentioned above are rather well known, but 
IMHO it makes no sense to mention all the possible problems one 
knows about in an install doc. If i tried to write down all the
potential traps and problems it'd take me days if not weeks.
(No pun intended!). Thus it's easier to wait until a problem
really arises instead of trying to cover every possible trap.

BTW: it's not uncommon that some of these well-known problems never
     arise just because other parts of the system have been changed.

> -> When creating file systems, I get a few messages like:
> -> command 0x5d completed with status 0x30
> -> command 0xa0 completed with status 0x30
> -> These are always in the same place.  Does this mean it hit a bad sector?
>  
>        This is a really good question. I also see these messages
> from time to time, and not always when doing newfs operations. Retrys
> perhaps? My gut feeling is that at least they are not hard errors...

I don't know offhand. But if you look into hdc9224.c and hdc9224.h
respectively all the commands and the bits in the status flag should
be declared/defined.

> newfs doesn't seem to have a "do a surface scan" option.  I know that
> the test 70 format on the VS2000 does indeed find bad blocks and
> redirect them.  However I can't see how NetBSD can be paying attention
> to that if it is using the whole disk.  The format actually sets aside a
> portion for replacements.

For the bad sector problem: VS2000 firmware does some kind of bad
sector replacement (I don't know if it's bad144-compatible). The
struct holding the on-disk information is declared in hdc9224.c,
but since my RD32 doesn't have any bad spots I could never check
how these blocks are handled and what happens if the controller
happens to access such a bad spot. There are methods to find the 
address of the replacement-sector, but I've no clue how to do it...

> First of all, I can't seem to find the boot block on the rx33 miniroot. 
> It seems that /usr/mdec is empty.  I tried to use /boot, but:
> disklabel: Bootstrap doesn't leave room for disk label
> It wants a really small file here.  I tried FTP searching for this
> thing, but I can't find it.

/boot doesn't hold the bootblocks! You can get the on-disk bootblocks
from disk/floppy by dd'ing the first 8K from the 'a'-partition. Since
the label is enclosed within the bootblock you'll copy/overwrite the
label also, thus you'll have to correct it later.

The disklabel program checks if the bootblocks about to be installed
have a hole (ie. zero filled portion) at the position which is reserved
for the label-information. If this hole doesn't exist, then disklabel
refuses to write these bootblocks (since installing would either mean
to clobber the label or to clobber the bootblocks). Since the /boot
program doesn't have this hole...

BTW: This is the reason why you can't install the bootblocks you've
     dd'ed from RX33 via disklabel. Either use dd to install the 
     bootblocks and restore the correct label after that operation
     or clear out the label-portion by hand and use disklabel.



Ok, I'll stop now. This has become rather long. Sorry!
Just my $0.02  (i've always wanted to write that ;-)
Ciao,
	bertram