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. > Thanks, > Scott > > _______________________________________________ > freebsd-current_at_freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org" > >Received on Thu Mar 01 2012 - 20:28:03 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:24 UTC