| From NetBSD.ORG!owner-port-vax Fri Jul  7 10:59:14 1995
| 
| the vax has dua0 which is a Maxtor XT2190 and a dua1 which is a
| dec rd53.

The Maxtor XT2190 is an RD54.

| racopy thinks dua0 is also a rd53, which is not the end of the
| world, just inconvenient; I'd have to relabel the disk manually
| (the kernel does recognize the actual size in sectors though
| when booting).

I believe the plan is for all root partitions to be the same size,
so the initial labelling isn't a big deal.

| Unfortunately, relabeling cannot be done while the device is
| mounted =).

I vaguely recall playing games by using another partition name,
but since I also ended up using two drives in the process I'm
likely remembering wrong.  I too had to relabel in order to
make a proper /usr partition on the RD54.

| Fortunately, I have a second drive, which is a rd53.
| Unfortunately, newfs-ing this drive results in a bunch of
| hard- and softerrors. I know that this drive has a few
| bad blocks, but not where the first superblock is stored.
| Shouldn't newfs map out the bad blocks ? If it does,
| it may be something else since the kernel sometimes even panics
| during access of this drive. Both drives are on the uda controller.

The assumption I think with RD (okay, MSCP) is that the controller
is supposed to deal with bad blocks etc.  A poor person's SCSI I
guess.  Alas I recall getting forced-bad blocks and needing to run
things like rabads to talk MSCP and revector the bad blocks.

Around here it seems the first sign of bad blocks and they simply
reformat the drive...  don't know if you've got the DEC tools to do it.

The bottom line with MSCP is you shouldn't encounter bad blocks if you
can help it - the SMD type drives (RM etc.) all use bad144 I think which
puts a higher level bad block table into the file system layer rather
than assuming the hardware deals with it.

| Then, it seems the kernel doesn't like 'vi'. Whenever vi is
| fired up (either manually or by 'disklabel -e') the kernel
| dumps, syncs and breaks out. Is this a known feature and a 
| quest to ban the usage of vi ? =)

I found both "vi" and before I had /usr loaded, "ed" caused panics.
The only way I'd encountered them as well (related to /tmp maybe?)

Which reminds me that I found the file systems stayed awfully clean
all the time regardless of whether they were or not 8-)  After each
panic the auto boot said "clean" and then went on to panic on the
partially allocated /tmp file - then I'd boot single user and fsck
to repair.