De TTYs quebrados a um desktop XFCE4 funcional no Arch Linux: análise de causa raiz

De TTYs quebrados a um desktop XFCE4 funcional no Arch Linux: análise de causa raiz#

Instalar o Arch Linux a partir do zero em uma máquina virtual ou física raramente segue um caminho totalmente linear. Quando a documentação convencional não cobre um comportamento inesperado, a saída é descer ao nível das chamadas de sistema, checar os caminhos físicos do pacote e entender como os serviços trocam mensagens no kernel.

Recentemente passei por esse processo durante a montagem de um ambiente Arch Linux no VirtualBox. O que começou como uma simples falha ao carregar o layout de teclado no terminal virtual (TTY) evoluiu para problemas de barramento D-Bus e painéis que não inicializavam no XFCE4.

Abaixo documento a análise de cada falha e os comandos necessários para deixar o sistema totalmente funcional.

O mistério do loadkeys br-abnt2 e o erro ENOENT#

Logo após o primeiro boot no terminal virtual, tentei carregar o mapa de teclado padrão brasileiro:

loadkeys br-abnt2
# Erro retornado: unable to open file no such file or directory

Mesmo reinstalando o pacote kbd com pacman -S kbd, o erro continuava aparecendo.

O comportamento interno do utilitário kbd#

A mensagem "unable to open file" é o retorno de usuário para a falha ENOENT (No such file or directory) devolvida pelo kernel durante chamadas openat() ou stat().

No código-fonte do utilitário kbd (em src/libkeymap/findfile.c), o programa percorre uma lista de diretórios padrão anexando extensões como .map, .map.gz ou .kmap. No Arch Linux, o resolvedor do binário falhou em associar a string direta "br-abnt2" ao arquivo real compactado em /usr/share/kbd/keymaps/i386/qwerty/br-abnt2.map.gz.

Ao falhar na abertura do arquivo, o programa encerra antes de disparar a chamada de controle ioctl(KDSKBENT), que é a responsável por gravar a tabela de tradução de teclas na memória do driver de console do kernel.

Rastreando a busca de arquivos com strace#

Para entender onde o binário procurava os mapas de teclado, rodei o strace filtrando chamadas de abertura de arquivos:

strace -e trace=open,openat,stat loadkeys br-abnt2 2>&1 | grep keymaps

A saída revelou tentativas em caminhos que não batiam com a estrutura instalada. Também confirmei o caminho padrão compilado no executável usando o strings:

strings $(which loadkeys) | grep /share/keymaps

Além disso, mapas de teclado compactados frequentemente usam diretivas internas de inclusão, como include "windowkeys". Se o arquivo referenciado no include estiver corrompido ou ausente, o descompactador interno falha com ENOENT, parecendo que o arquivo principal sumiu. Validei o conteúdo direto do mapa com o zless:

zless /usr/share/kbd/keymaps/i386/qwerty/br-abnt2.map.gz

Contorno e persistência com o systemd#

Para contornar o problema de resolução do nome curto, passei o caminho relativo completo da arquitetura:

loadkeys i386/qwerty/br-abnt2
# Ou pelo caminho absoluto:
loadkeys /usr/share/kbd/keymaps/i386/qwerty/br-abnt2.map.gz

Para garantir que o layout persista a cada boot sem depender de comandos manuais, configurei o arquivo do systemd em /etc/vconsole.conf:

KEYMAP=br-abnt2
FONT=Lat2-Terminus16

Para aplicar a configuração de console imediatamente sem reiniciar:

/usr/lib/systemd/systemd-vconsole-setup

Podemos checar o status do serviço com localectl status e journalctl -u systemd-vconsole-setup.

A stack gráfica no X11 e o suporte a máquinas virtuais#

Com o console virtual funcionando em português, instalei os componentes do servidor gráfico X11, o ambiente de desktop XFCE4 e o gerenciador de login LightDM:

# Instalacao da base grafica
pacman -S xorg-server xfce4 xfce4-goodies

# Instalacao do display manager
pacman -S lightdm lightdm-gtk-greeter
systemctl enable lightdm

Como o sistema rodava dentro do VirtualBox, foi necessário instalar as extensões de convidado para garantir suporte aos drivers DRM do Xorg e sincronização de tela:

pacman -S virtualbox-guest-utils
systemctl enable --now vboxservice

Mapeando o teclado no Xorg#

O utilitário loadkeys atua apenas sobre os terminais virtuais (/dev/ttyX). O servidor gráfico Xorg processa eventos de entrada por meio do subsistema libinput.

Para manter o layout ABNT2 ativo dentro da interface gráfica de forma permanente, criei o arquivo /etc/X11/xorg.conf.d/00-keyboard.conf:

Section "InputClass"
        Identifier "system-keyboard"
        MatchIsKeyboard "on"
        Option "XkbLayout" "br"
        Option "XkbVariant" "abnt2"
EndSection

Inicializando a sessão gráfica com D-Bus#

Se você optar por iniciar o ambiente diretamente pelo terminal sem um Display Manager (usando startx), o arquivo ~/.xinitrc precisa carregar o barramento de comunicação do D-Bus:

pacman -S xorg-xinit
cp /etc/X11/xinit/xinitrc ~/.xinitrc
echo "exec dbus-launch --exit-with-session startxfce4" >> ~/.xinitrc

O XFCE4 depende do barramento IPC do D-Bus para que o gerenciador de janelas (xfwm4), o painel e o gerenciador de arquivos (thunar) troquem eventos entre si. Sem ele, itens do painel e notificações falham silenciosamente.

O XFCE4 limpo e a recuperação do painel de tarefas#

Ao entrar na sessão gráfica pela primeira vez, me deparei com um desktop totalmente vazio: apenas o papel de parede e os ícones de sistema na área de trabalho, sem qualquer barra de tarefas ou menu visível.

Por que o painel não carregou?#

O processo principal de sessão (xfce4-session) tenta executar o xfce4-panel na inicialização. Na primeira vez em que roda, o painel deve exibir uma janela perguntando se você prefere um layout padrão ou vazio.

Se esse diálogo não aparece, os motivos mais comuns são:

1. Timeout no socket do D-Bus: falha na comunicação interprocessos durante a carga da sessão.
2. Permissões misturadas: se a interface foi iniciada anteriormente sob a conta de root, a pasta ~/.config/xfce4 pode ter sido gravada com propriedade restrita, impedindo o usuário comum de salvar novos arquivos.
3. Travamento no processo de configuração: instâncias antigas do xfconfd retendo estados incompletos.

Restaurando o painel pelo terminal#

Para diagnosticar a situação, chequei a lista de processos ativos:

ps aux | grep xfce

O xfdesktop estava ativo, mas o xfce4-panel não constava na listagem.

Para forçar a inicialização limpa do painel e restaurar o perfil inicial:

# Definir a tela ativa
export DISPLAY=:0

# Encerrar processos residuais
xfce4-panel --quit
pkill xfconfd

# Limpar o perfil corrompido para disparar a criacao inicial
rm -rf ~/.config/xfce4/panel

# Iniciar o painel ignorando checagens redundantes
xfce4-panel --disable-wm-check &

Ao executar essa sequência, o diálogo de primeiro uso apareceu na tela e o painel foi gerado com as barras padrão.

Para completar a interface com um menu moderno estilo busca, instalei o plugin do Whisker Menu:

pacman -S xfce4-whiskermenu-plugin xfce4-appfinder xfce4-goodies

Depois de instalado, adicionei o item ao painel clicando com o botão direito na barra e navegando em Painel -> Adicionar novos itens -> Menu Whisker.

Da depuração de baixo nível ao desktop estável: lições práticas#

Montar uma distribuição enxuta como o Arch Linux ensina muito sobre como as camadas do sistema se comunicam. Quando um comando básico como o loadkeys falha, o caminho mais rápido não é tentar pacotes aleatórios, mas rastrear com strace quais caminhos de arquivo o programa está tentando abrir.

Da mesma forma, problemas com desktops que sobem vazios quase sempre decorrem de permissões em pastas de perfil ou da ausência de barramentos IPC como o D-Bus. Entender esses pontos de contato entre kernel, X11 e gerenciadores de sessão permite solucionar falhas de inicialização com precisão e estabilidade.

Veja também

Linux Do Kali moderno ao metasploitable2: como dominar o layout de teclado ABNT2 no Linux via CLI

Infraestrutura Como reiniciar a interface do XFCE4 sem encerrar a sessão ou rebootar

Linux Como resolver o erro 'cannot refresh cache whilst offline' no Linux e cPanel

Este post está licenciado sob CC BY-NC.