Bug 711411 - RHEL 6.6: Serial console login behaviour is erratic
Summary: RHEL 6.6: Serial console login behaviour is erratic
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: plymouth
Version: 6.6
Hardware: x86_64
OS: Linux
high
high
Target Milestone: rc
: ---
Assignee: Ray Strode [halfline]
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On:
Blocks: 767187 846704 1132252 1168402
TreeView+ depends on / blocked
 
Reported: 2011-06-07 12:37 UTC by Tom Kelliher
Modified: 2015-04-22 14:54 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-04-22 14:54:16 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Tom Kelliher 2011-06-07 12:37:45 UTC
Description of problem:

Running 2.6.32-131.2.1.el6.x86_64 kernel on a Dell PowerEdge R310 with iDRAC6 for serial console access results in not being able to logon to the serial console.

Version-Release number of selected component (if applicable):

2.6.32-131.2.1.el6.x86_64 kernel

How reproducible:

See below.

Steps to Reproduce:
1. Boot 2.6.32-131.2.1.el6.x86_64 kernel
2. Attempt to logon to the serial console through the iDRAC6.
  
Actual results:

Console accepts username fine.  While attempting to enter password, it appears that random keystrokes are being entered into the input stream (similar to baud, etc., mis-match errors).  Logon is refused.

Expected results:

Successful logon.

Additional info:

This behavior does not occur with the 2.6.32-131.0.15.el6.x86_64 kernel.

I saw a similar issue a couple weeks ago after an update.  It had turned out that the update modified one of the init .conf files and the system now had two getty's running on the iDRAC6's serial port.  Eliminating the second getty eliminated the issue.  (I have confirmed that there is now only one getty running.)

Comment 2 Tom Kelliher 2011-06-08 13:42:10 UTC
I have additional information to report:

1) The iDRAC6 involved is the Enterprise model.  The issue reported above occurs with both the current iDRAC6 firmware (1.70, Build 21) and the firmware with which the server shipped.

2) In single-user mode, the 2.6.32-131.2.1.el6.x86_64 kernel will not echo typed characters back to the serial console.  This behavior does not occur with the 2.6.32-131.0.15.el6.x86_64 kernel.

Comment 3 Chris Evich 2011-06-08 16:02:27 UTC
Re: kernel will not echo typed characters back to the serial console

I found this as well with DRAC5.  The reset command seems to fix it for me.

Comment 4 Tom Kelliher 2011-06-08 17:29:22 UTC
"racadm racrest" had no effect for me.

Comment 5 Tom Kelliher 2011-06-16 14:20:04 UTC
For informational purposes, I'm seeing the same behavior with the just-released 2.6.32-131.4.1.el6.x86_64 kernel.

Comment 6 Vincent Brobald 2011-06-27 14:18:54 UTC
Very similar problem here with iLO2 interfaces virtual serial port:

If deployed with RHEL 6.1, the serial interface doesn't work properly and it is not possible to type the password.

Same hardware deployed with RHEL 6.0 doesn’t exhibit this behavior.

Comment 7 Tom Kelliher 2011-07-13 15:35:32 UTC
I have two informational comments to add:

1) I'm seeing the same behavior with the just-released 2.6.32-131.4.1.el6.x86_64 kernel.

2) The installation of the 2.6.32-131.4.1.el6.x86_64 kernel resulted in the de-installation of the 2.6.32-131.0.15.el6.x86_64 kernel on my server.  Because I had been using the latter kernel in single user mode as a workaround, I re-installed the 2.6.32-131.0.15.el6.x86_64 kernel using 'yum install' and booted it to ensure that it still behaved as I would have expected in single user.  To my surprise, it exhibited the same behavior as the more recent kernels.

At this point, I pulled all the files related to the 2.6.32-131.0.15.el6.x86_64 kernel from a dump I had taken earlier this month and discovered differences in the initramfs-2.6.32-131.0.15.el6.x86_64.img (as reported by running cmp against the two files; see below) as distributed originally with the 2.6.32-131.0.15.el6.x86_64 kernel and the copy that was installed when I executed 'yum install' earlier today.  Substituting the original initramfs-2.6.32-131.0.15.el6.x86_64.img resulted in the behavior I had expected (i.e., the 2.6.32-131.0.15.el6.x86_64 kernel is now echoing typed characters).  All of the other files related to the 2.6.32-131.0.15.el6.x86_64 kernel were unchanged.

It would appear that the root of this issue is some change in the initramfs image that was made since the original release of the 2.6.32-131.0.15.el6.x86_64 kernel.


cmp output:
initramfs-2.6.32-131.0.15.el6.x86_64.img.mostRecent initramfs-2.6.32-131.0.15.el6.x86_64.img differ: byte 5, line 1

Comment 8 Tom Kelliher 2011-07-13 15:42:13 UTC
Aaargh.  My apologies: "2.6.32-131.4.1.el6.x86_64" above should be "2.6.32-131.6.1.el6.x86_64."

Comment 9 Jason 2011-07-22 12:54:39 UTC
I believe Bug 691374 is related, and it contains a workaround to this problem.

I'm having this same problem with RHEL 6.1 on all my servers: virtual (VMware ESXi 4.1) and physical (Dell Poweredge R510s, R610s).

$ sudo stty --file=/dev/ttyS0 -clocal
stty: /dev/ttyS0: unable to perform all requested operations

Once echo is disabled for typing my password, each of my characters turn into newlines until agetty is restarted.

cassdevb01 login: root
Password: <newline>
Login incorrect

login:  <newline>
Password:  <newline>
Login incorrect

login:  <newline>

Comment 10 Tom Kelliher 2011-07-22 21:44:40 UTC
As suggested in Bug 691374, as noted by Jason earlier today, adding rd_NO_PLYMOUTH to the kernel line in grub.conf resolved the serial line login/single user problem on my server.

Comment 11 RHEL Program Management 2011-10-07 15:36:51 UTC
Since RHEL 6.2 External Beta has begun, and this bug remains
unresolved, it has been rejected as it is not proposed as
exception or blocker.

Red Hat invites you to ask your support representative to
propose this request, if appropriate and relevant, in the
next release of Red Hat Enterprise Linux.

Comment 13 RHEL Program Management 2012-05-03 05:01:51 UTC
Since RHEL 6.3 External Beta has begun, and this bug remains
unresolved, it has been rejected as it is not proposed as
exception or blocker.

Red Hat invites you to ask your support representative to
propose this request, if appropriate and relevant, in the
next release of Red Hat Enterprise Linux.

Comment 14 RHEL Program Management 2012-12-14 07:28:13 UTC
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

Comment 15 Charles Rose (Dell) 2014-11-19 17:58:45 UTC
The rd_NO_PLYMOUTH workaround works. Reassigning to plymouth.

Comment 16 Ray Strode [halfline] 2014-11-20 16:51:33 UTC
what version of plymouth is installed?

what is the full kernel command line?

Comment 17 Tom Kelliher 2014-11-22 17:27:28 UTC
(In reply to Ray Strode [halfline] from comment #16)
> what version of plymouth is installed?

0.8.3-27.el6_5.1

> what is the full kernel command line?

kernel /vmlinuz-2.6.32-504.1.3.el6.x86_64 ro root=LABEL=ROOT rd_NO_LUKS rd_NO_LVM rd_NO_MD rd_NO_DM rd_NO_PLYMOUTH LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=us quiet console=tty1 console=ttyS1,115200 crashkernel=auto

Comment 18 Tom Kelliher 2014-11-22 17:51:43 UTC
Removing

   rd_NO_PLYMOUTH

from the kernel command line did NOT cause the problem reported originally to reappear upon rebooting.  This is the first time I've removed the directive since 2011-07-22.

Comment 20 Tom Kelliher 2015-03-18 20:48:14 UTC
This bug no longer occurs; it can be closed.

Comment 21 Ray Strode [halfline] 2015-04-22 14:54:16 UTC
Thanks.


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