>>     aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa     dddddddddddbbbbbbbbbb
>>                                   eeeeeeeeeeeeeeee
> sysinst doesn't want it that way - it is usually a bug waiting to
> happen

sysinst obviously doesn't want it that way.  My comment was more "there
needs to be a `yes, dammit, I know what I'm doing and any resulting
problems are my own lookout' knob".

Unless we're going to actually support untar-it-yourself installs,
which I thought wasn't the case.

>> - Despite having d and e both set to no-mount and no-newfs, and d
>>   set to size=0 offset=0 (this last because of the previous issue),
>>   something tried to do some command - fsck, I think - on the d
>>   partition (and of course it failed).  For some reason this didn't
>>   repeat when I retried; I don't understand why not.
> Did you do an 'update' or an 'install' ?

The run where that happened - I forget.

> The former will read /etc/fstab from the existing fs

There was no /etc/fstab.  a had a filesystem in it but it contained
nothing but the usual . and .. entries in its root.  e had a filesystem
containing the distribution sets (and some other guff, such as the
INSTALL.* files), but nothing anywhere near an installed system.

> and try to mount everything.  It probably ought to display the
> entries and their 'last mounted on' fields (in knowable) and force
> you to enable them is the 'last mounted' mismatches.

It did display /mnt in all the mount-point fields, and that was correct
for all of them assuming it was using superblock last-mounted-on
strings.

>> - When doing unmounted-FS installation, the installer prompts for a
>>   base directory and a path.  It would help if it gave some
>>   indication what it means by these; [...]
> The split is vital for NFS, and helps typing in other cases.

I can't really see how it helps in the unmounted-local-fs case; having
to specify a path foo/bar/sets as "foo" + "bar/sets" is...obscure, at
least.

When you say it's vital for NFS, I assume the "base directory" is the
path passed to the NFS mount and the "path" is the path relative to the
mount point?  Then I think it would be better to label them that way,
in the NFS case, and collapse them into a single path, in the local-FS
case.  (I don't remember what the other cases are....)

For NFS, I'm thinking something like

Host/address to mount:	192.168.33.44
Path to mount:		/export/distribution
Path within mount:	NetBSD-2.0_RC5/sparc/binary/sets

and for unmounted-local-fs, perhaps,

Device:			/dev/sd0f
Filesystem type:	ffs
Path within mount:	NetBSD-2.0_RC5/sparc/binary/sets

>>   It would also help if some of the setup on the path I had to take
>>   to retry remembered what I'd selected before (in particular, I
>>   think the partitioning screen should remember my no-mount
>>   settings).
> You have a coding stick :-)

True.  I may sit down and try to fix some of these myself sometime.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B