Re: boot menu option to disable graphics mode

2012-06-13 Thread Andriy Gapon
on 09/06/2012 19:17 Doug Barton said the following:
 If this were a problem we didn't already have a solution for, I'd be
 much more interested in what you're proposing.

I wonder if you were in the same mindset when you worked on service(8).
This is not to doubt service(8) usefulness, of course.  Just drawing a parallel.

 But in no particular order ...
 
 1. This is not something most users would have to do very often, if at all.

1. Let's not generalize.
2. It is not a coincidence that I started this thread on this mailing list.

 2. We have a variety of different login managers, several of which do
 things subtly differently, all of which would need ongoing support.

The solution as proposed of now does not require any support or modifications.
If people would be willing to implement additional support, then probably they
would be doing that because they would want to have that, and to support that.

 3. While the changes you're proposing sound simple, the startup stuff
 has some subtle interactions that we don't like to disrupt without good
 reason.

This is too vague to comment.

 It's also worth pointing out that if all you need is a shell at boot
 time, you can still do Ctrl-Alt-F1 to get that, without having to change
 anything.

Thank you for opening my eyes.  And sorry for using sarcasm again.
No, that's not what I want.  I want X to not start.

 And if you find yourself needing to prevent the login manager
 from starting more often than not, just disable it by default and start
 it with 'service blah onestart', or use startx.

I do need it that often that I'd have to inconvenience each boot.
But I also want convenience those time when I need it.

 My point being that this doesn't come with zero costs, and has very
 little benefit. That usually spells no in my book.

I understand your point.  On the other hand, I find the proposed change to have
measurable benefit and insignificant cost.  This is yes in my book.

Please also note that I am not asking you to do any work.

-- 
Andriy Gapon
___
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


Re: boot menu option to disable graphics mode

2012-06-13 Thread Doug Barton
On 06/13/2012 06:50 AM, Andriy Gapon wrote:
 on 09/06/2012 19:17 Doug Barton said the following:
 If this were a problem we didn't already have a solution for, I'd be
 much more interested in what you're proposing.
 
 I wonder if you were in the same mindset when you worked on service(8).
 This is not to doubt service(8) usefulness, of course.  Just drawing a 
 parallel.
 
 But in no particular order ...

 1. This is not something most users would have to do very often, if at all.
 
 1. Let's not generalize.

In order to make intelligent decisions about what changes to include and
what changes to exclude we have to measure both the costs, and the
benefits. Part of measuring the latter is knowing how many of our users
will benefit from the proposed change. The percentage of desktop users
that we have is (regrettably) a very small percentage of our total
demographic. The percentage of those users who would benefit from this
proposed change is smaller still. OTOH, every single FreeBSD user is
affected by changes to the boot process.

Furthermore, we already have a non-trivial public perception that
FreeBSD is a hobbyist OS, by and for the developers first and foremost.
I don't want to do anything that contributes to that perception without
good reason.

 2. It is not a coincidence that I started this thread on this mailing list.

I get that. But changes we make to the boot process aren't restricted to
the members of this mailing list.

 2. We have a variety of different login managers, several of which do
 things subtly differently, all of which would need ongoing support.
 
 The solution as proposed of now does not require any support or modifications.

Which solution are you discussing? Marcin's? I think his idea has a lot
of merit, but in reference to your particular use case (inhibiting X
from starting) it requires the user to know which particular knob (or
knobs) is responsible. That's not necessarily a show-stopper, and people
who are likely to need this are likely to be able to figure that out.

If you're talking about a different proposed solution, please clarify.

 If people would be willing to implement additional support, then probably they
 would be doing that because they would want to have that, and to support that.

The latter bit is what I'm most concerned about, especially long term.

 3. While the changes you're proposing sound simple, the startup stuff
 has some subtle interactions that we don't like to disrupt without good
 reason.
 
 This is too vague to comment.

That doesn't make the point invalid. :)  If we have a specific solution
that people are excited about, with patches, I'm happy to give it a more
detailed review (along with freebsd-rc@ of course).

 It's also worth pointing out that if all you need is a shell at boot
 time, you can still do Ctrl-Alt-F1 to get that, without having to change
 anything.
 
 Thank you for opening my eyes.  And sorry for using sarcasm again.

FWIW I realize that *you* know that already. What I'm trying to do is to
get an idea of what people want to accomplish, and make sure that we're
not reinventing the wheel.

 No, that's not what I want.  I want X to not start.

Thanks for clarifying.

 And if you find yourself needing to prevent the login manager
 from starting more often than not, just disable it by default and start
 it with 'service blah onestart', or use startx.
 
 I do need it that often that I'd have to inconvenience each boot.
 But I also want convenience those time when I need it.
 
 My point being that this doesn't come with zero costs, and has very
 little benefit. That usually spells no in my book.
 
 I understand your point.  On the other hand, I find the proposed change to 
 have
 measurable benefit and insignificant cost.  This is yes in my book.

I think that we disagree on both the relative costs and the relative
benefits. That's why I wanted to express my concerns so that others
could weigh in.

 Please also note that I am not asking you to do any work.

That sounds great in theory. However given the amount of time that I've
spent on refining the boot process, as well as trying to get the boot
time down as low as possible; and given the overwhelming importance of
the boot process to the OS generally, I have concerns about what you're
proposing. Just to be clear, I'm not saying, NO!, I'm saying that if
we're going to make changes in this area that we need to understand the
landscape very well before we move forward.

My other concern, to be perfectly blunt, is that this project not become
something where changes are made, and then when users report problems
with those changes they are told that they are on their own to come up
with the debugging, analysis, and/or fixes for those problems. If you're
saying that resources exist to support the design, implementation,
testing, commit to HEAD, support in HEAD, MFC(s), and support in the
older branches; then I'm glad to hear that. If we don't have those
resources, that's a factor we 

Re: boot menu option to disable graphics mode

2012-06-10 Thread Andriy Gapon
on 09/06/2012 17:45 Marcin Wisnicki said the following:
 On Thu, 07 Jun 2012 12:57:41 +0300, Gleb Kurtsou wrote:
 
 On (07/06/2012 11:56), Andriy Gapon wrote:
 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

 
 That's trivial to implement:
 
 http://lists.freebsd.org/pipermail/freebsd-current/2007-November/079241.html
 
 Still applies with minor reject that can be ignored or easily resolved.
 
 It also brings support for overriding path to rc.conf, allowing multiple
 boot configurations.

Hey, this is very nice, thank you!  And developed almost 5 years ago too.
I wonder what rc@ guys would think about committing this.

-- 
Andriy Gapon
___
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


Re: boot menu option to disable graphics mode

2012-06-09 Thread Jason Hellenthal


On Sat, Jun 09, 2012 at 07:28:50AM +0300, Andriy Gapon wrote:
 on 09/06/2012 04:16 Jason Hellenthal said the following:
  runlevel support might be a better solution so it does not differ that
  much from what other systems do and would be easy for people to grasp.
 
 Patches are welcome, as always.
 

I agree... ;)

How about generic runlevel support through kenv instead ?


Set runlevel by default to 3 , where just like any other system is
multiuser, and provide support in the rc scripts to look at kenv. While
documenting runlevel in init(8)'s man page since that is where most
people look for these things.


This way a we could define a while bunch of things around generic
runlevels and if perhaps runlevels ever make it into FreeBSD the support
for them will already exist.


-- 

 - (2^(N-1))
___
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


Re: boot menu option to disable graphics mode

2012-06-09 Thread Marcin Wisnicki
On Thu, 07 Jun 2012 12:57:41 +0300, Gleb Kurtsou wrote:

 On (07/06/2012 11:56), Andriy Gapon wrote:
 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
 

That's trivial to implement:

http://lists.freebsd.org/pipermail/freebsd-current/2007-November/079241.html

Still applies with minor reject that can be ignored or easily resolved.

It also brings support for overriding path to rc.conf, allowing multiple
boot configurations.

___
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


Re: boot menu option to disable graphics mode

2012-06-09 Thread Doug Barton
On 06/07/2012 11:10, Andriy Gapon wrote:
 on 07/06/2012 17:29 Doug Barton said the following:
 On 06/07/2012 02:57 AM, Gleb Kurtsou wrote:
 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

 Why not just:

 boot single user
 fsck -p
 mount -a
 $EDITOR /etc/rc.conf[.local]

 
 Ah, right.  Why provide a way to do something using one command at one prompt
 (or even toggling a menu option using a single keystroke) when you can already
 do the same using multiple commands at multiple places (and also trying to not
 forget to undo your changes later)...

I realize you were being sarcastic, but your question deserves an answer.

If this were a problem we didn't already have a solution for, I'd be
much more interested in what you're proposing. But in no particular
order ...

1. This is not something most users would have to do very often, if at all.
2. We have a variety of different login managers, several of which do
things subtly differently, all of which would need ongoing support.
3. While the changes you're proposing sound simple, the startup stuff
has some subtle interactions that we don't like to disrupt without good
reason.

It's also worth pointing out that if all you need is a shell at boot
time, you can still do Ctrl-Alt-F1 to get that, without having to change
anything. And if you find yourself needing to prevent the login manager
from starting more often than not, just disable it by default and start
it with 'service blah onestart', or use startx.

My point being that this doesn't come with zero costs, and has very
little benefit. That usually spells no in my book.

Doug

-- 

This .signature sanitized for your protection
___
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


Re: boot menu option to disable graphics mode

2012-06-09 Thread George Mitchell

On 06/09/12 10:37, Jason Hellenthal wrote:


On Sat, Jun 09, 2012 at 07:28:50AM +0300, Andriy Gapon wrote:

on 09/06/2012 04:16 Jason Hellenthal said the following:

runlevel support might be a better solution so it does not differ that
much from what other systems do and would be easy for people to grasp.

Patches are welcome, as always.


I agree... ;)

How about generic runlevel support through kenv instead ?


I've wondered whether it would be more BSD-sh to specify a way to tell
init, Tell /etc/rc to run the scripts listed by rcorder up until we get
NETWORKING.  (Or SERVERS or whatever dependency you need, or Stop
just before LOGIN.)  -- George Mitchell



Set runlevel by default to 3 , where just like any other system is
multiuser, and provide support in the rc scripts to look at kenv. While
documenting runlevel in init(8)'s man page since that is where most
people look for these things.


This way a we could define a while bunch of things around generic
runlevels and if perhaps runlevels ever make it into FreeBSD the support
for them will already exist.




___
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


Re: boot menu option to disable graphics mode

2012-06-08 Thread Aled Morris
On 7 June 2012 16:12, Garrett Cooper yaneg...@gmail.com wrote:

 I've run into _multiple_ scenarios where this isn't possible because
 the terminal settings are screwed up in single user mode, and had to
 resort to `sed -i '' `.


ed is the standard text editor

Aled
___
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


Re: boot menu option to disable graphics mode

2012-06-08 Thread Jason Hellenthal


On Thu, Jun 07, 2012 at 01:06:09PM +0300, Andriy Gapon wrote:
 on 07/06/2012 12:57 Gleb Kurtsou said the following:
  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
 
 I think that this is an excellent idea.
 

runlevel support might be a better solution so it does not differ that
much from what other systems do and would be easy for people to grasp.

-- 

 - (2^(N-1))
___
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


Re: boot menu option to disable graphics mode

2012-06-08 Thread Andriy Gapon
on 09/06/2012 04:16 Jason Hellenthal said the following:
 runlevel support might be a better solution so it does not differ that
 much from what other systems do and would be easy for people to grasp.

Patches are welcome, as always.

-- 
Andriy Gapon
___
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


Re: boot menu option to disable graphics mode

2012-06-07 Thread Konstantin Belousov
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.


pgpGQ5pmj2pYb.pgp
Description: PGP signature


Re: boot menu option to disable graphics mode

2012-06-07 Thread Andriy Gapon
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.

IMO.

-- 
Andriy Gapon
___
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


Re: boot menu option to disable graphics mode

2012-06-07 Thread Gleb Kurtsou
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

Thanks,
Gleb.
___
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


Re: boot menu option to disable graphics mode

2012-06-07 Thread Andriy Gapon
on 07/06/2012 12:57 Gleb Kurtsou said the following:
 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

I think that this is an excellent idea.

-- 
Andriy Gapon
___
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


Re: boot menu option to disable graphics mode

2012-06-07 Thread Doug Barton
On 06/07/2012 02:57 AM, Gleb Kurtsou wrote:
 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

Why not just:

boot single user
fsck -p
mount -a
$EDITOR /etc/rc.conf[.local]

___
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


Re: boot menu option to disable graphics mode

2012-06-07 Thread Garrett Cooper
On Thu, Jun 7, 2012 at 7:29 AM, Doug Barton do...@freebsd.org wrote:
 On 06/07/2012 02:57 AM, Gleb Kurtsou wrote:
 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

 Why not just:

 boot single user
 fsck -p
 mount -a
 $EDITOR /etc/rc.conf[.local]

I've run into _multiple_ scenarios where this isn't possible because
the terminal settings are screwed up in single user mode, and had to
resort to `sed -i '' `.
-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


Re: boot menu option to disable graphics mode

2012-06-07 Thread Garrett Cooper
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


Re: boot menu option to disable graphics mode

2012-06-07 Thread Doug Barton
On 06/07/2012 08:12 AM, Garrett Cooper wrote:
 I've run into _multiple_ scenarios where this isn't possible because
 the terminal settings are screwed up in single user mode, and had to
 resort to `sed -i '' `.

If that happens, a) report it! SUM is a very important part of FreeBSD,
and it needs to always work.

b) There were problems after the cons25 - xterm conversion that have
almost all been fixed nowadays

c) Try using a simpler shell, like /bin/sh, or even /rescue/sh

d) Obviously don't try to do SUM with a shell that is not compiled static

hth,

Doug

___
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


Re: boot menu option to disable graphics mode

2012-06-07 Thread Andriy Gapon
on 07/06/2012 17:29 Doug Barton said the following:
 On 06/07/2012 02:57 AM, Gleb Kurtsou wrote:
 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
 
 Why not just:
 
 boot single user
 fsck -p
 mount -a
 $EDITOR /etc/rc.conf[.local]
 

Ah, right.  Why provide a way to do something using one command at one prompt
(or even toggling a menu option using a single keystroke) when you can already
do the same using multiple commands at multiple places (and also trying to not
forget to undo your changes later)...

-- 
Andriy Gapon
___
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


Re: boot menu option to disable graphics mode

2012-06-07 Thread Lars Engels
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 like this idea.

rc(8) sets rc_fast=yes when the system boots, so it would be possible
to extend the scripts that start a desktop manager can use a code like
this:

if [ -n $rc_fast -a `kenv inhibit_gui 2 /dev/null` = 1 ]; then
echo Console only mode, $name not started
exit 0
fi

Then the user can still start the DM manually by issuing
service $name start.




pgp6ER3Vv2RPM.pgp
Description: PGP signature