problem with getty and telnetd

Vijay Padiyar vijay_padiyar at hotmail.com
Wed Feb 2 00:47:02 EST 2005


Hi

I am running a Linux 2.6.10 kernel on an MPC8260 target. I have Busybox 1.0
installed on top of the Linux kernel.

Problem 1: getty ------------------------------------------

I wish to put in place a login system on my system console (ttyCPM). For
this, I add the following line to /etc/inittab:

::respawn:/sbin/getty -L 57600 ttyCPM

On the subsequent login, I find that the system goes totally haywire! It
keeps displaying the login prompt again and again, and doesn't accept the
user ID and password I give, saying:

# /:
(none) login: root
/bin/sh: root: No such file.

I am unable to do anything after this, as the login prompt keeps popping up
everytime I enter a command. After a while the console gets stuck.

However, if I remove the above line from /etc/inittab and execute the getty
process directly from the command prompt, everything works just fine!

# /: getty -L 57600 ttyCPM
(none) login: root
password:

BusyBox 1.00 xxxxxxxxxxx (BusyBox string)

~ /: pwd
/root

Also, if I add a line to /etc/inittab as follows:

s1:2345:/sbin/getty -L 57600 ttyCPM

then upon the subsequent boot, I can see the getty process in the list of
running processes (by giving the ps command). However, I don't get any login
prompt.

Please explain what the problem could be. I don't have any other relevant
files in /etc. Do I need to add any other files (other than the getty entry
in inittab) for getty to work ok?

Problem 2: telnetd ------------------------------------------

To implement a telnet host on my target, I run the telnetd process from the
target. All is fine at first sight - I can connect from a remote host, the
login prompt is displayed fine (and WORKS here!) and it SEEMS as if I can
use the system normally.

HOWEVER, the problem comes when I try a ls command or try to view a file
with vi. If I do a ls on a directory with several files, the telnet terminal
on the remote host gets stuck after displaying a few entries. There's only
two ways to recover: close the terminal window on the host or kill the 'ash'
shell process on the target with 'kill -HUP process_id'.

Why could this be happening? Is there some buffer setting that I need to
address? Or something else that I'm missing? Please help!!!

Regards

Vijay Padiyar



More information about the Linuxppc-embedded mailing list