Quando o Linux Nao Inicia - Kernel Panic e Modo de Emergencia

Quando o Linux Nao Inicia - Kernel Panic e Modo de Emergencia
Tempo de leitura: Cerca de 12 min Dificuldade: Intermediario

O Que Voce Vai Aprender

  • O significado e a diferenca entre uma tela congelada de kernel panic, o prompt (initramfs) e o modo de emergencia
  • Como fazer triagem de qual estagio do boot realmente falhou
  • O caminho de recuperacao mais rapido: iniciar um kernel antigo pelo GRUB, reparar fstab e executar fsck

Conclusao (o modelo de triagem)

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

  1. grub rescue> / grub> → parou no bootloader (configuracao ou modulos do GRUB perdidos)
  2. Prompt (initramfs) → o filesystem raiz nao pode ser montado (espaco de usuario inicial)
  3. Kernel panic - not syncing: ... → o kernel parou irrecuperavelmente
  4. Shell de emergencia / resgate → o espaco de usuario foi alcancado mas o boot falhou no meio (geralmente fstab)

Premissas (ambiente alvo)

  • Distro: Ubuntu / familia Debian (systemd e GRUB 2)
  • Voce pode ver a tela via console fisico ou console serial / VNC em cloud
  • A recuperacao precisa de root (o shell de emergencia roda como root)

Em Qual Estagio o Boot Parou?

Conclusao: Leia o texto na tela para identificar o estagio. grub significa bootloader, (initramfs) significa falha na montagem do root, Kernel panic significa que o kernel parou, e emergency mode significa uma falha apos o espaco de usuario iniciar.

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

Estagio Sinal na tela Causa comum
1. Bootloader grub rescue> / grub> Configuracao do GRUB ou /boot perdidos, mudancas de particao
2. Espaco de usuario inicial Prompt (initramfs) Dispositivo raiz nao encontrado, corrupcao de filesystem
3. Kernel Kernel panic - not syncing: Root nao monta, driver ausente, initramfs quebrado
4. systemd You are in emergency mode / rescue mode fstab ruim, montagem obrigatoria falhou, servico falhou

Iniciar um kernel antigo vale a pena tentar primeiro

Se a maquina parou de iniciar logo apos uma atualizacao de kernel, simplesmente iniciar o kernel anterior em "Advanced options" frequentemente resolve (veja abaixo).

O Que e um Kernel Panic?

Conclusao: Um kernel panic e o kernel parando de proposito apos detectar um erro irrecuperavel. E mais frequentemente causado por nao conseguir montar o filesystem raiz, ou um driver essencial ausente ou initramfs quebrado.

Quando o kernel detecta uma inconsistencia interna fatal, ele decide que continuar corromperia dados e para deliberadamente. Isso e um kernel panic. Diferente de um crash de aplicacao, o sistema inteiro para.

Uma mensagem tipica:

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

Este e o sinal de que o filesystem raiz nao pode ser montado. Causas comuns:

  • Um initramfs quebrado ou desatualizado apos atualizacao de kernel (falta o driver de armazenamento necessario)
  • O parametro root= do kernel aponta para um UUID / dispositivo alterado
  • Mudancas de armazenamento (LVM / RAID / troca de disco) deixam o root impossivel de encontrar

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

A tela de panic frequentemente rola para alem. A causa real esta nas primeiras linhas (bem no topo). Em servidores cloud leia o log do console serial; em maquinas fisicas fotografe o topo da tela.

Como Iniciar um Kernel Antigo Pelo GRUB?

Conclusao: Acesse o menu do GRUB, abra "Advanced options" e escolha o kernel anterior. Se uma atualizacao recente de kernel e a causa, isso sozinho ja permite iniciar.

Logo apos uma atualizacao de kernel, iniciar o kernel antigo e a forma mais rapida de triagem.

  1. Apos ligar, exiba o menu do GRUB (segure Shift, ou pressione Esc em UEFI, se nao aparecer)
  2. Escolha Advanced options for Ubuntu
  3. Selecione a versao 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 parametros de boot no local.

  1. Pressione e na entrada desejada
  2. Mova para o final da linha que comeca com linux (apos ro quiet splash, etc.)
  3. Adicione o parametro necessario (ex: systemd.unit=rescue.target)
  4. Pressione Ctrl + X ou F10 para iniciar

Esta edicao e temporaria e reverte ao reiniciar. Para torna-la permanente, edite /etc/default/grub e execute update-grub.

E Se Parar no Prompt do initramfs?

Conclusao: O prompt (initramfs) significa que o filesystem raiz nao pode ser montado. Geralmente e corrupcao de filesystem — execute fsck, depois exit para continuar o boot.

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

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

ou uma inconsistencia 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. Apos terminar, exit retorna a sequencia normal de boot.

Qual a Diferenca Entre Modo de Resgate e Emergencia?

Conclusao: rescue.target e semelhante a single-user com filesystems locais montados e servicos basicos, enquanto emergency.target monta apenas o root como somente leitura com quase nada rodando. Um fstab ruim leva voce ao modo de emergencia automaticamente.

O systemd tem dois targets de recuperacao. Eles diferem no que voce pode fazer.

Target Montagens Servicos Uso
rescue.target Filesystems locais Conjunto minimo ativo Semelhante a single-user. Trabalho de recuperacao normal
emergency.target Apenas root, somente leitura Quase nenhum Mais minimo. Ultimo recurso quando fstab esta quebrado

Entrar em modo de resgate / emergencia de proposito

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) tambem funcionam, mas a forma systemd.unit= e confiavel. Inicie com Ctrl + X e voce chega em um shell root apos digitar a senha.

Tornar root gravavel no modo de emergencia

No modo de emergencia, o root geralmente esta somente leitura, entao voce nao pode editar arquivos. Remonte como gravavel:

$ mount -o remount,rw /

E Se um fstab Ruim Me Jogou no Modo de Emergencia?

Conclusao: Um erro em /etc/fstab ou uma referencia a um dispositivo ausente para o boot e leva voce ao modo de emergencia. Corrija a linha ofensora, valide com mount -a e reinicie.

A razao mais comum para cair no modo de emergencia e /etc/fstab. Um UUID errado em uma nova montagem, um dispositivo desconectado ou um erro de digitacao deixa o systemd esperando por uma montagem ate desistir.

Recuperacao:

# 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 esta saudavel. Qualquer erro significa que aquela linha ainda tem problema.

Prevencao: adicione a opcao nofail a montagens nao essenciais para que um dispositivo ausente nao pare o boot. Util para discos externos e montagens de rede.

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

Como Ler o Log de Boot?

Conclusao: Apos a recuperacao, 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 repeticao.

# 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 tambem.

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

O Que Nao Fazer

Conclusao: 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 identificacao do estagio.

  • Executar fsck em um filesystem montado → corrupcao. Sempre faca somente leitura / desmontado
  • Julgar pela ultima linha da tela de panic → a causa real esta no topo; atencao ao scroll
  • Reinstalar o SO sem fazer triagem → elimina casos corrigiveis com uma linha de fstab ou kernel antigo
  • Deixar a linha ruim do fstab no lugar → voce cai no modo de emergencia em todo reboot
  • Reiniciar sem journal persistente → o log da falha se perde e a causa vira um misterio

Proximas Leituras