On Thu, Jun 7, 2012 at 2:57 AM, Gleb Kurtsou <gleb.kurt...@gmail.com> wrote:
> On (07/06/2012 11:56), Andriy Gapon wrote:
>> on 07/06/2012 11:47 Konstantin Belousov said the following:
>> > On Thu, Jun 07, 2012 at 10:45:26AM +0300, Andriy Gapon wrote:
>> >>
>> >> It's long been a wish of mine to have an ability to decide at boot time
>> >> that a
>> >> system should boot in "console-only" mode. That is, that no graphics/X
>> >> applications like e.g. xdm/kdm/gdm are automatically started even when
>> >> they are
>> >> configured to do so.
>> >>
>> >> Here is my attempt at implementing that:
>> >> https://gitorious.org/~avg/freebsd/avgbsd/commit/96f7051d63d4286ef6f0196d241e7855338a6ed7?format=patch
>> >>
>> >> All the option does at boot time is setting of 'inhibit_gui' variable for
>> >> kernel
>> >> environment. I envision that this variable could be properly and
>> >> gracefully
>> >> handled in various startup scripts and/or application startup logic.
>> >> But to ensure that the option is always honored I've also added "ultimate
>> >> protection" to syscons that prohibits KDSETMODE/KD_GRAPHICS ioctl.
>> > This is too much, IMO. I understand why you may want to disable
>> > auto-start of login manager, but preventing a user from running X at all
>> > until she learns about kenv -u _and_ obscure code somewhere in the kernel,
>> > is unreasonable.
>>
>> A user doesn't have to select the option unless he needs to.
>> A "simple user" can just reboot without selecting the option to get back his
>> X.
>> A user doesn't have to learn anything about the code, just about kenv and
>> "magic" inhibit_gui variable.
>
> What do you think about adding generic support for overriding *_enable
> options in rc.conf?
>
> I'd like to be able to disable services at boot prompt, e.g.
> # set rc.slim_enable="no" -- overrides slim_enable="yes" in rc.conf
>
> Similarly rc.pf_enable="no"
>
> Then introduce x_enable knob (=yes by default) to disable login
> managers. User will be able to override this setting with
> # service xdm forcestart
It needs to be profiled, but I would be curious what the slowdown
would be for this change. Also, it sort of introduces a fun chicken
and egg problem with sourcing rc.conf files, like I discovered
recently at $JOB.
Thanks,
-Garrett
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
