getty/login problem

lord_fleg at iinet.net.au lord_fleg at iinet.net.au
Fri Nov 7 03:44:26 UTC 2008


hi Denys,

On Wed Nov  5 19:59 , 'Denys Vlasenko' <vda.linux at googlemail.com> sent:
>On Wed, Nov 5, 2008 at 7:29 AM,  lord_fleg at iinet.net.au> wrote:
>> when logging on via the serial port (ttyS1) i get prompted for the username when
>> i enter it and hit return it gets echoed back to me on the line below, and then
>> when i enter the password nothing happens and it eventually times out.
>> on entering the username/password a second time all is well.
>>
>> essentially the same problem described in message...
>>
>> http://www.busybox.net/lists/busybox/2004-August/012267.html
>
>Which version of busybox do you use?

1.12.1

>> so i tried turning off syslogd but this wasnt sufficient, i also
>
>You tried *what*?

i stopped syslogd from starting, ie, i commented it out of /etc/init.d/rcS.
not a long term solution i know :) i just wanted to see if (as suggested
in http://www.busybox.net/lists/busybox/2004-August/012267.html) it was
syslog that was causing the problem.

>
>> had to remove "console=ttyS1, 9600" from the kernel command line, which
>> seems to me to fit in with the advice given in the above message and does remove
>> the problem of the first login always failing.  however it means i dont
>> see the kernel boot messages.
>>
>> is there a better solution?  and if not could someone give me an idea
>> of how big a job this is to fix and where i should start?
>
>Does it help if you add this line in getty.c?
>
>        /* Open the tty as standard input, if it is not "-" */
>        /* If it's not "-" and not taken yet, it will become our ctty */
>        debug("calling open_tty\n");
>        open_tty(options.tty);
>        ndelay_off(0);
>+       ioctl(0, TIOCSCTTY, 1); /* another stab at maing it out ctty */
>        debug("duping\n");
>        xdup2(0, 1);
>        xdup2(0, 2);
>
>If this doesn't help, replace all "ioctl(0, TCSETS, tp);" with
>"xioctl(0, TCSETS, tp);" - this won't make it work but
>may give meaningful error messages instead of silently failing
>to work as intended.

ok, thanks for the suggestion, we're in the middle of a sprint (as in scrum)
right now so i'll have to wait till the next iteration before i can try this.
when i do i'll let you know what happens.
thanks again,
fleg

>--
>vda





More information about the busybox mailing list