Subject: bin/5751: Various sysinst annoyances
To: None <email@example.com>
From: None <cgd@NetBSD.ORG>
Date: 07/13/1998 19:03:02
>Synopsis: Two recent installs showed some sysinst annoyances.
>Responsible: bin-bug-people (Utility Bug People)
>Arrival-Date: Mon Jul 13 19:05:00 1998
>Originator: Chris G. Demetriou
Kernel Hackers 'r' Us
>Release: NetBSD/i386 1.3.2, NetBSD/alpha 19980628 snapshot
NetBSD/i386 1.3.2, on a PC.
NetBSD/alpha 19980628 snapshot, on an AlphaStation 200 using serial console
via 'tip' from an xterm.
I recently had the pleasure of using sysinst to install a NetBSD/i386
1.3.2 system, and to install a relatively -current NetBSD/alpha
I noticed the following annoyances, and thought i'd document them for
y'all. Unfortunately, I don't have sysinst running in front of me
while writing this, so I might have gotten a few words/descriptions
slightly wrong. However, there's a kernel of bogosity underlying each
point. 8-) I would have filed them as individual PRs as is often
good form, but I think that would have been silly.
(1) When editing partitions, it'd be nice if the partition letter
would select the partition to be edited. I mean, why have this
arbitrary mapping between selection letters and partition letters.
They're usually the same for the first few partitions, after all! 8-)
Seriously, i made more than one mistake because of this. You have to
enter a letter to edit a partition, but not the name of the partition.
(2) There's rounding lossage in the partition creation code. When
partitioning a disk from scratch, you can specify (approximate) sizes
in megabytes, e.g. 128 for the first partition, 256 for the second,
128 for the third, etc. (what I like for root, swap and /var). But
then the partition list says that they are:
partition size offset
a 128 0
b 256 128
e 128 384
f ... 513 <---
It looks like sizes are automatically being rounded up to cylinder
boundaries. If you then go and try to resize your partitions, and
again enter sizes in (even) megabytes, the sizes you enter may leave
you with overlapping partitions. The answer is to either:
* either always use a megabyte as a megabyte, i.e. use 1024k
regardless of the cylinder size (don't round up), or
* redefine a "megabyte" in terms of a number of cylinders
Either of those produces a sensible (from the user's perspective),
reproducable (i.e., regardless of data entry mechanism) result. (In
the latter case, you should tell them what a "megabyte" really means,
though. 8-) Not rounding up to a cylinder boundary probably won't
work on all architectures.
(3) If you start the partitioning process again from scratch (without
restarting sysinst), it doesn't ask you for your unit preference.
Given that it asks everything else and you _did_ start the
partitioning process from scratch, it should.
(4) The default choice in the units-preference selection dialog should
be any units preference previously expressed. (e.g. If you say
"change units" and then hit return immediately, it should result in
the unit that you'd selected before.)
(5) after running newfs, the code syas "if you see error messages
above" or something similar. If there were any error messages, in all
likelyhood they scrolled off the screen while the user was doing
something else while waiting for the newfs to happen, so that's not a
very good/useful question. "detect the error codes yourself." The
user shouldn't be subjected to newfs output!
(6) NFS installation: right now it only takes server & mount path.
should also take a subdirectory. (server might have the bits in
a subdir, but not have -alldirs or the equivalent set. Some of us
can't easily change the NFS server configurations of the servers we
(7) after the "are the values ... network" prompt for network
configuration is OK'd, there can be a longer-than-expected delay with
no feedback. (On the i386 and alpha I tried this on, there was a
delay of several seconds. If I recall correctly, this only happened
the first time sysinst was run to this point after a reboot.) The
long delay made me hit return a few times, which in turn selected a
bunch of stuff that I didn't want. "feedback for operations which may
take a while is a good thing." at least say "please wait ..." to
indicate that the initial return was registered.
(8) It'd be good if the arrow keys worked. They didn't seem to, at
least when used on an alpha via serial console (tip from an xterm).
the escape codes seemed to go through, e.g. up-arrow would beep twice
then select 'A' (it's ESC-[-A), down-arrow would beep twice then
select 'B', etc. This was confusing, especially when i started out on
a menu, hit down-arrow, went to be, hit down-arrow again had nothing
happen, etc. 8-)
(9) it would be nice if sysinst provided a bunch of opportunities for
people to shell out and do things. For instance, right before
installing, I wanted to shell out and symlink /var to /usr/var. I was
able to do this by suspending sysinst, but that's Weird.
(10) control-Z shouldn't just suspend sysinst with no warning, and
control-C shouldn't just quit it (etc.). If possible, if they're to
have any action, they should say "are you sure you want to do
(11) I'm not sure if I mentioned this in a previous PR or message
somewhere, but in some cases (e.g. network configuration) there's no
good way to replace something you've already specified with "no
value". For instance, set a default router or domain name, then try
to go back and unset it without quitting. If you just hit return when
prompted, you get the default (what you previously set). Other
values, like <space> and "" don't always do the right thing. In
general, this type of issue would be best solved by creating text
fields, putting the default values in the fields, and letting the user
edit the fields. That way if they just hit return, they get the
default (the value initially in the field), but they can kill it, too.
Despite my long list of annoyances, I do have to say: it could suck
much, much more, and I think it's better than what was there before.
(I especially allowed to say that, because I wrote a lot of what was
there before. 8-)
Use sysinst as described above.