> > Interestingly, I had this exact same symptom and the "fix" was to specify
> > 4.2BSD when I used disklabel -i. This didn't seem to be a requirement,
> 
> Right... that's exactly what I did too. My disklabelling was
> all trial and error, but seems that's the right way to do things 
> sometimes :)
> 
> Is there any particular order for the partitions, should the 
> partition boundaries be placed in some special manner, what
> else should I know about the disk before I really try to 
> run NetBSD from them?

What I do is the following.  It usually always works.  If you don't
yet have a machine up, you have to do this manually, and maybe there
needs to be some protolabel files kept somewhere in the archives?
Maybe an example protofile needs to be included in the INSTALL.txt?

1.  disklabel -R device > device.label      (where device=sd0/1/2/3/4/5)

    That makes a working skeleton device protofile.  It probably will
    have only the c partition (entire drive) listed in its table, but,
    it should fetch reasonable cylinder/head/sector info for reference.

2.  edit the device.label

    Figure out the numbers of sectors per track, and use that to set
    partition boundaries so the end of a partition ends on a track.
    That usually leaves 1 unwritten sector at the end of each partition.
    Multiply heads x sectors/track x cylinders to get a value around
    twice what you need for a partition, then that should be about
    right (remember it is using 1/2 k blocks so you need double the
    expected sizing).

3.  devicea is the first partition (root)(usually 32mb but sometimes larger)
    deviceb is the swap partition  (size to suit for biggie ram usually at
                                    around ram x 2 or ram x 3)
    devicec is the entire drive (usually don't touch)
    deviced is the fourth partition (usually var and often 32mb or larger)
    devicde is the fifth partition (usually usr and as big as required or
                                    until the end of the disk).
    devicef is the sixth partition (if used... my VAXen are usually not
                   that well endowed with HD space, yet)

    auxillary drives usually only have one or two partitions, usually one
    mounted as /home or /wd1, /wd2, /wd3, or mounted onto usr/local or
    usr/src or something like that.  That partition is usually the ``a''
    partition, but sometimes something else.  Sometimes additional swap
    space is put at the head of auxiliary drives, sized to suit, usually
    32mb or up to ram sized should do.  Nothing is particularly magic
    on additional drives, but it is good karma to keep root/swap/usr/var
    on the first drive and squirrel away a spare single drive fstab in
    etc so you can bring it down to single drive, but full system use
    in emergency.

    BE CAREFUL to note the exact sizes in the protofile label.  Disklabel
    returns bogus sizes sometimes, and the head part of the label may
    have the sizes given as different from the bottom table values,
    AND may be different from the actual drive parameters.  Check to
    make sure they all are correct.  Any returned asterisks in the table
    indicates something is off.  Usually the head of the label is correct,
    and the table off, but sometimes both are off a bit.  This is where
    your actual calculations based upon the known drive parameters are
    important.

4.  disklabel -R -B device device.label

    That writes out the disk label from the protofile and adds boot blocks.

5.  disklabel -R -r device >devicecompare.label

    That writes out a new copy of the label to a second file that you can
    diff to see if the differences you made took correctly.  It also does
    not overwrite your protofile, in case something is still off and needs
    some fine tuning.

6.  Once you have good labels, PRINT THEM OUT and squirrel away a spare
    set for safekeeping.  It is good karma to make a label for each drive
    on the machine, and to gather up such labels as you may expect to use
    down the road.  Keep them handy.  Also, expand the disktab entry if you
    want it to include your version of labels.  Else, keep a copy of the
    protolabel file handy in root or in etc or somewhere, for reuse later.

I find the above works for me, and I had lots of burps getting my VAXen
going the first time, especially relearning ed for disklabels.

Anyway, others may have lots of good ways to do it too, and I would
appreciate hearing others' good karma on the genteel art of disklabeling.
 
> Seems like I might finally get a standalone VAX after all this
> time...

Great!  The more VAXen about, the better!

Thought... if we stack VAXen together in a closet, do they breed more
VAXen?  Mebbie a good way to clone spare machines?  (:+\\...

Bob