svn commit: r228192 - head/usr.sbin/bsdinstall/scripts

[Ken Smith]

On Fri, 2011-12-02 at 14:18 +0100, Erik Cederstrand wrote:
> Den 02/12/2011 kl. 10.44 skrev Joel Dahl:
> 
> > On 02-12-2011  0:38, Ken Smith wrote:
> >> Author: kensmith
> >> Date: Fri Dec  2 00:38:47 2011
> >> New Revision: 228192
> >> URL: http://svn.freebsd.org/changeset/base/228192
> >> 
> >> Log:
> >>  Add a screen that asks if the user would like to enable crash dumps,
> >>  giving them a very brief description of the trade-offs.  Whether the
> >>  user opts in or out add an entry to what will become /etc/rc.conf
> >>  explaining what dumpdev is and how to turn on/off crash dumps.  The folks
> >>  who handle interacting with users submitting PRs have asked for this.
> > 
> > Hmm. Two things I'd like to bring up:
> > 
> > * Not specifically aimed at this commit, but my recommendation
> >  would be that we keep bsdinstall as simple as possible: installing FreeBSD
> >  should require a minimum amount of keystrokes. I realise this is just one
> >  more screen, but I hope we don't turn bsdinstall into a configuration
> >  utility where you can disable/enable just about anything in rc.conf.
> > 
> > * Mentioning future system crashes during installation feels awkward. Is that
> >  really what we want? I understand the problem and how this helps us with
> >  debugging, but this is like saying to users that what they are installing
> >  is unstable and that it'll eventuelly crash and die. I know we discussed
> >  ways of making crash dumps smarter in order to not fill up /var, which in
> >  turn would allow us to always have it on. Maybe that is the right path?
> 
> Maybe do away with the dialog, and then unconditionally enable textdump in rc.conf, adding the magic so textdump_enable="YES" sets up textdump with sane defaults.
> 
> Thanks,
> Erik
> 

This just implements what we seemed to settle on during the latest round
of several discussions we've had about this issue.  It comes up each
I've turned off dumpdev as part of converting head into a stable branch,
which is a step that got started way before I started being the one to
do it.  I'll be happy to see what I just added go away but the
pre-condition for that is infrastructure that prevents crash dumps
(of any form, including textdumps) from filling up /var if the user
turns out to be clueless about them and doesn't realize they should
pay attention to them.  At least as of the last time we discussed it
this knob I just added is a compromise between people who worry about
crash dumps going unattended and filling /var versus the people who
want us to be able to collect debugging information from the users
who submit PRs *and* provide an *extremely* easy way for said users
to turn it on/off.

I normally hate dragging what others do into the discussions but I
know of several Linux's that offer to enable kdump in their installer
so we're not alone in that regard.

-- 
                                                Ken Smith
- From there to here, from here to      |       kensmith at freebsd.org
  there, funny things are everywhere.   |
                      - Theodor Geisel  |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/svn-src-head/attachments/20111202/26885b96/attachment.pgp