From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-DE; rv:1.7.2) Gecko/20040806 Description of problem: keytables are not loaded at system startup if serial console is activated. /etc/rc.d/init.d/keytable is missing in package and older version is removed during update. Version-Release number of selected component (if applicable): kbd-1.08-10.2 How reproducible: Always Steps to Reproduce: 1.Install fresh system from Taroon Update 2 CD set with keyboard other than qwerty (for example a german keyboard). Or install system with previous CD sets and update kbd to kbd-1.08-10.2 . 2.Activate a serial console 3.Login on both serial and local console and try to type a 'z' or 'y' on both screens. Actual Results: keytable for (german) keyboard is not loaded if kernel parameter console=ttyS0,... is used. Keyboard mapping for local console is not set. Expected Results: Local console should use the selected keytable (german, ...). Additional info:
Copying the initscript from an older version solves the problem.
What happens if you use console=ttyS0 console=tty0?
We use console=tty0 console=ttyS0,57600n8r. With only console=tty0, everything works as expected. When we use the keytable initscript from a previous version of the kbd package and console=tty0 console=ttyS0,57600n8r, everything works as expected. The solution for the problem is simple. Provide a kbd package with a working initscript.
That's superfluous for 99% of cases, and actually causes bugs in the presence of some serial consoles.
In our case we have problems with the local Console (not the serial console) if /etc/rc.d/init.d/keytable is missing or not executed during bootup. The keyboard layout is not set correctly. OK: If keytable is called during bootup, the characterset for the serial console is mixed up and the local terminal has to be reset. Case 1: keytable is deaktivated (chkconfig keytable off, reboot) keyboard layout at serial console: OK (QWERTZ) characterset at serial console: OK (even german umlaut) keyboard layout at local console: QWERTY instead QWERTZ characterset at local console: seems to be us_US, german umlauts are missing although locale is set to de_DE.UTF-8 login with ssh: OK Case 2: keytable is aktivated (chkconfig keytable on, reboot) keyboard layout at serial console: OK (QWERTZ) characterset at serial console: OK (even german umlaut) keyboard layout at local console: OK characterset at local console: OK login with ssh: OK After keytable is executed the display at the serial console is screwed up: NFS statd starten: [ OK ] [ OK ]r starten: [ OK ] Starting keytable: à OK à à OK à audit subsystemà OK à I get TERM=linux for local and serial console in both cases. Especially for WS users with QWERTZ layout keyboards, working on their local console might be very annoying without the correct settings. There are still some of the rare species out there, who still know how to work with the keyboard. Not all are addicted to working with mice. By the way: Shouldn`t the system take care that it is aware of the type of console the user is using for login and switch to the appropriate settings for the session? The users choice of the language and keyboard settings should be respected and not superseded. OK: Perhaps superseeding is needed for some special cases. For example for serial consoles, but not for the local console. Oh: Which are the 99% of cases where keytable is superfluous? I don't think that 99% of RHEL3 users are using us_US. And: If keytable causes bugs, the reason for those bugs should be fixed. Discarding keytable is not the kind of bugfix I would prefer.
In the case where you are using only one type of console, keytable is superfluous. The only case it may be needed is when you have secondary consoles that aren't /dev/console.
And, as you stated, in that case it will break the serial console.