more thoughts on the (9.0beta2) installer

Dear all,

I set up a scratch box earlier this week (to check that openafs still 
works on beta2, and soon, HEAD), and took advantage of the opportunity to 
play around with the installer a bit.

First off, let me thank Nathan for putting in a huge pile of work to get 
things to where they are -- the new installer is pretty solid, and looks 
to be much more improvable than sysinstall.  Of course, I do have a few 
improvements of my own that I'd like to see find their way in ...

I was doing this on top of an existing installation of 7.4 (also for 
openafs testing, surprise surprise), so my first thought was to just reuse 
the existing partitions/slices.  However, this failed in the extracting 
stage with an error about not being able to create /var/empty (with 
permissions such and such; I didn't record it verbatim).  Now, installing 
over an existing system is somewhat risk-prone, as there may well be stuff 
sitting around that is unneeded or actively harmful, but this is not the 
way I would expect an installer to enforce a "don't install on top of an 
existing installation" rule.

When I was installing it, the ports.txz extraction felt very slow, slower 
even than portsnap extract.  However, in a later installation I did not 
take ports from bsdinstall and used portsnap post-install, and it also 
felt longer than I remembered :) .  So, maybe I (or someone else) should 
go back and actually time these things; I know that at least Thomas 
Mueller mentioned a portsnap preference on this list, and I suspect many 
other people do as well.  The point being that, perhaps the ports.txz 
collection need not be selected by default.

Having console messages overwrite the dialog is really annoying -- is 
there any way to have the installer run on VT4 or something, with console 
messages staying on VT0?  If I can start up a shell to go do stuff 
mid-installation, then we must be multi-user, so I think this is possible 
....  Our Debathena installer here at MIT (on top of the debian installer) 
does this, actually even further separating console output and the 
installer output to separate terminals and having another one dedicated 
for user interaction.

In the networking configuration, if I need to cancel out and try again, 
some settings (IP address/netmask/gateway) are saved and pre-filled for 
the next round, but others (e.g. distributions and resolver settings) are 
not.  This inconsistency feels unnatural -- it would be really nice to 
have consistency.  On the topifc of IP address and netmask and gateway, 
wouldn't it be enough to specify only one of the netmask and gateway, and 
determine the other accordingly?  (Well, most of the time, at least.)

In most of the installer, the new dialog is reasonable, with space 
select/deselecting and enter activating.  But the behavior in the network 
configuration and resolver dialogs is different -- it seems that I have to 
use the up/down arrows to move between the IP address, netmask, and 
default router fields; enter on any of them still performs the 'ok' 
action, even though 'ok' is not selected when any of those three fields 
are selected. I think there are several ways in which this situation might 
be improved -- it might be that one of 'ok' and 'cancel' is always 
selected, or tab might move between the three entry fields as well as 
ok/cancel, or enter on one field might move to the next.
(I didn't do anything with IPv6, so I don't know if similar issues are 
present there.)

After installation is finished, I would really like a stage where I have 
the option of removing the CD, prior to rebooting.  Otherwise I'll just 
end up at the installer again, unless I'm paying full attention to the 
machine and intervene in time.

The guided partitioner is pretty overwhelming.  Not so much as being 
handed raw fdisk/gpart/bsdlabel/etc. (hm, are there man pages available in 
the shell?  I didn't think to check) and having to deal, but there's still 
a lot going on.  Someone will need to sit down and try out a whole slew of 
combinations and document what is expected and furthermore what is 
recommended.  (Sorry, I'm booked solid for the next couple weeks.  It took 
me a couple days just to get to write this mail.)  In particular, this 
list of seven (?) options when I select a physical disk is pretty daunting 
-- I'm pretty sure I want either GPT or MBR (or maybe BSD), but I don't 
remember seeing a "this one is probably what you want" notice.

Once I'm in the interactive partitioner, I have no way of knowing what 
values are valid for the "type" other than essentially trial-and-error. 
(I think ivoras has also noted this?)  If there was a way to display a 
list of valid or commonly-used values, that would be quite helpful.  (When 
is "freebsd-ufs" used, versus just "freebsd"?)
Also, if I try to modify a partition that I've created, I don't have the 
ability to change the size -- I have to delete and recreate.  Now, I know 
that there are some cases where this is hard to deal with, such as when 
there are other partitions after the one in question, and resizing would 
require moving those other partitions further into the disk.  But if 
there's only one partition, or there's free space available, or I want to 
shrink, I would like to be able to do that.  (The solaris installer gets 
this right, if I remember correctly.)

It seems like the "auto" partitioner does different things depending on 
where I start from, yet it still prompts me for what disk to automatically 
allocate (!).  In particular, I think that if I have made a GPT or MBR on 
that disk, it will use that type for the auto-layout, but I'm not sure. 
It's not clear to me what it is actually supposed to be doing, and I can 
imagine that users might also become confused by it, in the absence of 
some explanation of what it does.
Now, if I give the autopartitioner a blank device to work with, it (on 
amd64) wants to use GPT.  With GPT, we can put labels on the partitions, 
and we probably should.  At this point in the installer, we should have a 
hostname, so we could use that and the mountpoint to create a label name.
Additionally, as Mike Tancsa (and others?) have noted, having a way to 
specify the full arguments to newfs (and friends) that's not "drop to a 
shell" would probably be useful.  It doesn't have to be super obvious, but 
even some of us expert-ish users still like to have the framework of the 
partitioner in which to work.

I also had some interesting experiences due to selecting the "US 
traditional UNIX" keyboard layout and expecting the standard US 8859-1 
layout, but that's mostly on me.  Though as a few people have pointed out, 
starting out on a default entry, or indicating what is (used to be) the 
default in some way, would probably be worthwhile.

Finally, I'll note that gcooper mentioned maybe tracking installer feature 
requests on http://wiki.freebsd.org/BSDInstall -- I don't see anything 
there at the moment, though, so I'm a bit reluctant to start adding my own 
desiderata there.  I do agree, though, that having a non-email place to 
track such things would be quite useful.

Thanks,

Ben Kaduk