Subject: bin/5751: Various sysinst annoyances
To: None <>
From: None <cgd@NetBSD.ORG>
List: netbsd-bugs
Date: 07/13/1998 19:03:02
>Number:         5751
>Category:       bin
>Synopsis:       Two recent installs showed some sysinst annoyances.
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    bin-bug-people (Utility Bug People)
>State:          open
>Class:          change-request
>Submitter-Id:   net
>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
		  that's close.
	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.
	See above.