Bug 621290 - no getty on serial port when booting with console=ttyS?
no getty on serial port when booting with console=ttyS?
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: systemd (Show other bugs)
rawhide
All Linux
medium Severity high
: ---
: ---
Assigned To: Lennart Poettering
Fedora Extras Quality Assurance
: Reopened
: 627776 628824 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-08-04 13:22 EDT by Jeff Layton
Modified: 2014-06-18 03:40 EDT (History)
8 users (show)

See Also:
Fixed In Version: initscripts-9.20-1.fc14
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-09-14 19:22:52 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jeff Layton 2010-08-04 13:22:39 EDT
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.
Comment 1 Lennart Poettering 2010-08-06 06:09:01 EDT
Fixed now upstream. Upload follows soon.
Comment 2 Petr Lautrbach 2010-08-12 07:48:51 EDT
mingetty is not suitable for serial lines and ttyS0 should be added to /etc/securetty to allow root login via this tty.
Comment 3 Petr Lautrbach 2010-08-12 08:41:15 EDT
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
Comment 4 Lennart Poettering 2010-08-14 18:39:56 EDT
Regarding mingetty vs. agetty we are waiting for https://bugzilla.redhat.com/show_bug.cgi?id=623685
Comment 5 Lennart Poettering 2010-08-17 08:47:38 EDT
The other issue reagrding starting /bin/sh and the getty on the same tty is now fixed in git master.
Comment 6 Petr Lautrbach 2010-08-17 09:55:30 EDT
Could you please provide link to git master commit at least commit id?
Comment 7 Lennart Poettering 2010-08-17 13:09:19 EDT
It's actually a number of commits, but the most important one is this:

http://cgit.freedesktop.org/systemd/commit/?id=5192bd1945f59254b3d260ded15dd9f2b8cc2de7
Comment 8 Lennart Poettering 2010-08-26 17:52:48 EDT
This has now been fixed in systemd v8: we properly use agetty and register things with initscripts' securetty tool.
Comment 9 Lennart Poettering 2010-08-26 20:17:51 EDT
*** Bug 627776 has been marked as a duplicate of this bug. ***
Comment 10 Petr Lautrbach 2010-08-30 08:11:23 EDT
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
Comment 11 Jonas Jonsson 2010-08-31 10:20:37 EDT
*** Bug 628824 has been marked as a duplicate of this bug. ***
Comment 12 Jonas Jonsson 2010-09-01 07:39:08 EDT
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.
Comment 13 Zing 2010-09-01 09:22:26 EDT
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.
Comment 14 Jeff Layton 2010-09-01 12:48:12 EDT
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.
Comment 15 Jeff Layton 2010-09-01 12:56:33 EDT
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.
Comment 16 Michal Jaegermann 2010-09-01 13:28:46 EDT
(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.
Comment 17 Jonas Jonsson 2010-09-01 13:59:40 EDT
(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.
Comment 18 Michal Jaegermann 2010-09-01 14:41:11 EDT
(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?
Comment 19 Jonas Jonsson 2010-09-02 03:33:57 EDT
(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.
Comment 20 Lennart Poettering 2010-09-02 22:24:00 EDT
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.
Comment 21 Fedora Update System 2010-09-02 23:38:08 EDT
systemd-9-2.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/systemd-9-2.fc14
Comment 22 Fedora Update System 2010-09-03 12:44:10 EDT
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
Comment 23 Fedora Update System 2010-09-03 18:37:01 EDT
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
Comment 24 Fedora Update System 2010-09-07 23:18:22 EDT
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
Comment 25 Fedora Update System 2010-09-10 11:14:10 EDT
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
Comment 26 Fedora Update System 2010-09-14 00:28:34 EDT
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
Comment 27 Fedora Update System 2010-09-15 03:12:09 EDT
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.
Comment 28 Paul Bolle 2010-10-15 15:13:09 EDT
(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.
Comment 29 Paul Bolle 2010-10-15 16:02:02 EDT
(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?

Note You need to log in before you can comment on or make changes to this bug.