> I have some queries about the upgrade process for which there may well
> be a good RTFM answer, but from what I have seen in the documentation

From having just been through (or, to a slight extent, still in) the same
situation, here are my quick takes - there may be different and even
better answers from others.

> 1.  Can I assume that if I can boot from CD-ROM I can also
> upgrade that way?

Worked fine for me.  I downloaded the i386 install iso, burned it,
booted it, and the first thing I did in sysinst was drop to the shell.
Then I just made some changes to my partition layout (that I had been
wanting to make for a while) with fdisk and disklabel, newfs'd the new
partitions, wrote the new booter with installboot, and used pax to extract
the .tgz sets on the CD.  (Hint: study and/or print the man pages for
these tools before beginning--the 2.0 man pages, because some, especially
installboot, have different syntax and options from 1.6.2, and no man
pages are available in the minimal system that boots from the cd.) Actually I
only extracted a kernel, base.tgz, and etc.tgz, and then rebooted off the hard
disk; then I had all the base tools available while I extracted the
remaining sets.

If you have configured lots of things in /etc, you can skip extracting
etc.tgz and just keep what you have; I had only tweaked a few things,
so I opted to scorch the earth and then put my few tweaks back in.

> 2.  Just how much of 2.0 do I have to get installed to have a working
> system?   Leaving aside anything that involves compilation, can I
> assume backward compatibility for vi, groff, X and so forth (yes, I'm
> an ageing Unix hacker), or should I really be seeing this as a fresh
> installation necessarily?   It's just that I have work to do as well,
> and ideally I don't want surprises.   Without experience of
> undertaking previous upgrades, I'm wondering if I'm going to find I
> have to reconfigure numerous things I rely on (sendmail, named,
> NFS...)

If the kernel has COMPAT_16 turned on it should run binaries you keep
around from the old version, but if you're talking about standard tools
like vi and you haven't locally modified them (why would you?) I don't
see a reason not to go ahead and use the new ones you'll get when you
extract the 2.0 sets.

> someone point me to how I go about setting up a NetBSD ffs on a
> different fdisk partition from the current one?   Not something I've
> ever had to do before...

The basic answer: disklabel partitions (a - p) are defined by their start
and end sectors on the raw disk, period; nothing but convention really
links them to the MBR (fdisk) partitions, or says they have to be all
contained in one fdisk partition or another or can't straddle two or
be out in sectors beyond any fdisk partition at all (though if you
do something like that it's up to you to remember not to create a new
fdisk partition later that clobbers them :).  So all you need to do
is find out (from fdisk) the sectors corresponding to that fdisk
partition, and then define (with disklabel) a new disklabel partition
that occupies those sectors.

What I like to do to avoid embarrassing mistakes is maintain an entry
in /etc/disktab that describes my current partition layout.  If you
don't already have such an entry, disklabel -t will output one in the
proper format describing the current layout of the disk.  If I want to
add a partition, I do it by editing the entry in /etc/disktab,
convincing myself twice it makes sense, and then using disklabel -w to
impose it on the disk.  Then I know what's in the file is an accurate
record of what I've got, and there's a way to recreate it if the disklabel
ever gets trashed.  You can also just use disklabel in an interactive
mode, but I prefer this way.  Then you just 'newfs wd0i' and it gets the
parameters it needs from the label and makes the ffs filesystem.

> 4.  Is 2.0 going to want to alter the overall layout of my disk (from
> the label:
> 
> 16 partitions:
> #        size    offset     fstype  [fsize bsize cpg/sgs]
>  a:   2009889        63     4.2BSD   1024  8192    86   # (Cyl.    0*- 1993)
>  b:   3934224   2009952       swap                      # (Cyl. 1994 - 5896)
>  c:  40960017        63     unused      0     0         # (Cyl.    0*- 40634)
>  d:  78140160         0     unused      0     0         # (Cyl.    0 - 77519)
>  e:   9625392   5944176     4.2BSD   1024  8192    86   # (Cyl. 5897 - 15445)
>  f:   9625392  15569568     4.2BSD   1024  8192    86   # (Cyl. 15446 - 24994)
>  g:   1433376  25194960     unused      0     0         # (Cyl. 24995 - 26416)
>  h:  14331744  26628336     4.2BSD   1024  8192    86   # (Cyl. 26417 - 40634)
> 
> )   (and BTW why does it say 16 partitions? I've always wondered...)

Looks to me like you're not going to run out of space anywhere.
If it were me I might make / smaller and /usr bigger, or combine them in
one big fs and break out var on something writable and tmp on something
speedy and async, and sources, pkg, and pkgsrc on something big and
stable - but those are all judgment calls, the system will not require
you to change anything.  It says 16 partitions because you can define
up to partition p if you like.

-Chap