Re: getty repeating too quickly on port `/dev/console', sleeping

--- Aleksey Cheusov <cheusovtut.by> wrote:

> >    login: Oct  8 00:00:36 init: getty repeating
too quickly on port
> `/dev/console', sleeping
> 
> Ok. Web known everything, well, almost everything.
> 
> I've fixed this by 
> changing
>     console "/usr/libexec/getty Pc"        
wsvt25  on secure
> to
>     console "/usr/libexec/getty Pc"        
wsvt25  off secure
> 
> Can anybody extend section 8.10 of NetBSD guide?
> http://netbsd.org/docs/guide/en/chap-x.html#chap-x-xdm

> 
> -- 
> Best regards, Aleksey Cheusov.
> 

Hi,

I think the problem is that /dev/console and /dev/ttyE0 are
really the
same physical hardware on your machine. That is, putting a
getty on
both when the console physically corresponds to ttyE0 will
cause
problems because two gettys will try to grab the same device
and one or
both will have problems. Similar problems will occur if the
machine is
headless and you have a getty entry for /dev/console and
/dev/tty00 for
example.

My soultion was also to exclude a getty for /dev/console:
this way you
can chage the console device when/if necessary without
having to change
this file and console messages will still go to the right
place. Also,
you will still be able to login on all terminals
regardless.
Disadvantage: log ons to the 'console' device will not
appear in
lastlog etc. as being on the 'console' (who cares?).

I agree the guide should be extended and this problem
explained: you
need to choose either a getty for between /dev/console and
the relevant
/dev/ttyEX or /dev/ttyXX terminals.


      Be smarter than spam. See how smart SpamGuard is at
giving junk email the boot with the All-new Yahoo! Mail at
http://mr
d.mail.yahoo.com/try_beta?.intl=ca

On Wed, Oct 10, 2007 at 08:23:00PM -0400, Gary Thorpe
wrote:
> 
> I think the problem is that /dev/console and /dev/ttyE0
are really the
> same physical hardware on your machine. That is,
putting a getty on
> both when the console physically corresponds to ttyE0
will cause
> problems because two gettys will try to grab the same
device and one or
> both will have problems.

There is a similar problem if you try to run the xconsole
window (or
anything else that steals writes to /dev/console).

If that is the problem then running the getty on
/dev/constty should
help (which is how sysinst manages to catch writes
/dev/console (including
kernel messages) and insert them into the curses output).
I've actually wondered whether it is possibly to exclude
writes to the
programs controlling terminal from the 'console output
stealing code',
and whether that would help!

	David

-- 
David Laight: davidl8s.co.uk