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: | initscripts | Assignee: | Miloslav Trmač <mitr> | ||||||
Status: | CLOSED ERRATA | QA Contact: | Brock Organ <borgan> | ||||||
Severity: | medium | Docs Contact: | |||||||
Priority: | medium | ||||||||
Version: | 4.0 | CC: | 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
Peter Bieringer
2005-03-10 13:24:17 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 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 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? Which 'this'? 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". Primary console is the *last* one on the command line, not the first one. So the primary console is serial in that case. 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 *** Bug 201456 has been marked as a duplicate of this bug. *** 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. 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. Is there a backport available for RHEL4 for testing? Whoops, shouldn't have put this on the FC5 update tracker. Will post a test patch shortly. Created attachment 139140 [details]
patch for this issue
Created attachment 141696 [details]
fixed patch for this issue
Here's an updated patch, removes s390 noise.
Patch commited to CVS, will be in 7.93.26.EL-1 or later. 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. Maybe. Can you check with strace why that command would fail? 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 OK, can you file that against kbd? Probably not going to change the redirect at this point. This is #143124 - maybe we shouldn't have backported the usage of (loadkeys -u ...) in UTF-8 locales. 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. 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? (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. Can you please point me to initscripts 7.93.29.EL-1? RHEL4 beta channel still contains 7.93.27. 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 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. 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 |