Bug 150769 - rc.sysinit do not set KEYTABLE on vt console if booted via serial console
rc.sysinit do not set KEYTABLE on vt console if booted via serial console
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: initscripts (Show other bugs)
4.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Miloslav Trmač
Brock Organ
:
: 201456 (view as bug list)
Depends On:
Blocks: 176344
  Show dependency treegraph
 
Reported: 2005-03-10 08:24 EST by Peter Bieringer
Modified: 2007-11-30 17:07 EST (History)
4 users (show)

See Also:
Fixed In Version: RHBA-2007-0303
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-05-01 13:26:32 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
patch for this issue (1.51 KB, patch)
2006-10-23 11:54 EDT, Bill Nottingham
no flags Details | Diff
fixed patch for this issue (1.26 KB, patch)
2006-11-20 16:01 EST, Bill Nottingham
no flags Details | Diff

  None (edit)
Description Peter Bieringer 2005-03-10 08:24:17 EST
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 07:36:47 EDT
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 05:11:48 EDT
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 04:33:20 EDT
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 13:52:50 EDT
Which 'this'?
Comment 5 Bastien Nocera 2006-07-06 05:29:51 EDT
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 11:08:37 EDT
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 11:14:14 EDT
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 10:31:28 EDT
*** Bug 201456 has been marked as a duplicate of this bug. ***
Comment 10 RHEL Product and Program Management 2006-08-18 13:47:39 EDT
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 17:15:30 EDT
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 16:42:08 EDT
Is there a backport available for RHEL4 for testing?
Comment 17 Bill Nottingham 2006-10-23 11:50:29 EDT
Whoops, shouldn't have put this on the FC5 update tracker. Will post a test
patch shortly.
Comment 18 Bill Nottingham 2006-10-23 11:54:10 EDT
Created attachment 139140 [details]
patch for this issue
Comment 19 Bill Nottingham 2006-11-20 16:01:12 EST
Created attachment 141696 [details]
fixed patch for this issue

Here's an updated patch, removes s390 noise.
Comment 20 Bill Nottingham 2006-11-20 16:09:07 EST
Patch commited to CVS, will be in 7.93.26.EL-1 or later.
Comment 22 Peter Bieringer 2007-01-31 04:37:04 EST
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 11:22:54 EST
Maybe. Can you check with strace why that command would fail?
Comment 24 Peter Bieringer 2007-02-01 06:45:49 EST
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 10:46:25 EST
OK, can you file that against kbd? Probably not going to change the redirect at
this point.
Comment 26 Miloslav Trmač 2007-02-01 10:48:39 EST
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 12:59:36 EDT
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 05:04:26 EDT
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 06:34:21 EDT
(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 06:54:44 EDT
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 09:05:38 EDT
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 09:21:43 EDT
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 13:26:32 EDT
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

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