Bug 150769

Summary: rc.sysinit do not set KEYTABLE on vt console if booted via serial console
Product: Red Hat Enterprise Linux 4 Reporter: Peter Bieringer <pb>
Component: initscriptsAssignee: Miloslav Trmač <mitr>
Status: CLOSED ERRATA QA Contact: Brock Organ <borgan>
Severity: medium Docs Contact:
Priority: medium    
Version: 4.0CC: notting, ohudlick, oliva, tao
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: RHBA-2007-0303 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-05-01 17:26:32 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 176344    
Attachments:
Description Flags
patch for this issue
none
fixed patch for this issue none

Description Peter Bieringer 2005-03-10 13:24:17 UTC
Description of problem:
If one boot a RHEL server via serial console, rc.sysinit doesn't set
KEYTABLE on vt console, even if this exists.



Version-Release number of selected component (if applicable):
initscripts-7.93.11.EL-1 and below (also RHEL3)

How reproducible:
Always

Steps to Reproduce:
1. Setup RHEL3 or RHEL4
2. boot normal
3. enable serial console by editing /boot/grub/grub.conf and /etc/inittab
4. boot, select serial on grub menu
    

Actual Results:  keymap on vt: after 2) keyboard layout is proper set,
after 4) it isn't

Expected Results:  even if booted via serial console, keyboard layout
on vt should be set

Additional info:

I think this is a very common scenario, were out-of-band access and
console access are dual-used.

fixes should be applied around here:

/etc/rc.d/rc.sysinit:

if [ "$CONSOLETYPE" = "vt" -a -x /bin/loadkeys ]; then
 KEYTABLE=
 KEYMAP=

Perhaps it's enough to extend the check 
   "$CONSOLETYPE" = "vt" -o "$CONSOLETYPE" = "serial"

and extend to something like 

 if [  "$CONSOLETYPE" = "vt" -o "$CONSOLETYPE" = "serial" ]; then
   if [ -x /bin/loadkeyss ]; then
    ...

    ...
   fi
 fi

Comment 1 Peter Bieringer 2005-04-18 11:36:47 UTC
I use now following patch to /etc/rc.d/rc.sysinit to solve this issue

@@ -272,7 +274,7 @@

 action $"Setting clock $CLOCKDEF: `date`" date

-if [ "$CONSOLETYPE" = "vt" -a -x /bin/loadkeys ]; then
+if [ \( "$CONSOLETYPE" = "vt" -o "$CONSOLETYPE" = "serial" \) -a -x
/bin/loadkeys ]; then
  KEYTABLE=
  KEYMAP=
  if [ -f /etc/sysconfig/console/default.kmap ]; then


Comment 2 Peter Bieringer 2005-04-26 09:11:48 UTC
Upper shown patch didn't proper work, but the following does:

@@ -272,7 +274,7 @@

 action $"Setting clock $CLOCKDEF: `date`" date

-if [ "$CONSOLETYPE" = "vt" -a -x /bin/loadkeys ]; then
+if [ \( "$CONSOLETYPE" = "vt" -o "$CONSOLETYPE" = "serial" \) -a -x
/bin/loadkeys ]; then
  KEYTABLE=
  KEYMAP=
  if [ -f /etc/sysconfig/console/default.kmap ]; then
@@ -292,9 +294,15 @@
   else
     echo -n $"Loading default keymap: "
   fi
-  loadkeys $KEYMAP < /dev/tty0 > /dev/tty0 2>/dev/null && \
-     success $"Loading default keymap" || failure $"Loading default keymap"
-  echo
+  if [ "$CONSOLETYPE" = "vt" ]; then
+    loadkeys $KEYMAP < /dev/tty0 > /dev/tty0 2>/dev/null && \
+      success $"Loading default keymap" || failure $"Loading default keymap"
+    echo
+  else
+    for i in 1 2 3 4 5 6; do
+      loadkeys $KEYMAP < /dev/tty$i > /dev/tty$i 2>/dev/null
+    done
+  fi
  fi
 fi


Comment 3 Bastien Nocera 2006-07-03 08:33:20 UTC
This doesn't work with those kernel options:
Kernel command line: ro root=LABEL=/ console=tty0 console=ttyS0,9600n8

Does the kernel get the TIOCLINUX ioctl wrong now? Bill?

Comment 4 Bill Nottingham 2006-07-05 17:52:50 UTC
Which 'this'?

Comment 5 Bastien Nocera 2006-07-06 09:29:51 UTC
Good point.
The keymap isn't set when booting up with a secondary serial console.

1. Boot your setup using those kernel options:
ro root=LABEL=/ console=tty0 console=ttyS0,9600n8

2. See that loadkeys isn't being started.

consoletype returns "serial" instead of "vt", even though the primary console is
"vt".

Comment 6 Bill Nottingham 2006-07-06 15:08:37 UTC
Primary console is the *last* one on the command line, not the first one. So the
primary console is serial in that case.

Comment 7 Peter Bieringer 2006-07-06 15:14:14 UTC
Yes, on my systems primary console is serial, grub config looks like:

kernel (hd0,0)/vmlinuz-2.6.9-34.0.1.EL ro root=/dev/md1 panic=60 vga=extended
console=tty0 console=ttyS0,38400n8

But this should rc.sysinit not prevent to set proper keytable.

My current simplified workaround is:

rc.local:

. /etc/sysconfig/keyboard
loadkeys $KEYTABLE.map </dev/tty0 >/dev/tty0

Comment 9 Bill Nottingham 2006-08-07 14:31:28 UTC
*** Bug 201456 has been marked as a duplicate of this bug. ***

Comment 10 RHEL Program Management 2006-08-18 17:47:39 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

Comment 15 Fedora Update System 2006-10-19 21:15:30 UTC
initscripts-8.31.6-1 has been pushed for fc5, which should resolve this issue.  If these problems are still present in this version, then please make note of it in this bug report.

Comment 16 Peter Bieringer 2006-10-22 20:42:08 UTC
Is there a backport available for RHEL4 for testing?

Comment 17 Bill Nottingham 2006-10-23 15:50:29 UTC
Whoops, shouldn't have put this on the FC5 update tracker. Will post a test
patch shortly.

Comment 18 Bill Nottingham 2006-10-23 15:54:10 UTC
Created attachment 139140 [details]
patch for this issue

Comment 19 Bill Nottingham 2006-11-20 21:01:12 UTC
Created attachment 141696 [details]
fixed patch for this issue

Here's an updated patch, removes s390 noise.

Comment 20 Bill Nottingham 2006-11-20 21:09:07 UTC
Patch commited to CVS, will be in 7.93.26.EL-1 or later.

Comment 22 Peter Bieringer 2007-01-31 09:37:04 UTC
Can it be that this patch causes such error message after reboot now:

Loading default keymap (de-latin1-nodeadkeys): [FAILED]

Currently, I have only access via serial console to the box, rc.sysinit was
patched with #19.

Comment 23 Bill Nottingham 2007-01-31 16:22:54 UTC
Maybe. Can you check with strace why that command would fail?

Comment 24 Peter Bieringer 2007-02-01 11:45:49 UTC
Command fails because of bugs in keymap! It would be no good idea to direct
stderr to /dev/null ...

# loadkeys -u de-latin1-nodeadkeys < /dev/tty0 > /dev/tty0; echo $?
Loading /lib/kbd/keymaps/i386/qwertz/de-latin1-nodeadkeys.map.gz
unknown keysym 'Meta_acute'
/lib/kbd/keymaps/i386/qwertz/de-latin1.map.gz:34: syntax error
syntax error in map file
key bindings not changed
1

# loadkeys -u de-latin1 < /dev/tty0 > /dev/tty0; echo $?
Loading /lib/kbd/keymaps/i386/qwertz/de-latin1.map.gz
unknown keysym 'Meta_acute'
/lib/kbd/keymaps/i386/qwertz/de-latin1.map.gz:34: syntax error
syntax error in map file
key bindings not changed
1

# loadkeys -u de < /dev/tty0 > /dev/tty0; echo $?
Loading /lib/kbd/keymaps/i386/qwertz/de.map.gz
0

Comment 25 Bill Nottingham 2007-02-01 15:46:25 UTC
OK, can you file that against kbd? Probably not going to change the redirect at
this point.

Comment 26 Miloslav Trmač 2007-02-01 15:48:39 UTC
This is #143124 - maybe we shouldn't have backported the usage of (loadkeys -u
...) in UTF-8 locales.

Comment 32 Ondrej Hudlicky 2007-03-29 16:59:36 UTC
This fix is available in the latest RHEL-4.5 Beta.  If the customer is
in a position to test the beta, please ask for testing feedback.
Thanks.

Comment 34 Peter Bieringer 2007-04-11 09:04:26 UTC
If comment #32 is related to a newer version of kbd, this doesn't help:

# rpm -qf `which loadkeys`
kbd-1.12-2.el4.4

I found this version in beta channel of RHEL4. Previously installed: kbd-1.12-2

# loadkeys -u de-latin1-nodeadkeys < /dev/tty0 > /dev/tty0; echo $?
Loading /lib/kbd/keymaps/i386/qwertz/de-latin1-nodeadkeys.map.gz
unknown keysym 'Meta_acute'
/lib/kbd/keymaps/i386/qwertz/de-latin1.map.gz:34: syntax error
syntax error in map file
key bindings not changed
1

# loadkeys -u de-latin1 < /dev/tty0 > /dev/tty0; echo $?
Loading /lib/kbd/keymaps/i386/qwertz/de-latin1.map.gz
unknown keysym 'Meta_acute'
/lib/kbd/keymaps/i386/qwertz/de-latin1.map.gz:34: syntax error
syntax error in map file
key bindings not changed
1

# rpm -qf /lib/kbd/keymaps/i386/qwertz/de-latin1.map.gz
kbd-1.12-2.el4.4
# rpm -qf /lib/kbd/keymaps/i386/qwertz/de-latin1-nodeadkeys.map.gz
kbd-1.12-2.el4.4

If there is any newer version available, where can I get it?

Comment 35 Miloslav Trmač 2007-04-11 10:34:21 UTC
(In reply to comment #34)
> If comment #32 is related to a newer version of kbd, this doesn't help:
No, it is about initscripts, fixing the original bug.

initscripts-7.93.29.EL-1 revert to the original RHEL4 behavior of not using -u.


Comment 36 Peter Bieringer 2007-04-11 10:54:44 UTC
Can you please point me to initscripts 7.93.29.EL-1? RHEL4 beta channel still
contains 7.93.27.

Comment 37 Ondrej Hudlicky 2007-04-11 13:05:38 UTC
You can download the packages here (let me know if you need other archs too) :

http://people.redhat.com/ohudlick/initscripts/initscripts-7.93.29.EL-1.i386.rpm
http://people.redhat.com/ohudlick/initscripts/initscripts-7.93.29.EL-1.src.rpm

Comment 38 Peter Bieringer 2007-04-11 13:21:43 UTC
Ok, at least the keymap loading is now successful:
Loading default keymap (de-latin1-nodeadkeys): [  OK  ] 

So I assume, that keymap on vt console is proper set, I can't test this for real
at the moment, because I'm far away from the system.

Comment 39 Red Hat Bugzilla 2007-05-01 17:26:32 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2007-0303.html