After having empirically trudged through, and watching the efforts of others'
attempts, I thought I'd post my own summarisation of what I believe to be the
facts about booting MicroVax II's and VaxStation 3100/30 machines.

All my booting attempts have been attempted on two uvII's (16mb on each),
and two VS3100/30's (8mb each, and various SCSI drives).

My own experience has caused me to concede to the following for these platforms:

o	Booting from floppy on the VS3100 doesn't work.
o	Booting from floppy on the uvII doesn't work (floppy size issue).
o	Booting from tape doesn't work for both platforms.
o	Booting from SCSI disk on the uvII works fine, once you get a disk 
	built.
o	Booting from SCSI disk on the VS3100/30 doesn't work -- the ROM boot
	loads the netbsd boot, but the netbsd boot is unable to access the 
	built-in SCSI controller.  This is evidenced by the fact that there
	is absolutely no activity on the SCSI bus.
o	The boot block code is indeed broken -- you must type:
		boot dev(<parms>)file -<flags> -or- boot file -<flags>
	simply typing:
		boot file
	fails miserably.
o	The install program suggests you can setup the hard drive, and install 
	"packages," hence build a bootable/working system.  It appears, instead,
	that the sysinst program will merely accomplish generating a disktab
	entry for you, which you can then use in the UTILITY/shell option to
	disklabel, newfs, config your ether, ftp, then manually untar the
	binaries.

The summary of all this is:
	- You simply MUST netboot the uvII to create a system from scratch.  
	If you don't have a system to netboot from, you're out of luck.  
	Once the system is built as mentioned above (in the install comment),
	you can boot and go just fine.  NetBSD/vax STABILITY becomes the 
	issue now.

	- The VS3100 is a completely different issue -- you can certainly
	build a system here manually, just like the uvII, however I have
	yet managed to get the netbsd boot to access the drive.   THUS,
	you will forever have to netboot your kernel, as the bootblocks
	refuse to talk to the VS3100's SCSI.  Once the kernel is booted,
	it will access the SCSI just fine.  And now you'll be dealing
	with STABILITY, and *ALSO* the fact that the VS3100 is excruciatingly
	slow -- I get better overall performance on the uvII's over the
	VS3100 for the simple reason that the VS3100 has a horrid SCSI driver.

The purpose for all this ultimately is to hopefully save others the agony
of looking for confirmation that these are indeed issues not addressed in
the VAX port.  Hopefully this will a) provoke some definitive solutions/
information other than "you must netboot", or in the least confirm the 
issues; b) ingnite some resolution to the problems; or c) document these
issues somewhere to prevent futile attempts and individual resolutions
to the same.

Regards,
Scott-
--
Scott G. Akmentins-Taylor     InterNet: staylor@mrynet.com
MRY Systems			        staylor@idt.net, staylor@mrynet.lv
Westlake Village, CA  USA		
    (Skots Gregorijs Akmentins-Teilors -- just call me "Skots")
		----- Labak miris neka sarkans -----