RE: revisiting tunables under Safe Mode menu option

> -----Original Message-----
> From: Julian Elischer [mailto:julian_at_freebsd.org]
> Sent: Thursday, March 01, 2012 1:28 PM
> To: Scott Long
> Cc: Devin Teske; freebsd-current_at_freebsd.org; 'Devin Teske'; 'John Baldwin';
> 'Andriy Gapon'
> Subject: Re: revisiting tunables under Safe Mode menu option
> 
> On 3/1/12 9:13 AM, Scott Long wrote:
> >
> > 1.  There are a number of knobs that can be manipulated to help enable a
non-
> booting system boot, which in turn gives a system administrator a fighting
chance
> to figure out what's wrong.  ACPI is (or was) one of these options, but there
are
> several others, and up until your re-write of the menu system, they were
opaque
> to the user.  I'd like to explore the idea of having a sub-menu that exposes
these
> knobs and allows them to be individually controlled, but still have an
upper-level
> option that turns them all-on or all-off for ease of use.
> >
> > 2.  There are a ton of kenv/TUNABLE knobs in any given kernel, and many of
> them are useful for sysadmins, even beyond just the 'safe mode' subset.  I'd
like
> to see a post-processor run on the kernel build that collects all of the kenv
knobs
> in that kernel and puts them into a file that can be read by the boot menu
> system.  The system then dynamically turns these into another sub-menu of
> knobs that can be manipulated.
> >
> > So, how hard would it be to have nested sub-menus?  Would (1) be something
> feasible to do in the near term?  Would (2) be feasible to do in the long
term?
> 
> not only collecting stuff from am kernel build but from a running system.
> it would be nice fro example to be able to influence the /etc/rc.d
> system by disabling some functions.
> e.g. come up but don't turn on the window system, or networking..
> We can disable a device but how about specifying a different default
> route than that in /etc/rc.conf?
> 
> if we extract the setup tha tthe machine eventually comes up to, we
> can allow that to be tuned as well.

I'm interested in which path you would choose amongst what I've seen mentioned
thus far:

a. Modifying the boot menu to offer fine-grain control over each aspect of Safe
Mode (wherein perhaps the Safe Mode option becomes a hook for a sub-menu rather
than its current setup as an "On"/"Off" toggle).

b. Keeping Safe Mode as an On/Off toggle, but shifting the fine-grain control to
userland (wherein loader(8) simply sets a safemode Boolean and the user is
dropped into something like single-user mode but with prompts for each feature)

c. Something else.
-- 
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.