Bug 621290
| Summary: | no getty on serial port when booting with console=ttyS? | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Jeff Layton <jlayton> |
| Component: | systemd | Assignee: | Lennart Poettering <lpoetter> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | high | Docs Contact: | |
| Priority: | medium | ||
| Version: | rawhide | CC: | jonas, lpoetter, metherid, michal, pebolle, plautrba, steved, zing |
| Target Milestone: | --- | Keywords: | Reopened |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | initscripts-9.20-1.fc14 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2010-09-14 23:22:52 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Fixed now upstream. Upload follows soon. mingetty is not suitable for serial lines and ttyS0 should be added to /etc/securetty to allow root login via this tty. systemd-7-1.fc14.x86_64 runlevel 1 is broken on serial console, there are running mingetty and sh# together: Enabling /etc/fstab swaps: [ OK ] Fedora release 14 (Branched) Kernel 2.6.35-3.fc14.x86_64 on an x86_64 (ttyS0) localhost login: Welcome to rescue mode. Use "systemctl default" to activate default mode. Retrigger failed udev events[ OK ] Starting monitoring for VG VolGroup: sh-4.1# 2 logical volume(s) in volume group "VolGroup" monitored [ OK ] Fedora release 14 (Branched) Kernel 2.6.35-3.fc14.x86_64 on an x86_64 (ttyS0) localhost login: Password: ls bin cgroup etc lib lost+found mnt proc sbin srv tmp var boot dev home lib64 media opt root selinux sys usr sh-4.1# Login incorrect Regarding mingetty vs. agetty we are waiting for https://bugzilla.redhat.com/show_bug.cgi?id=623685 The other issue reagrding starting /bin/sh and the getty on the same tty is now fixed in git master. Could you please provide link to git master commit at least commit id? It's actually a number of commits, but the most important one is this: http://cgit.freedesktop.org/systemd/commit/?id=5192bd1945f59254b3d260ded15dd9f2b8cc2de7 This has now been fixed in systemd v8: we properly use agetty and register things with initscripts' securetty tool. *** Bug 627776 has been marked as a duplicate of this bug. *** I can see no getty on serial console with systemd-8-3.fc14.x86_64. # cat /proc/cmdline 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 # ps ax | grep agetty 1071 pts/0 S+ 0:00 grep --color=auto agetty # grep ttyS0 /etc/securetty # echo $? 1 *** Bug 628824 has been marked as a duplicate of this bug. *** I sort of solved my problem. I added a symlink in /etc/systemd/system/getty.target.wants/ to /lib/systemd/system/systemd-auto-serial-getty.service This started an agetty on ttyS0 (/sbin/agetty -s ttyS0 115200 38400 9600) The problem is that I use console=ttyS0,115200 to boot but when agetty is started it uses 9600. I just updated to systemd-8-3.fc14.x86_64/systemd-units-8-3.fc14.x86_64 and the serial console doesn't come up. Yes. This was sort of working (starting a mingetty) and just recently broke again. Now no getty is started on the serial port at boot time. I added the symlink that Jonas did and got a serial console. The command line looks very odd though: root 1331 1 0 12:52 ttyS0 00:00:00 /sbin/agetty -s ttyS0 115200 38400 9600 The serial port seems to be set up correctly though (probably due to the -s): [root@rawhide ~]# setserial -a /dev/ttyS0 /dev/ttyS0, Line 0, UART: 16550A, Port: 0x03f8, IRQ: 4 Baud_base: 115200, close_delay: 50, divisor: 0 closing_wait: 3000 Flags: spd_normal skip_test ...I'm not sure what those numbers are intended to be however. Baud rates? If so, that doesn't appear to be valid syntax for agetty options. (In reply to comment #15) > root 1331 1 0 12:52 ttyS0 00:00:00 /sbin/agetty -s ttyS0 115200 > 38400 9600 > > The serial port seems to be set up correctly though (probably due to the -s): It looks that '-s' is just, luckily, ignored. There is no '-s' option on 'man agetty'. > ...I'm not sure what those numbers are intended to be however. Baud rates? If > so, that doesn't appear to be valid syntax for agetty options. This is supposed to be a comma-separated list. Again - see 'man agetty' for a description and details on 'baud_rate'. /etc/init/serial.conf used by upstart gets that right. A comment there says: # ... If a serial console is the # primary console (last console on the commandline in grub), the event # 'fedora.serial-console-available <port name> <speed>' is emitted and hardwiring any of these into systemd-auto-serial-getty.service looks like a really wrong thing to do. (In reply to comment #16) > It looks that '-s' is just, luckily, ignored. There is no '-s' option on 'man > agetty'. This is a new feature of agetty that has been added. The man page states: -s Try to keep the existing baud rate. The baud rates from the command line are used when agetty receives a BREAK character. > This is supposed to be a comma-separated list. Again - see 'man agetty' for a > description and details on 'baud_rate'. This is true, and that is what is specified in /lib/systemd/system/serial-getty@.service: ExecStart=-/sbin/agetty -s %I 115200,38400,9600 It seems that the commas are somewhat removed by systemd. > and hardwiring any of these into systemd-auto-serial-getty.service looks like a > really wrong thing to do. Not when using the -s option. They are, from what I understand, only used as a fallback when the current setting is useless. (In reply to comment #17) > (In reply to comment #16) > > It looks that '-s' is just, luckily, ignored. There is no '-s' option on 'man > > agetty'. > This is a new feature of agetty that has been added. The man page states: > -s Try to keep the existing baud rate. The baud rates from the > command line are used when agetty receives a BREAK character. Ah, ok. I looked at 'man agetty' from Fedora 13. > It seems that the commas are somewhat removed by systemd. Then one would expect that an excess of arguments will be dropped. So why you got a console running at 9600 as per comment 12 (and that with '-s' I am guessing)? I do not think that 38400 was misinterpreted as a terminal type. Or you got a different invocation than in comment 15? BTW - is systemd setting something reasonable for TERM? (In reply to comment #18) > Then one would expect that an excess of arguments will be dropped. So why you > got a console running at 9600 as per comment 12 (and that with '-s' I am > guessing)? I do not think that 38400 was misinterpreted as a terminal type. > Or you got a different invocation than in comment 15? BTW - is systemd setting > something reasonable for TERM? Systemd sets the TERM to vt100-nav. This is defined in serial-getty@.service and it is what I get when logging in using the serial console. I had a quick look at the agetty code and from that, it seems that agetty is started with only 3 arguments. (agetty -s ttyS0 115200,38400,9600) since it doesn't set the TERM variable to 38400. (The setenv() call has overwrite=1) So my best guess is that with -s it uses the current speed which is probably reset back to 9600 (Is this a default value perhaps?) An observation is that the kernel still prints it messages to the serial console using 115200 despite agetty running at 9600. However I can't interact with the kernel using the sysrq magic when agetty has been started. I guess this is related. Hmm, are you suggesting that the kernel uses 115200 but "agetty -s" settles on 9600 baud? If so, then that's a bug in agetty. Please open a bug against util-linux-ng! Note that it is agetty that replaces the commas by NULs in the command line, not systemd. The other issue, that systemd doesn't spawn a serial getty in some cases should be fixed in systemd git. Upload follows shortly. systemd-9-2.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/systemd-9-2.fc14 systemd-9-2.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update systemd'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/systemd-9-2.fc14 systemd-9-3.fc14, initscripts-9.18-1.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update systemd initscripts'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/systemd-9-3.fc14,initscripts-9.18-1.fc14 initscripts-9.19-1.fc14, systemd-9-3.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update initscripts systemd'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/systemd-9-3.fc14,initscripts-9.19-1.fc14 initscripts-9.20-1.fc14, sysvinit-2.87-5.dsf.fc14, systemd-9-3.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update initscripts sysvinit systemd'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/systemd-9-3.fc14,initscripts-9.20-1.fc14,sysvinit-2.87-5.dsf.fc14 systemd-10-1.fc14, initscripts-9.20-1.fc14, sysvinit-2.87-5.dsf.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update systemd initscripts sysvinit'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/systemd-10-1.fc14,initscripts-9.20-1.fc14,sysvinit-2.87-5.dsf.fc14 initscripts-9.20-1.fc14, sysvinit-2.87-5.dsf.fc14, systemd-10-2.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report. (In reply to comment #20) > Hmm, are you suggesting that the kernel uses 115200 but "agetty -s" settles on > 9600 baud? If so, then that's a bug in agetty. Please open a bug against > util-linux-ng! Has this ever been done? Recent rawhide kernels (kernel-2.6.36-0.3?.rc?.git?.fc15.i686) and recent util-linux-ng (util-linux-ng-2.18-4.fc15.i686) still seem to be unable to get a serial console working at 115200 baud. (In reply to comment #28) > Recent rawhide kernels > (kernel-2.6.36-0.3?.rc?.git?.fc15.i686) and recent util-linux-ng > (util-linux-ng-2.18-4.fc15.i686) still seem to be unable to get a serial > console working at 115200 baud. Strike that. ps shows the agetty listening on ttyS0 with: /sbin/agetty -s ttyS0 115200 38400 9600 This needs sending quite a number of breaks to establish a connection at 115200 baud. After logging in and logging out that cycle repeats again: send a number of breaks before a connection at 115200 baud can be established. Given that the kernel command line specifies 115200, there seems to be little reason to offer other speeds. Or am I missing something? Anyhow, is this an agetty bug? |
systemd doesn't seem to be set up to deal with a console on a serial port. I often run my KVM guests with serial consoles to make it easier to get to oops output. To do this, I usually boot with: console=ttyS0,115200 ...old-school init required an entry in /etc/inittab to deal with that. upstart detected this on the kernel command line and knew to run a getty on that serial port. systemd doesn't seem to start one at all. See /etc/init/serial.conf to see how it was done with upstart.