Bug 711411

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.

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.

"racadm racrest" had no effect for me.

For informational purposes, I'm seeing the same behavior with the just-released 2.6.32-131.4.1.el6.x86_64 kernel.

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.

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

Aaargh.  My apologies: "2.6.32-131.4.1.el6.x86_64" above should be "2.6.32-131.6.1.el6.x86_64."

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>

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.

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.

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.

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.

The rd_NO_PLYMOUTH workaround works. Reassigning to plymouth.

what version of plymouth is installed?

what is the full kernel command line?

(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

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.

This bug no longer occurs; it can be closed.

Thanks.