Bug 597370

Summary: no getty is run on ttyS1
Product: Red Hat Enterprise Linux 6 Reporter: Jeff Moyer <jmoyer>
Component: upstartAssignee: Petr Lautrbach <plautrba>
Status: CLOSED NOTABUG QA Contact: qe-baseos-daemons
Severity: medium Docs Contact:
Priority: low    
Version: 6.0CC: notting, sassmann
Target Milestone: rcKeywords: Reopened
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-06-22 19:19:46 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Jeff Moyer 2010-05-28 18:25:05 UTC
Description of problem:
When booting with a kernel command line option to output to the serial console, no getty is spawned there.  Further, upon rebooting the system,  none of the reboot messages are sent to the serial console.

Version-Release number of selected component (if applicable):
RHEL-6 Beta 1

How reproducible:

Steps to Reproduce:
Actual results:

Expected results:

Additional info:

Comment 2 Petr Lautrbach 2010-05-31 09:21:00 UTC
It seems to be more kernel or initscripts issue for me.

What exactly do you have in your kernel command line? Which versions of upstart, initscripts and kernel? I've just tried this in virtual machine (libvirtd + kvm):

kernel /vmlinuz-2.6.32-25.el6.x86_64 ro root=/dev/mapper/vg_rhel6beta-lv_root LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=us console=ttyS1 init=/sbint/init --verbose crashkernel=auto

and everything is as expected, boot messages are printed, agetty on /dev/ttyS1 is spawned.

# initctl status serial DEV=ttyS1
serial (ttyS1) start/running, process 1665

1665 ttyS1    Ss+    0:00 /sbin/agetty /dev/ttyS1 9600 vt100-nav

Comment 3 Jeff Moyer 2010-06-01 13:50:22 UTC

# cat /proc/cmdline 
ro root=/dev/mapper/vg_megadeth-lv_root rd_LVM_LV=vg_megadeth/lv_root rd_NO_LUKS rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=us console=ttyS1,115200n8 console=tty1 crashkernel=129M@0M

# initctl status serial DEV=ttyS1
initctl: Unknown instance: ttyS1

Comment 4 Petr Lautrbach 2010-06-01 14:36:07 UTC
"console=ttyS1,115200n8 console=tty1"

Primary console should given last, see /etc/init/serial.conf:

# How this works:
# On boot, a udev helper examines /dev/console. 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, which
# triggers this script. It waits for the runlevel to finish, ensures
# the proper port is in /etc/securetty, and starts the getty.
# If your serial console is not the primary console, or you want a getty
# on serial even if it's not the console, create your own event by copying
# /etc/init/tty.conf, and changing the getty line in that file.

Comment 5 Jeff Moyer 2010-06-01 14:43:08 UTC
Even if this isn't the primary console, shouldn't a getty be spawned?  I may be wrong, but I'm fairly sure this used to be the case in RHEL 5.

Comment 6 Bill Nottingham 2010-06-02 15:51:26 UTC
No, the only automatically spawned gettys are for the primary console.

Comment 7 Petr Lautrbach 2010-06-21 11:42:53 UTC
*** Bug 606294 has been marked as a duplicate of this bug. ***

Comment 8 Stefan Assmann 2010-06-21 12:06:52 UTC
(In reply to comment #5)
> Even if this isn't the primary console, shouldn't a getty be spawned?  I may be
> wrong, but I'm fairly sure this used to be the case in RHEL 5.    

I just confirmed that a getty is spawned for every console specified in the kernel command line in RHEL5. See the following serial console output I just took:

EXT3-fs: mounted filesystem with ordered data mode.
type=1404 audit(1277107121.112:2): enforcing=1 old_enforcing=0 auid=4294967295 ses=4294967295
type=1403 audit(1277107121.374:3): policy loaded auid=4294967295 ses=4294967295
Bridge firewalling registered

intel-piketon-tpm-01.lab.bos.redhat.com login: 
Red Hat Enterprise Linux Server release 5.5 (Tikanga)
Kernel 2.6.18-194.el5 on an x86_64

intel-piketon-tpm-01.lab.bos.redhat.com login: root
Last login: Mon Jun 21 08:00:53 from ovpn01.gateway.prod.ext.phx2.redhat.com
root@intel-piketon-tpm-01.lab.bos.redhat.com:~> cat /proc/cmdline 
ro root=/dev/VolGroup00/LogVol00 loglevel=7 crashkernel=128M@16M console=ttyS0,115200n81 console=tty0

I think the whole purpose for specifying multiple consoles on the kernel command line is to have them spawned automatically. Looks like a regression to RHEL5 to me, reopening.

Comment 9 Bill Nottingham 2010-06-22 19:19:46 UTC
I just tested a RHEL 5 VM, and it does *not* behave as you describe out of the box.

Kernel command line: ro root=/dev/VolGroup00/LogVol00  console=ttyS0,115200n81 console=tty0 => no getty is spawned.

Kernel command line: ro root=/dev/VolGroup00/LogVol00  console=tty0 console=ttyS0,115200n81 => getty is spawned.

Perhaps your lab box had its configuration modified by hand? I'm not sure.
In any case, in my testing the RHEL 6 behavior is consistent with RHEL 5.

Comment 10 Stefan Assmann 2010-06-23 15:13:54 UTC
Hi Bill thanks for checking again,

I guess the reason Jeff and myself thought about this is that the lab machines are altered for serial console access by default. I looked at a newly provisioned RHEL5 machine and found
co:2345:respawn:/sbin/agetty ttyS0 115200 vt100-nav
in /etc/inittab, which is probably not there in the normal RHEL5 setup.