I recently (far too recently) upgraded my NetBSD/sparc 1.3.1 system to
1.3.2.  Everything did work quite well, but it was far from painless.
This is the first time I've upgraded any NetBSD system for quite some
time, and I was surprised at that the many "bugs" that seem to have
lingered on.  Some of the problems are of course generic to installation
and upgrades because of the vast amount of shared code in the procedures
but I'll focus only on the upgrade problems here.

Hopefully this is in time for something to be improved in the 1.3.3
release that seems to be in preparation.  I realize there's a massive
thread of disussion currently revolving on ways to re-work the
installation mechanisms, and of course there's also already a big gulf
between the way installs and upgrades can be done on the sparc and some
other architectures.

My first comment is that the INSTALL document is big, huge, ugly, and
misleading!  ;-)

Actually the worst part about it is that it tries to be to far too many
documents all in one.  It would be immensely better if it were split
into a README, an INSTALL, and an UPGRADE document.  It might even be a
good idea to split out other files too, such as one for HARDWARE, one
for OBTAINING, and maybe even separate INSTALL.tape, INSTALL.sunos,
INSTALL.netboot, etc. documents.  Having to print the whole thing out
and then constantly turn back and forth and add little annotations and
hints before one begins a procedure that should be mostly intuitive
(esp. for someone such as myself who has a rather deep understanding of
what's actually going on) is a real pain.  Trying to read through and
determine what actions are necessary on a step-by-step basis is
impossible.

Actually that paragraph sounds deja vu on re-reading -- perhaps I've
made similar comments in the past....

Anyway, to get into the actual upgrade process:

There were several places where I ended up looking through the various
scripts being run to confirm the intentions of ambiguous prompts and to
verify what actions would be taken before I dove on forward.

One example was the question about where the install sets were located.
I have effectively mirrored the FTP directories on my local machine, so
I specified the full pathname to the "sparc" sub-directory, since I knew
there were sets in both the "secr" and "sets" directories under there.
The resulting error message was even even more confusing because it
didn't contain the path I typed -- it said just:

	The directory \"\" does not exist, or does not hold any of the
	upgrade sets.

This is when I went to another machine and started reading sources.

The next surprise came when the full complement of sets I'd downloaded
into the "sets" subdirectory were not displayed (i.e. "x*.tgz").  I
didn't realize until just today when reading the "install.sub" script
that the default list to be displayed was hard-coded.  Luckily I did
discover that the additional sets could be selected regardless of
whether they appeared in the list.

Unfortunately multiple local directories for the sets cannot be
specified, so I still had to manually install the "secr.tgz" set.

There's also the wee bit of naming confusion between "sets" and
"savesets".  Neither is very meaningful on their own, especially the
latter.

Finally I was somewhat surprised when my disks became inexplicably busy
after the upgrade was finished and I was expecting a simple reboot.  Of
course a simple <CTRL-Z> and "ps" showed me it was just a silent "fsck"
running, but I'd have been much less aprehensive if I'd known that this
was going to happen before the reboot.

I'm willing to spend some time working one-on-one with any CVS committer
who's able to actually test some fixes for this miniroot installation
and upgrade process, especialy if it'll make 1.3.3.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>