A cadeia de boot do Linux para diagnóstico: firmware, bootloader, kernel, initramfs e systemd

O que é

O bootup(7) descreve a cadeia: o firmware do sistema faz uma inicialização mínima do hardware e passa o controle a um bootloader (GRUB ou systemd-boot) armazenado em armazenamento persistente. O bootloader carrega um kernel do sistema operacional a partir do disco ou da rede; em sistemas EFI, o firmware também pode carregar o kernel diretamente. O kernel monta então uma raiz em memória, o initramfs, que é um arquivo CPIO comprimido extraído para um tmpfs, e que localiza e monta o sistema de arquivos raiz real. Em seguida, o initramfs transfere o controle ao gerenciador do sistema do host (systemd(1) na maioria das distribuições atuais), que detecta o hardware restante, monta os demais sistemas de arquivos e inicia os serviços configurados até chegar ao target padrão.

Por que importa

Uma falha em cada etapa tem um aspecto diferente e exige uma correção diferente: uma falha de firmware ou de bootloader não produz nenhuma saída do kernel; uma falha do kernel gera mensagens iniciais do kernel, mas não chega ao init; uma falha do initramfs normalmente leva a um shell inicial ((initramfs) no Debian/Ubuntu, um shell de emergência do dracut em sistemas da família RHEL) ou trava à espera de um dispositivo raiz; uma falha do systemd deixa o kernel iniciar normalmente, mas serviços falham ou o sistema termina em um target diferente do padrão. Tratar as quatro situações como "não dá boot" faz perder tempo reinstalando o componente errado.

Como aplicar

• Acompanhe o console durante o boot (localmente, por porta serial ou pelo console do hipervisor) para ver qual foi a última etapa que produziu saída.
• Depois de um boot que chega ao systemd, consulte o log do próprio boot: journalctl -b para o boot atual e journalctl -b -1 para o anterior, caso o sistema tenha reiniciado sozinho (use --no-pager em scripts; por padrão a saída é paginada pelo less). Ler o journal do sistema exige root ou participação nos grupos systemd-journal, adm ou wheel.
• Meça onde o systemd gastou tempo ou o que o bloqueou com systemd-analyze blame e systemd-analyze critical-chain, que mostra a cadeia crítica de unidades, em termos de tempo, para um target.
• Na linha de comando do kernel, passe systemd.unit= para escolher um target de inicialização alternativo (por exemplo, rescue.target) apenas para um boot, sem editar nenhum arquivo, conforme o kernel-command-line(7); a forma com prefixo rd. (rd.systemd.unit=) vale apenas dentro do initramfs.
• Se nada chega a um prompt de login, verifique primeiro a etapa de firmware/bootloader (o menu de boot chega a aparecer?) antes de supor que o problema está no kernel ou no systemd.

Armadilhas

• Ler journalctl -b depois que o boot com falha já foi substituído por um boot bem-sucedido; use -b -1, -b -2 etc. (journalctl --list-boots mostra o que está disponível) e lembre que um journal não persistente perde por completo os boots anteriores.
• O systemd-analyze blame não informa serviços Type=simple, porque o systemd os considera iniciados imediatamente; um serviço simple lento não aparece ali.
• Supor que uma tela em branco após a splash do firmware significa "o kernel travou", quando pode ser apenas uma animação gráfica de boot escondendo as mensagens do kernel; remova quiet splash (Debian/Ubuntu) ou rhgb quiet (família RHEL) por um boot, no editor do GRUB, para ver a saída real.