OpenSuSE serviço 12.3 kbd falhando na inicialização

Question

Uma instalação do OpenSuSE 12.3 (mas atualizada de 11.2) exibe esta mensagem

...
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: _

e deixa seu teclado com o layout padrão dos EUA. Como tenho um teclado de TI e uma senha contendo caracteres internacionais, não consigo mais efetuar login do console e preciso usar o SSH. Uma vez executado loadkeys contra tty1 do controle remoto, o console tornou-se loginnable , mas foi bastante complicado.

Alguém teve isso acontecer? O teclado realmente funcionou - embora nos EUA. O único problema (que eu podia ver) era o mapa de teclado não sendo carregado. O serviço kbd nunca falhou comigo antes (e esta não é a mesma máquina com teclado exigente que me fez perguntar esta questão ).

    

Answer 1

O motivo acabou sendo um erro no processamento do -C flag de loadkey . Os relatórios loadkeys manpage (corretamente, acontece)

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

Mas isso é dispositivo , não dispositivos . No arquivo /etc/sysconfig/keyboard , a variável KBD_TTY mantém em seu lugar

KBD_TTY="tty1 tty2 tty3 tty4 tty5 tty6"

e isso, no arquivo /etc/init.d/kbd , causa um erro:

Couldn't open tty tty2 tty3 ...

Então a solução foi modificar o arquivo /etc/init.d/kbd ,

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

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

(esse tipo de código aparece em quatro lugares ao todo).

Esta diferença em loadkeys foi aparentemente notada em outra distro ( ?) em 2011.

Pesquisando no OpenSuSE da Novell O banco de dados do BugZilla procurando por "loadkeys" não produziu nenhum resultado, então eu acabei de inseri-lo como bug 813902 . Eu argumentei que mesmo que o bug não apareça em uma instalação normal, as linhas que invocam loadkeys ainda estão erradas. E mesmo que seja porque eu tenho o loadkeys ou kbd errado devido a um caminho de instalação / atualização incomum, isso ainda é um sintoma de um bug no script de atualização.