OpenSuSE 12.3 kbd service failing at boot

An install of OpenSuSE 12.3 (but upgraded from 11.2) displays this message

...
Starting Firewall Initialization (phase 2 of 2)                        done
Master Resource Control: runlevel 3 has been                           reached
Failed services in runlevel 3:                                         kbd
Skipped services in runlevel 3:                               irq_balancer

Welcome to openSUSE 12.3 "Dartmouth" - Kernel 2.6.31.14-0.8-desktop (tty1).

brontolo login: _

and leaves its keyboard with the default US layout. Since I have an IT keyboard and a password containing international characters, I could no longer log in from console and had to use SSH. Once run loadkeys against tty1 from remote, the console became loginnable, but it was pretty awkward.

Anyone had this happen? The keyboard actually worked – albeit in US. The only problem (that I could see) was the keymap not being loaded. The kbd service has never failed me before (and this is not the same machine with choosy keyboard that got me to ask this question).

The reason turned out to be a bug in the handling of the -C flag of loadkey. The loadkeys manpage reports (correctly, it turns out)

You can specify console device by the -C (or --console ) option

But that’s device, not devices. In the /etc/sysconfig/keyboard file, the KBD_TTY variable holds instead

KBD_TTY="tty1 tty2 tty3 tty4 tty5 tty6"

and this, in the /etc/init.d/kbd file, causes an error:

Couldn't open tty tty2 tty3 ...

So the solution was to modify the /etc/init.d/kbd file,

--- loadkeys -C "$KBD_TTY" ...

+++ for tty in $KBD_TTY; do
+++     loadkeys -C $tty ...
+++ done

(this kind of code appears in four places in all).

This difference in loadkeys was apparently noticed in another distro (?) in 2011.

Searching in Novell’s OpenSuSE BugZilla database searching for “loadkeys” yielded no results, so I just entered it as bug 813902. I reasoned that even if the bug doesn’t surface in a normal installation, those lines invoking loadkeys are still wrong. And that even if it’s because I have the wrong loadkeys or kbd due to a uncommon installation/upgrade path, that’s still a symptom of a bug in the update script.