1043261 – plymouth breaks serial console on kvm guest

RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1043261 - plymouth breaks serial console on kvm guest

Summary: plymouth breaks serial console on kvm guest

Keywords:
Status:	CLOSED WONTFIX
Alias:	None
Product:	Red Hat Enterprise Linux 6
Classification:	Red Hat
Component:	plymouth
Sub Component:
Version:	6.6
Hardware:	Unspecified
OS:	Unspecified
Priority:	unspecified
Severity:	unspecified
Target Milestone:	rc
Target Release:	---
Assignee:	Ray Strode [halfline]
QA Contact:	Desktop QE
Docs Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+	depends on / blocked

Reported:	2013-12-15 13:59 UTC by Jan Stancek
Modified:	2017-12-06 10:34 UTC (History)
CC List:	4 users (show)
Fixed In Version:
Doc Type:	If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:	2017-12-06 10:34:40 UTC
Target Upstream Version:
Embargoed:

Attachments	(Terms of Use)

Description Jan Stancek 2013-12-15 13:59:39 UTC

Description of problem:
I have a kvm guest (named i386_kvm) with 2 serial ports (ttyS0, ttyS1). Plymouth is interfering with the latter, making it impossible to log in via "virsh console". 

1. KVM guest
-------------

Relevant part of guest XML:
  <serial type="file">
    <source path="/mnt/tests/i386_kvm_console.log"/>
    <target port="0"/>
  </serial>
  <serial type="pty">
    <target port="1"/>
  </serial><console type="file">
    <source path="/mnt/tests/i386_kvm_console.log"/>
    <target type="serial" port="0"/>
  </console>

i386_kvm # cat /proc/cmdline
ro root=/dev/mapper/vg_dhcp4798-lv_root console=ttyS0,115200 console=ttyS1,115200 rd_NO_LUKS LANG=en_US.UTF-8 rd_LVM_LV=vg_dhcp4798/lv_swap rd_LVM_LV=vg_dhcp4798/lv_root rd_NO_MD SYSFONT=latarcyrheb-sun16 console=ttyS0   KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM

i386_kvm # cat /etc/init/ttyS1.conf
# start ttyS1
start on runlevel [2345]
stop on runlevel [S016]
instance ttyS1
respawn
pre-start exec /sbin/securetty ttyS1
exec /sbin/agetty /dev/ttyS1 115200 vt100-nav

Plymouth has ttyS1 opened and is activately reading from it, which is presumably the reason why the whole input is not reaching getty:

i386_kvm # ps afx | grep plymouth
  110 ?        S      0:00 /bin/plymouthd --attach-to-session
 1884 pts/1    S+     0:00          \_ grep plymouth
 
i386_kvm # ls -la /proc/110/fd
total 0
dr-x------. 2 root root  0 Dec 15 08:31 .
dr-xr-xr-x. 8 root root  0 Dec 15 03:15 ..
lrwx------. 1 root root 64 Dec 15 08:31 0 -> /dev/tty1
lrwx------. 1 root root 64 Dec 15 08:31 1 -> /dev/tty1
lrwx------. 1 root root 64 Dec 15 08:31 10 -> /dev/ttyS0
lrwx------. 1 root root 64 Dec 15 08:31 11 -> /dev/ttyS0
l-wx------. 1 root root 64 Dec 15 08:31 12 -> /var/log/boot.log
lrwx------. 1 root root 64 Dec 15 08:31 2 -> /dev/tty1
lrwx------. 1 root root 64 Dec 15 08:31 3 -> [eventpoll]
lr-x------. 1 root root 64 Dec 15 08:31 4 -> pipe:[5891]
l-wx------. 1 root root 64 Dec 15 08:31 5 -> pipe:[5891]
lrwx------. 1 root root 64 Dec 15 08:31 6 -> /dev/ptmx
lrwx------. 1 root root 64 Dec 15 08:31 8 -> socket:[5896]
lrwx------. 1 root root 64 Dec 15 08:31 9 -> /dev/ttyS1

i386_kvm # strace -f -t -p 110
Process 110 attached - interrupt to quit
08:33:15 clock_gettime(CLOCK_MONOTONIC, {1096, 378922781}) = 0
08:33:15 epoll_wait(3, {{EPOLLIN, {u32=134944952, u64=134944952}}}, 4, -1) = 1
08:33:41 clock_gettime(CLOCK_MONOTONIC, {1122, 159190199}) = 0
08:33:41 poll([{fd=9, events=POLLIN|POLLPRI}], 1, 10) = 1 ([{fd=9, revents=POLLIN}])
08:33:41 read(9, "o", 1024)             = 1
08:33:42 epoll_wait(3, {{EPOLLIN, {u32=134944952, u64=134944952}}}, 4, -1) = 1
08:33:42 clock_gettime(CLOCK_MONOTONIC, {1123, 569203553}) = 0
08:33:42 poll([{fd=9, events=POLLIN|POLLPRI}], 1, 10) = 1 ([{fd=9, revents=POLLIN}])
08:33:42 read(9, "t", 1024)             = 1
08:33:43 epoll_wait(3, {{EPOLLIN, {u32=134944952, u64=134944952}}}, 4, -1) = 1
08:33:44 clock_gettime(CLOCK_MONOTONIC, {1125, 443173055}) = 0
08:33:44 poll([{fd=9, events=POLLIN|POLLPRI}], 1, 10) = 1 ([{fd=9, revents=POLLIN}])
08:33:44 read(9, "", 1024)              = 0
08:33:44 epoll_wait(3, {{EPOLLIN|EPOLLERR|EPOLLHUP, {u32=134944952, u64=134944952}}}, 4, -1) = 1
08:33:44 clock_gettime(CLOCK_MONOTONIC, {1125, 454963448}) = 0
08:33:44 ioctl(9, FIONREAD, [0])        = -1 EIO (Input/output error)
08:33:44 open("/dev/ttyS1", O_RDWR|O_NOCTTY) = 7
08:33:44 epoll_ctl(3, EPOLL_CTL_ADD, 7, {EPOLLERR|EPOLLHUP, {u32=134951872, u64=134951872}}) = 0
08:33:44 epoll_ctl(3, EPOLL_CTL_MOD, 7, {EPOLLERR|EPOLLHUP, {u32=134951872, u64=134951872}}) = 0
08:33:44 fstat64(7, {st_mode=S_IFCHR|0620, st_rdev=makedev(4, 65), ...}) = 0
08:33:44 ioctl(7, SNDCTL_TMR_TIMEBASE or TCGETS, {B9600 opost -isig -icanon -echo ...}) = 0
08:33:44 ioctl(7, SNDCTL_TMR_START or TCSETS, {B9600 opost -isig -icanon -echo ...}) = 0
08:33:44 ioctl(7, SNDCTL_TMR_TIMEBASE or TCGETS, {B9600 opost -isig -icanon -echo ...}) = 0
08:33:44 epoll_ctl(3, EPOLL_CTL_MOD, 7, {EPOLLIN|EPOLLERR|EPOLLHUP, {u32=134951872, u64=134951872}}) = 0
08:33:44 epoll_ctl(3, EPOLL_CTL_DEL, 9, NULL) = 0
08:33:44 epoll_wait(3, ^C <unfinished ...>
Process 110 detached

2. Host
--------
host # virsh console --devname serial1 i386_kvm
Connected to domain i386_kvm
Escape character is ^]

Red Hat Enterprise Linux Server release 6.5 (Santiago)
Kernel 2.6.32-435.el6.i686 on an i686

dhcp47-98 login: ro
Password:

PROBLEM
--------
"root" was entered, but only "ro" reached getty.

Workaround
-----------
Moving plymouth away makes the issue go away and I can log in to guest.

i386_kvm # mv /sbin/plymouthd /sbin/disable_plymouthd
i386_kvm # dracut -f
i386_kvm # reboot

host # virsh console --devname serial1 i386_kvm
Connected to domain i386_kvm
Escape character is ^]
...
dhcp47 login: root
Password:

# stty
speed 115200 baud; line = 0;
-brkint ixoff -imaxbel
-iexten -echoctl

Version-Release number of selected component (if applicable):
plymouth-0.8.3-27.el6.x86_64

How reproducible:
100%

Steps to Reproduce:
1. install kvm guest with 2 serial ports
2. open virsh console to ttyS1
3. try to log in

Actual results:
unable to log in, input is getting lost

Expected results:
login works on ttyS1

Additional info:

Comment 2 Jan Stancek 2013-12-15 16:27:22 UTC

I assume the problem here is that plymouth didn't stop. Looking at /etc/init/* I see a path where it should stop when prefdm starts. prefdm however starts only when all runlevel 5 services complete:
  start on stopped rc RUNLEVEL=5

This wasn't the case in my setup, one init script (rhts-compat) was running long enough for me to log in over ssh and run "virsh console".

Comment 3 Jan Kurik 2017-12-06 10:34:40 UTC

Red Hat Enterprise Linux 6 is in the Production 3 Phase. During the Production 3 Phase, Critical impact Security Advisories (RHSAs) and selected Urgent Priority Bug Fix Advisories (RHBAs) may be released as they become available.

The official life cycle policy can be reviewed here:

http://redhat.com/rhel/lifecycle

This issue does not meet the inclusion criteria for the Production 3 Phase and will be marked as CLOSED/WONTFIX. If this remains a critical requirement, please contact Red Hat Customer Support to request a re-evaluation of the issue, citing a clear business justification. Note that a strong business justification will be required for re-evaluation. Red Hat Customer Support can be contacted via the Red Hat Customer Portal at the following URL:

https://access.redhat.com/

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