init/getty/login issue

[Denys Vlasenko]

On Friday 21 May 2010 04:28, John Williams wrote:
> Hi,
> 
> I'm running a pure BusyBox v1.14.3 rootfs on a PPC440 environment, and
> am seeing some strange behaviour at the initial login prompt.  Console
> device is a Xilinx uartlite (mainline driver 2.6.31-stable) on
> /dev/ttyUL0
> 
> Here's inittab:
> 
> ~ # cat /etc/inittab
> ::sysinit:/etc/rc.sysinit
> ::shutdown:/etc/rc.reboot
> ::ctrlaltdel:/sbin/reboot
> ttyUL0::respawn:/bin/getty -L 115200 ttyUL0 vt100
> ::respawn:/bin/syslogd -n
> ::respawn:/bin/flatfsd
> ::sysinit:/bin/inetd /etc/inetd.conf

Try experimenting with adding string "null" as tty
for last three lines, anstead of leaving it empty.


> Here's the last bit of my boot log
> 
> Sending select for 192.168.0.6...
> Lease of 192.168.0.6 obtained, lease time 259200
> adding dns 192.168.0.1
> Starting portmap:
> 
> Xilinx-ML507-PPC-lite login: root
> root
> Password:
> <looooong pause>
> <hit ^D>
> ~ # whoami
> root
> 
> Note how when getty gets the login name, it's being echoed to the
> console.  And, after I enter the password, it just sits until I hit
> ^D, then I'm logged in successfully.
> 
> Job control or termio issues maybe?

Looks like termio problem - something messed with console's termio.


> Some other observations -
>  * if I hit ^D immediately at the login: prompt, it pauses a few
> seconds (I think for init to respawn getty), then I see this:
> 
> Xilinx-ML507-PPC-lite login:  <Ctrl-D>
> getty: ttyUL0: read: No such file or directory

likely caused by:

                        /* Do not report trivial EINTR/EIO errors. */
                        if (read(STDIN_FILENO, &c, 1) < 1) {
                                if (errno == EINTR || errno == EIO)
                                        exit(EXIT_SUCCESS);
                                bb_perror_msg_and_die("%s: read", op->tty);
                        }

Need to account for the possibility of read of 0 bytes!
(I just fixed it in git)


> <wait a few seconds>
> Xilinx-ML507-PPC-lite login:
> 
>   This re-spawned getty works fine - no local echo of the username, no
> strange hangups etc.

Because it properly resets termio, overwriting broked setting.


>  * If I 'cat /etc/motd' at the end of my rc.sysinit script, the MOTD
> output gets truncated (last line incomplete or missing), instead it is
> interrupted by the login: prompt.  It's like there's some kind of race
> between the init scripts and getty.

Yes. Check your /etc/rc.sysinit that it does not start
something in background so that this "something" runs even
after /etc/rc.sysinit exits (and then init proceeds to start
respawn services); or all backgrounded processes are properly
isolated. Instead of simple:

command args &

do something like:

setsid command args </dev/null >/dev/null 2>&1 &

bacause bare "command args &" retains stdin/out/err of the parent
(which is /dev/console == /dev/ttyUL0 in your case)
and if it, or one of its children, plays with termio settings
of stdin/out/err, it affects it _globally_.


>  * If I don't set the kernel console bootarg (defaults to
> console=/dev/ttyUL0), then I get no kernel boot output, and also no
> output from my init scripts.  Nothing appears until the login prompt
> from getty, but in this case it *does not* suffer the issue I have
> described above.

Exactly.


>  * If I boot an identical init/rootfs environment for MicroBlaze,
> using the same uartlite console, everything works fine.  MicroBlaze is
> significantly slower than the PPC, so any race condition may be masked
> there.

Yes.

-- 
vda