Date:        Tue, 24 Sep 2002 13:17:10 -0400
    From:        William Allen Simpson <wsimpson@greendragon.com>
    Message-ID:  <3D909DE7.8A02885@greendragon.com>

  | The install is quite different, and I found a number of problem areas.

This is not surprising, sysinst is still a rather primitive interface,
and still needs lots of fixing.

Unfortunately, for most of us here now, we're used to it, and have learned
to cope with how it works, and for us, it functions fine (or adequately
anyway).

For someone coming to it for the first time however, much of sysinst is
either unfathomable, or surprising (even to people who understand unix,
but worse for those who don't).

Whenever we get someone who has just used it for the first time, and is
actually willing to describe all of the problems they faced, we should
take careful note, treat every such report as a problem that we should
fix (metaphorical we, as I'm not really in a position to do it) and almost
never attempt to deflect the complaint (only perhaps when the user has
done something so amazingly contrary to common sense and what the on-screen
documentation has told them to do).

  | I'll write up some problem reports over the next few days,

Please do.

  | (A) INSTALL step 7: "wd1: no disk label" appeared in a random spot on 
  | the screen.

The "no disk label" kernel messages should probably all be expunged.
They're rarely useful for anything.   At the very least, there needs to
be an interface to cause the kernel to explicitly be told to be quiet
about them.   After all, installing NetBSD onto a system that has no
labels on its discs is hardly a rare event!   And sysinst is trying to
control what gets written to the screen, having  the kernel blathering
meaningless messages doesn't help (nor should sysinst be using TIOCCONS
to grab all kernel messages, as they it would have to try and parse them
because some, like "file system full" and the various I/O errors do
need to be reported to the user).

  | Not true.  OpenBSD is installed.

It really means "no NetBSD disk label" but is economizing on string space...

  | For reasons described below, mbrlabel needs a change that puts foreign
  | systems starting at i, rather than a.

This would probably be a reasonable idea, or start at 'p' and work down.

  | (C) INSTALL step 9: I selected Megabytes.  The resulting displays are 
  | nearly useless.  (I see that this has been mentioned recently.)

Yes, even though the disc partitioner has improved markedly over the past
year or so, it is still not good.   The unit selection stuff is really a
hangover from when that was used for input (before the ability to add unit
suffixes to numbers was added).  Then it made some sense to display in the
same units.

But it would be much better to display in both blocks & MB/GB (and cyls as
well, but perhaps only on sparc where they are needed), rather than to
have to select one or the other.

It should also be possible to simply move the boundary between two
partitions, without having to calculate new start/end positions for
both of them (not that it is very hard these days, but it is still
harder than this simple operation needs to be).

  | (D) INSTALL step 9: OpenBSD is listed as Unknown. 
  | 
  | Solution: update the tables.

I think those are kept small to save space in the floppy images.  There
are lots of unknown partition types that the install fdisk doesn't
understand.   I'd suspect that just better doc, "unknown is not a problem"
is needed here (people who have those kind of partitions probably know
what they are, not being able to translate the number to a name shouldn't
hurt).

But we should be able to create partitions with any type value, not just
one of the few the install system knows about.

  | (E) INSTALL step 9: the active partition needs an asterisk.  

Yes, that one has been pointed out before.  Its another of those "once you're
used to it, you don't see it as a problem" type things.   It should be
fixed.

  | (F) INSTALL step 10: the disklabel should be initialized with mbrlabel, 
  | before adding/recalculating NetBSD partitions. 

That's probably not a bad idea.   I've yet to use the new version that
has finally allowed existing partition tables to be used - until very
recently you had to start from scratch (every time, for a full install)
regardless of what the drive had on it before.

  | (G) INSTALL step 10: the disklabel should be initialized with existing 
  | disklabels, in this case from OpenBSD.

NetBSD doesn't know anything about other system labels.   That's possibly
asking a little too much.

  | Of course, NetBSD uses c and d differently, so it would wipe out those 
  | entries, but still would have saved time. (OpenBSD successfully used the 
  | NetBSD disklabel.)

FreeBSD can as well.   I don't know OpenBSD at all, but FreeBSD uses a
completely different label methodology.   NetBSD treats the drive as
NetBSD property, with exactly one label, its.   Some of the space can
just be "unused" (ie: for some other OS), but that's it.  There is exactly
one label, no more, no less (like a drive on SunOS/Solaris etc).

The DOS style label thing is used only for locating the NetBSD label (and
booting), as soon as that one is found, nothing else matters.

This does need to be well documented, probably in a section header "For
those familiar with other unix systems", so people coming to this who
have no idea what all this label business is about can ignore it (if you
don't know about different label kinds, etc, then the NetBSD system is
pretty easy to understand).

  | (H) INSTALL between 11 and 12: "normal set of bootblocks or serial 
  | bootblocks?" 
  | 
  | No explanation in INSTALL.  Picked "Normal", hope that is OK. 

It is.   This one has also been commented on before.   No-one who doesn't
already know what this is about understands this question.   This is more
than just a strong hint that it needs to be fixed.

  | (I) INSTALL between 11 and 12: asked for distribution sets.  This is 
  | step 19 in INSTALL.  In fact, this is a bad place to ask....
  | 
  | As I had problems finding my distribution sets (described later), I had 
  | to do this step over and over and over. 
  | 
  | It would be better to go back to the old way, at step 19, after the 
  | FTP/NFS/CDROM had been found, and only list those files present. 

I agree with that.   sysinst should look to see what is available, not
simply know what is required to exist.   That could be by reading the
directory (but that would not give info on what is required, what is
optional, etc), or by reading a file that is with the sets, which could
contain all of this info (along with the sizes required on various
filesystems (/ /usr /var /usr/X11R6 ...) after unpacking, etc).

  | On one of my passes, I accidentally left misc listed, and it aborted 
  | later, leaving me to re-do the entire install!  Very annoying!

Once you've done it enough times, you would have known how to avoid
having to re-do the entire install...

  | (J) INSTALL step 17 or 18: I was completedly unable to get either 
  | method to work on MSDOS.

Picking installation sets from an existing filesystem is another known
"difficult" (as in close to impossible) technique.   Most "how to get
around this" answers suggest creating a sub-shell from sysinst,
mounting the filesystem concerned manually, and then using the "install
from an already mounted filesystem" option.   But this is really not
good enough.   I guess most of us just know that either FTP, or CD
installs work trivially, and so ignore that part.

  | MOREOVER, when I NFS mounted MSDOS, it still couldn't find kern-GENERIC, 
  | which appeared as kern-gen.tgz on ls. 

Yes, sysinst knows what file names it wants.  MSDOS filesystems can't
represent all the names.   They used to be carefully crafted to avoid
that problem, but all the new kernel sets have forgotten about that
problem...   This one I suspect is just a straight out unarguable bug
(but having the set names read from a file would avoid it, as the file
put on a msdos filesystem could be edited to contain the msdos visible
names)

  | (K) INSTALL step 17: NFS worked from mounted ffs, with several problems. 
  | 
  | (K1) network setup used a classful netmask.

Not sure about that one, it defaults to that, but doesn't it ask what
you want to use?   Defaulting to classful is hardly unusual.

  | (K2) router and DNS setup (which was not needed, but will be used after 
  | installation), caused long waits for pings (several minutes), as I was 
  | offline at the time....  Two prompts about network failure.

You're lucky, a while ago, it wouldn't have let you past that stage at
all, ping failure meant data is bad, meant enter something different...
Fortunately that got fixed, so at least you can proceed now.

But in general, the "use after installation" info is best entered after
installation, that sysinst attempts to save your config for later use
is arguably a bug, it would be better if it didn't, and made it clear
that it wouldn't, and that the data entered is for installation only.

  | (K4) IPv6 auto didn't work, and required redoing everything.  

?   Didn't work how?   (Bill you know better than to say "didn't work"
as a bug report...)   Was there an IPv6 router sending RA packets?

  | (K5) For Host and Directory prompts, would prefer better prompt system 
  | more like network, instead of blank page with menu item.  Better yet, 
  | it could list possible directories after the mount, and allow menu 
  | choices. 

Yes, for it would be nicer if sysinst could descend through directories
until the sets are found, so it is possible to locate them if you simply
don't know where they are (which can easily happen, especially if someone
has been "creative" when making a CD ... I often put 3/4 different sets
of sets on the same CD, so I can pick which particular version I want to
install on a particular box).

  | (M) INSTALL step 19: "Before extraction begins, you can elect to watch" 
  | never asked.

Didn't it?   If it didn't, that's a step forward (and the doc should be
fixed).   I never understood why anyone would want to slow down their install
by a factor of 3 (or more) just so they could observe (but not read, it
is too fast) a list of meaningless file names scroll past...

  | (O) INSTALL step 19: "The next menu will allow you to select the time 
  | zone that you're in...."
  | 
  | time zones not alphabetical, hard to select, a multi-level menu would be 
  | better.

Yes, a hierarchical menu would be better, the TZ stuff is arranged to
make this pretty easy.   But the list was alphabetical the last time I
looked, what was wrong?

  | (P) INSTALL step 20: "Congratulations..."
  | 
  | Should reboot here, rather than taking back to the main menu.  Very 
  | confusing, I tried eXit, which was definitely not what I wanted!

No, this one I disagree with.   Instead it should perhaps ask if you
want to reboot, or return to the main menu (from which you can reboot,
indirectly).   But certainly not just go ahead and reboot (aside from
anything else, if you've been installing from a bootable CD, you wouldn't
have had time to remove it, and it could just reboot back to the CD
sysinst, which would truly be confusing).

kre