I run a server with serial console on COM1 (/dev/ttyS0) at 115200bps. Everything
seems to be all right, but when I try to run screen or mc, it hangs and I should
ssh to the server and kill it. I tried a lot of TERM and stty settings, but still cannot get screen and mc work. This server has dual-boot Gentoo Linux / FreeBSD 5.4, and in FreeBSD screen and mc on serial console work well.
I attach /boot/grub/grub.conf, /etc/inittab and output of emerge --info
f1 ~ # cat /boot/grub/grub.conf
#color green/black light-green/black
serial --unit=0 --speed=115200
terminal --timeout=3 serial console
title Gentoo Linux
kernel /boot/kernel-2.6.16 root=/dev/hda2 ro console=ttyS0,115200
#kernel /boot/kernel-2.6.16 root=/dev/hda2 ro vga=0x0F06
title FreeBSD 5.4
f1 ~ # cat /etc/inittab
# /etc/inittab: This file describes how the INIT process should set up
# the system in a certain run-level.
# Author: Miquel van Smoorenburg, <firstname.lastname@example.org>
# Modified by: Patrick J. Volkerding, <email@example.com>
# Modified by: Daniel Robbins, <firstname.lastname@example.org>
# Modified by: Martin Schlemmer, <email@example.com>
# $Header: /var/cvsroot/gentoo-x86/sys-apps/sysvinit/files/inittab,v 1.5 2005/12/22 02:03:23 vapier Exp $
# Default runlevel.
# System initialization, mount local filesystems, etc.
# Further system initialization, brings up the boot runlevel.
c1:12345:respawn:/sbin/agetty 38400 tty1 linux
c2:2345:respawn:/sbin/agetty 38400 tty2 linux
#c3:2345:respawn:/sbin/agetty 38400 tty3 linux
#c4:2345:respawn:/sbin/agetty 38400 tty4 linux
#c5:2345:respawn:/sbin/agetty 38400 tty5 linux
#c6:2345:respawn:/sbin/agetty 38400 tty6 linux
# SERIAL CONSOLES
s0:12345:respawn:/sbin/agetty 115200 ttyS0 vt100
#s1:12345:respawn:/sbin/agetty 9600 ttyS1 vt100
# What to do at the "Three Finger Salute".
ca:12345:ctrlaltdel:/sbin/shutdown -r now
# Used by /etc/init.d/xdm to control DM startup.
# Read the comments in /etc/init.d/xdm for more
# info. Do NOT remove, as this will start nothing
# extra at boot if /etc/init.d/xdm is not added
# to the "default" runlevel.
f1 ~ # emerge --info
Portage 2.0.54 (default-linux/x86/2006.0, gcc-3.4.5, glibc-2.3.5-r2, 2.6.16 i686)
System uname: 2.6.16 i686 AMD Duron(tm) processor
Gentoo Base System version 1.6.14
sys-devel/autoconf: 2.13, 2.59-r7
sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1
CFLAGS="-O3 -march=athlon -pipe"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/qmail/control"
CXXFLAGS="-O3 -march=athlon -pipe"
FEATURES="autoconfig distlocks sandbox sfperms strict"
USE="x86 berkdb bzip2 cli crypt ctype dba elibc_glibc fastbuild force-cgi-redirect ftp idn java kernel_linux libwww memlimit ncurses pam perl posix python readline session simplexml soap sockets spl ssl tcpd tokenizer udev userland_GNU userlocales xsl zlib"
Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTDIR_OVERLAY
I can confirm this on Sparc64 (Sun Ultra 2) using TeraTermPro from Windows or Minicom from another Sparc. Although I dont have to kill the mc process as I can still cancel this one with ctrl-c. But for the screen process I have to kill it or close/reopen the serial connection.
Can you try to recompile mc with USE="-ncurses" and tell us if it helps?
See above and post back. Thanks.
Created attachment 83219 [details]
So the serial console looks like. Mc should not be killed in ssh session, it can be stopped with Ctrl-C, but still does not work
I have recompiled mc with USE="-ncurses" and it does not help (see screenshot). I also need working screen.
OK, this apparently doesn't move anywhere, no idea what's causing this problem. Attach some debugging info (like strace) and reopen then.
Created attachment 83835 [details, diff]
Can you please test this patch? I've no idea what other implications it has except that mc starts over a real serial console (with the DCD line implemented).
Created attachment 83882 [details]
strace log for mc on a serial console
Created attachment 83884 [details]
strace log for screen on a serial console
Created attachment 83886 [details]
shell log with stty settings
I'm really wondering what I should do with those logs
I'm really wondering what I should do with those logs
Can you please submit the output files of "strace -ff -o mc-strace mc"? And does it work after applying the patch?
Yes, after applying the patch mc started to work on a serial console. I have also tested it in ssh and telnet sessions and it worked there too. But I cannot test mc on a virtual console right now because that machine has no monitor and keyboard attached and this is a server used in a project, so it should be always up.
Screen still does not work. I will upload it's strace -ff log today.
Created attachment 84054 [details]
strace -ff log for screen on a serial console
Created attachment 84055 [details]
strange second strace -ff log for screen on a serial console
I have also noticed that on a serial console screen gives the error message
Directory '/var/run/screen' must have mode 777.,
and after chmod 777 /var/run/screen it gives the message
Directory '/var/run/screen' must have mode 775. in ssh session, so I should run
chmod 777 /var/run/screen.
The maintainer of the screen ebuild will check in the patch not long from now. Please wait until then.
Any information on this?
I didn't understand what you mean. The maintainer of screen has not contacted me. I emerge --sync'ed yesterday and saw that mc was updated to version 4.6.1, and it also does not work on a serial console and your patch does not work with this version. So on a machine with a serial console I used to emerge "=app-misc/mc-4.6.0" with your patch applied manually.
Lanius: Please use the attached patch for screen.
(In reply to comment #19)
> Lanius: Please use the attached patch for screen.
Good luck w/ lanius. ;) exg, can you perhaps revbump mc w/ this patch?
Created attachment 85846 [details, diff]
Can you please verify that mc-4.6.1 works with this patch?
Yes, the patch for mc 4.6.1 works. The only thing left is to add this patch to portage. BTW, what attached patch for screen do you mean? I cannot find it.
fixed in mc-4.6.1-r1.ebuild.
This old bug seems to be back in mc-188.8.131.52, same symptoms and same patch works.
Assigning to current mc maintainers
So that would be what is known as a regression. Please file a new bug report.