> Somehow it seems to have lots of problems with the 2nd drive
> installed though (I don't know if this has anything to do
> with the stuff on Ragge's todo-list).

If you get these "zero uba entry" messages (or similiar), then you 
see what ragge mentioned ...

> the vax has dua0 which is a Maxtor XT2190 and a dua1 which is a
> dec rd53.
> 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).

racopy dumps the miniroot.fs onto disk and thus the label residing
in the bootblocks of miniroot.fs; I think the label within miniroot.fs
is a rd53-label. This might be the reason for what you see. 

> Unfortunately, relabeling cannot be done while the device is
> mounted =).
> Fortunately, I have a second drive, which is a rd53.

You have two possibilities:
- use labeledit to edit the label in miniroot.fs before(!) using
  racopy to dump minirot.fs onto disk.
  [labeledit.c is a standalone-utility which should compile on
  any(?) NetBSD system. I tested it only on NetBSD/i386.]
- install onto your dua1 (which is an RD53), then boot from
  dua1 and use the new system to disklabel dua0.
  You seem to have done this already :-)

> 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.

AFAIK newfs doesn't remap bad blocks. bad144 is intended to do
that but I don't know if this tool exists/works for the vax-port.

> 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 ? =)

Same problem for me. I think it's a problem in the kernel (but I'm
not sure). It only/always happens if vi is used from uid 0,
other uids can use vi ...

Ciao,
	bertram