Description of problem: I'm not able to login via serial console. Version-Release number of selected component (if applicable): kernel-2.6.37-0.rc5.git2.1.fc15.x86_64 systemd-15-1.fc15.x86_64 How reproducible: Steps to Reproduce: 1. boot kernel-2.6.37-0.rc5.git2.1.fc15.x86_64 with console=ttyS0 2. try to login Actual results: I can write only first character of password, after that it looks like enter is sent and I see "Login incorrect" Expected results: Successful login/ Additional info: This doesn't happen with init=/sbin/upstart
If I change password to only one character I am able to log in but after that no input is shown. If I try to call 'stty sane' I see: [root@rawhide ~]# stty: standard input: unable to perform all requested operations
hmm, weird. Could you run "stty" on both the upstart and the systemd boot and compare? Is TERM= set to the same value? Is this a real hw serial terminal?
This is virtual serial console connected with 'virsh console' grub.conf: serial --unit=0 --speed=9600 kernel /vmlinuz-2.6.37-2.fc15.x86_64 ro root=/dev/mapper/VolGroup-lv_root rd_LVM_LV=VolGroup/lv_root rd_LVM_LV=VolGroup/lv_swap rd_NO_LUKS rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=us console=ttyS0 systemd.log_level=debug systemd.log_target=kmsg systemd: # stty speed 9600 baud; line = 0; min = 1; time = 0; -brkint -imaxbel -isig -icanon -iexten -echo # echo $TERM vt100 ttyS0 agetty process: /sbin/agetty -s ttyS0 115200 38400 9600 upstart: # stty speed 9600 baud; line = 0; -brkint ixoff -imaxbel -iexten -echoctl # echo $TERM vt100-nav ttyS0 agetty process: /sbin/agetty /dev/ttyS0 9600 vt100-nav I've tried to change TERM variable in /lib/systemd/system/serial-getty@.service:Environment to vt100-nav. $TERM is set to vt100-nav but it doesn't help. # echo $TERM vt100-nav ttyS0 agetty process: /sbin/agetty -s ttyS0 115200 38400 9600 kernel-2.6.37-2.fc15.x86_64 systemd-16-1.fc15.x86_64 util-linux-ng-2.18-5.fc15.x86_64
Hmm, the terminal parameters are really different. Weird. if you manually configure the same stty params on the systemd tty as they are set on upstart, does that fix issues? Use "stty -g > stty-settings" on the upstart boot to dump the stty settings to a file. Then load them via "stty `cat stty-settings`" on the systemd machine.
(A side note: my guess is that something is wrong with the agetty -s feature in recent u-l-ng)
I get same error message as in #c1: stty: standard input: unable to perform all requested operations stty-settings: 1500:5:cbd:83b:3:1c:7f:15:4:0:1:0:11:13:1a:0:12:f:17:16:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0
Hmm, this is really weird, not sure what might be going on here. I am puzzled.
I can reproduce this. The serial console gets into this weird state almost always as long as the VM has only 1 CPU. If the VM has more CPUs, then it happens rarely (but sometimes it still does). When the serial console is in the confused state, then "stty -F /dev/ttyS0 -g" shows: 100:5:cbd:a30:3:1c:7f:15:4:0:1:0:11:13:1a:0:12:f:17:16:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0 and stty (or rather the kernel) refuses to adjust its settings (tcsetattr() returns 0, but the settings are not really changed and this is what stty detects and says "unable to perform all requested operations").
Hmm, so we had reports on other distros that we ended up starting two gettys on the same terminal. Could that be the propblem here? I fixed those issues in v18. Could you retry with v18 (still in bodhi) and see if things work there? If not, could you check whether you have two gettys on the same tty?
no change for me before update: 957 tty6 Ss+ 0:00 /sbin/agetty tty6 38400 959 tty2 Ss+ 0:00 /sbin/agetty tty2 38400 960 tty5 Ss+ 0:00 /sbin/agetty tty5 38400 963 tty4 Ss+ 0:00 /sbin/agetty tty4 38400 966 tty3 Ss+ 0:00 /sbin/agetty tty3 38400 967 ttyS0 Ss+ 0:00 /sbin/agetty -s ttyS0 115200 38400 9600 968 tty1 Ss+ 0:00 /sbin/agetty tty1 38400 after update: 926 tty6 Ss+ 0:00 /sbin/agetty tty6 38400 927 tty2 Ss+ 0:00 /sbin/agetty tty2 38400 928 tty5 Ss+ 0:00 /sbin/agetty tty5 38400 929 tty4 Ss+ 0:00 /sbin/agetty tty4 38400 930 tty3 Ss+ 0:00 /sbin/agetty tty3 38400 932 tty1 Ss+ 0:00 /sbin/agetty tty1 38400 1045 ttyS0 Ss+ 0:00 /sbin/agetty -s ttyS0 115200 38400 9600 # systemctl | grep serial serial-g... loaded active running Serial Getty on ttyS0
hmm, ok, i think i figured it out. To prove my guess: could you boot with rd_NO_PLYMOUTH on the kernel cmdline? I presume it works fine then? Apparently we need to run the serial gettys after plymouth finished stopping, since otherwise plymouth will configure weird settings to the tty and lock them, so that other tools cannot change them anymore.
yes, it works with rd_NO_PLYMOUTH
OK, then it is fixed in current systemd git. Upload will follow shortly. Thanks for testing this so timely!