[CFT] Improve bsdinstall debugging

Hi all,

I've got a set of patches to apply to bsdinstall to improve
debugging.

Would like some testing and/or review feedback.

Patches are here (tarball form; apply in any order using
"svn patch"):

http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_debug/?view=tar
http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/?view=tar

The net effect of the patches is to:

1. Increase debugging to include commands and their output
2. Add descriptions in the debug output to show what we're doing
3. Provide better error reporting through dialog(1) (when interactive)
4. Implement debugging for things we may not expect to go wrong
5. Show function names in debug messages
6. Log values of important environment variables
7. Type-check arguments that need to be a specific type (e.g., integer)
8. Double-quote values that we can't guarantee to not contain $IFS
9. In the zfsboot script, catch any error from all 48+ fork-execs
10. Abort immediately on error if nonInteractive is set (zfsboot)
11. Implement `-D file' for bsdinstall to change BSDINSTALL_LOG
12. If the log file can't be written, print a single warning and don't log
13. Fix dangling participle "Begun" in log message to "Began"
14. Rewrite "docsinstall" module to not depend on the log file for error
NB: Also brings in bsdconfig package management API to docsinstall

Right now, it should be noted that I went to town on the zfsboot script
but I was a lot more sedate when patching the rest of bsdinstall.

The initial motivation for the debugging additions for the rest of bsdinstall
(besides zfsboot) was from flo_at_ whom was unable to deploy to his
Soekris boxen via PXE because /tmp was read-only when bsdinstall
started (and if it couldn't write to its log file, it just exited -- without perhaps
giving you a chance to run a script to bootstrap a writable /tmp). These
patches fixed flo_at_'s problem with bsdinstall not launching.

The motivation for the zfsboot debugging additions was a thread wherein
someone had some ad hoc graid metadata on a disk and we were unable
to (from the user interface *or* the debug logfile) diagnose the situation.
These patches fixed Johan's problems with that. Then... I decided to take
it one step further and centralize the debugging API -- currently stashed in
"zfsboot" for local usage... but with feedback from this thread, I'd like to then
uplift those into the library files and then pepper them throughout the rest
of bsdinstall to make its debugging as strong as that in "zfsboot".
-- 
Devin

_____________
The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.