Quando o Linux Não Inicia - Kernel Panic e Modo de Emergência

2026-06-06 Tempo de leitura: Cerca de 12 min Dificuldade: Intermediário

O Que Você Vai Aprender

O significado e a diferença entre uma tela congelada de kernel panic, o prompt (initramfs) e o modo de emergência
Como fazer triagem de qual estágio do boot realmente falhou
O caminho de recuperação mais rápido: iniciar um kernel antigo pelo GRUB, reparar fstab e executar fsck

Conclusão (o modelo de triagem)

O que fazer depende inteiramente de onde o boot parou. Verifique até onde chegou, de cima para baixo.

grub rescue> / grub> → parou no bootloader (configuração ou módulos do GRUB perdidos)
Prompt (initramfs) → o filesystem raiz não pode ser montado (espaço de usuário inicial)
Kernel panic - not syncing: ... → o kernel parou irrecuperavelmente
Shell de emergência / resgate → o espaço de usuário foi alcançado mas o boot falhou no meio (geralmente fstab)

Premissas (ambiente alvo)

Distro: Ubuntu / família Debian (systemd e GRUB 2)
Você pode ver a tela via console físico ou console serial / VNC em cloud
A recuperação precisa de root (o shell de emergência roda como root)

Em Qual Estágio o Boot Parou?

Conclusão: Leia o texto na tela para identificar o estágio. grub significa bootloader, (initramfs) significa falha na montagem do root, Kernel panic significa que o kernel parou, e emergency mode significa uma falha após o espaço de usuário iniciar.

O boot do Linux segue aproximadamente esta ordem. Identificar onde parou é o primeiro passo.

Estágio	Sinal na tela	Causa comum
1. Bootloader	`grub rescue>` / `grub>`	Configuração do GRUB ou `/boot` perdidos, mudanças de partição
2. Espaço de usuário inicial	Prompt `(initramfs)`	Dispositivo raiz não encontrado, corrupção de filesystem
3. Kernel	`Kernel panic - not syncing:`	Root não monta, driver ausente, initramfs quebrado
4. systemd	`You are in emergency mode` / `rescue mode`	`fstab` ruim, montagem obrigatória falhou, serviço falhou

Iniciar um kernel antigo vale a pena tentar primeiro

Se a máquina parou de iniciar logo após uma atualização de kernel, simplesmente iniciar o kernel anterior em "Advanced options" frequentemente resolve (veja abaixo).

O Que é um Kernel Panic?

Conclusão: Um kernel panic é o kernel parando de propósito após detectar um erro irrecuperável. É mais frequentemente causado por não conseguir montar o filesystem raiz, ou um driver essencial ausente ou initramfs quebrado.

Quando o kernel detecta uma inconsistência interna fatal, ele decide que continuar corromperia dados e para deliberadamente. Isso é um kernel panic. Diferente de um crash de aplicação, o sistema inteiro para.

Uma mensagem típica:

Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

Este é o sinal de que o filesystem raiz não pode ser montado. Causas comuns:

Um initramfs quebrado ou desatualizado após atualização de kernel (falta o driver de armazenamento necessário)
O parâmetro root= do kernel aponta para um UUID / dispositivo alterado
Mudanças de armazenamento (LVM / RAID / troca de disco) deixam o root impossível de encontrar

Uma variante diferente, Kernel panic - not syncing: Attempted to kill init!, significa que o init (systemd) morreu logo após iniciar. Suspeite de initramfs ou filesystem raiz quebrado.

A tela de panic frequentemente rola para além. A causa real está nas primeiras linhas (bem no topo). Em servidores cloud leia o log do console serial; em máquinas físicas fotografe o topo da tela.

Como Iniciar um Kernel Antigo Pelo GRUB?

Conclusão: Acesse o menu do GRUB, abra "Advanced options" e escolha o kernel anterior. Se uma atualização recente de kernel é a causa, isso sozinho já permite iniciar.

Logo após uma atualização de kernel, iniciar o kernel antigo é a forma mais rápida de triagem.

Após ligar, exiba o menu do GRUB (segure Shift, ou pressione Esc em UEFI, se não aparecer)
Escolha Advanced options for Ubuntu
Selecione a versão anterior do kernel e inicie

Uma vez dentro com o kernel antigo, reconstrua o initramfs do kernel atual:

$ sudo update-initramfs -u -k all
$ sudo update-grub

Editar uma entrada de boot do GRUB em tempo real

Com uma entrada selecionada, pressione e para editar seus parâmetros de boot no local.

Pressione e na entrada desejada
Mova para o final da linha que começa com linux (após ro quiet splash, etc.)
Adicione o parâmetro necessário (ex: systemd.unit=rescue.target)
Pressione Ctrl + X ou F10 para iniciar

Esta edição é temporária e reverte ao reiniciar. Para torná-la permanente, edite /etc/default/grub e execute update-grub.

E Se Parar no Prompt do initramfs?

Conclusão: O prompt (initramfs) significa que o filesystem raiz não pode ser montado. Geralmente é corrupção de filesystem — execute fsck, depois exit para continuar o boot.

O prompt BusyBox (initramfs) aparece quando o kernel iniciou mas não conseguiu montar o root. Frequentemente é precedido por uma linha como:

ALERT!  /dev/sda1 does not exist.  Dropping to a shell!

ou uma inconsistência de filesystem detectada. Para corrigir:

# Veja quais dispositivos de bloco sao reconhecidos
(initramfs) cat /proc/partitions
(initramfs) ls /dev/sd* /dev/nvme*

# Verifique e repare a particao alvo (deve estar desmontada)
(initramfs) fsck /dev/sda1

# Apos o reparo, continue o boot
(initramfs) exit

Quando fsck perguntar se deve reparar, responda y como regra. Se houver muitos prompts, use fsck -y /dev/sda1 para aceitar todos. Após terminar, exit retorna à sequência normal de boot.

Nunca execute fsck em um filesystem montado — há risco de corrupção. Execute-o a partir do estágio (initramfs), do modo de emergência enquanto o root está somente leitura, ou de um live USB.

Qual a Diferença Entre Modo de Resgate e Emergência?

Conclusão: rescue.target é semelhante a single-user com filesystems locais montados e serviços básicos, enquanto emergency.target monta apenas o root como somente leitura com quase nada rodando. Um fstab ruim leva você ao modo de emergência automaticamente.

O systemd tem dois targets de recuperação. Eles diferem no que você pode fazer.

Target	Montagens	Serviços	Uso
`rescue.target`	Filesystems locais	Conjunto mínimo ativo	Semelhante a single-user. Trabalho de recuperação normal
`emergency.target`	Apenas root, somente leitura	Quase nenhum	Mais mínimo. Último recurso quando `fstab` está quebrado

Entrar em modo de resgate / emergência de propósito

No editor do GRUB (e), adicione ao final da linha linux:

# Modo de resgate (recomendado; suficiente para a maioria das recuperacoes)
systemd.unit=rescue.target

# Modo de emergencia (mais minimo)
systemd.unit=emergency.target

Atalhos (rescue / emergency / os antigos single 1) também funcionam, mas a forma systemd.unit= é confiável. Inicie com Ctrl + X e você chega em um shell root após digitar a senha.

Tornar root gravável no modo de emergência

No modo de emergência, o root geralmente está somente leitura, então você não pode editar arquivos. Remonte como gravável:

$ mount -o remount,rw /

E Se um fstab Ruim Me Jogou no Modo de Emergência?

Conclusão: Um erro em /etc/fstab ou uma referência a um dispositivo ausente para o boot e leva você ao modo de emergência. Corrija a linha ofensora, valide com mount -a e reinicie.

A razão mais comum para cair no modo de emergência é /etc/fstab. Um UUID errado em uma nova montagem, um dispositivo desconectado ou um erro de digitação deixa o systemd esperando por uma montagem até desistir.

Recuperação:

# 1. Remonte root como gravavel
$ mount -o remount,rw /

# 2. Encontre a montagem com falha no log deste boot
$ journalctl -xb | grep -i -E 'mount|fstab|dependency'

# 3. Corrija o fstab (voce pode comentar temporariamente a linha ruim)
$ nano /etc/fstab

# 4. Recarregue a configuracao e valide todas as entradas
$ systemctl daemon-reload
$ mount -a

Se mount -a completar sem erros, o fstab está saudável. Qualquer erro significa que aquela linha ainda tem problema.

Prevenção: adicione a opção nofail a montagens não essenciais para que um dispositivo ausente não pare o boot. Útil para discos externos e montagens de rede.

UUID=xxxx  /mnt/data  ext4  defaults,nofail  0  2

Como Ler o Log de Boot?

Conclusão: Após a recuperação, leia este boot com journalctl -xb e o boot anterior com falha com journalctl -b -1. Comece pelas linhas vermelhas (unidade com falha) e Dependency failed.

Uma vez inicializado, confirme o que aconteceu para prevenir repetição.

# O boot atual completo (-x adiciona texto explicativo)
$ journalctl -xb

# O boot anterior (com falha)
$ journalctl -b -1

# Listar apenas as unidades com falha
$ systemctl --failed

Linhas como Dependency failed for ... ou Failed to mount ... apontam para a causa direta da parada. Se erros de I/O de disco estiverem misturados, suspeite de falha de hardware também.

Ler o boot anterior (-b -1) precisa de journal persistente. Onde /var/log/journal/ está ausente, logs desaparecem ao reiniciar. Torne-o persistente primeiro: sudo mkdir -p /var/log/journal && sudo systemctl restart systemd-journald.

O Que Não Fazer

Conclusão: Executar fsck em um filesystem montado, reinstalar antes de identificar a causa e perder o topo da tela de panic pioram as coisas. Priorize as linhas do topo do log e a identificação do estagio.

Executar fsck em um filesystem montado → corrupção. Sempre faça somente leitura / desmontado
Julgar pela última linha da tela de panic → a causa real está no topo; atenção ao scroll
Reinstalar o SO sem fazer triagem → elimina casos corrigíveis com uma linha de fstab ou kernel antigo
Deixar a linha ruim do fstab no lugar → você cai no modo de emergência em todo reboot
Reiniciar sem journal persistente → o log da falha se perde e a causa vira um mistério