Kernel panic "Unable to mount root fs": como achar a causa e recuperar o boot

O servidor reiniciou depois de uma atualização e o console mostra "Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)". Nada responde. A resposta curta: o kernel carregou, mas não conseguiu montar a partição raiz, onde está o resto do sistema. Na maioria das vezes falta o initramfs da versão nova, porque a atualização foi interrompida ou o /boot encheu, ou o parâmetro de boot aponta para um disco que mudou de identidade. O primeiro passo é escolher o kernel anterior no menu do GRUB. Se ele sobe, o disco está bem e o conserto é regenerar o initramfs e a configuração do GRUB.

Não é um erro de aplicativo e quase nunca exige reinstalar o sistema. É uma falha numa etapa curta e bem definida da inicialização, e dá para recuperar sem apagar nenhuma partição.

O que acontece entre o GRUB e o sistema subir

A inicialização de um Linux comum segue uma cadeia. O firmware, BIOS ou UEFI, carrega o GRUB. O GRUB carrega dois arquivos de /boot: o kernel, por exemplo vmlinuz-6.8.0-45-generic, e o initramfs correspondente, como initrd.img-6.8.0-45-generic. O initramfs é um sistema de arquivos mínimo, carregado na memória, com os drivers e scripts necessários para achar o disco de verdade: controlador NVMe, SATA ou virtio, LVM, RAID por software, criptografia LUKS.

O GRUB também passa ao kernel o parâmetro root=, normalmente com o UUID da partição raiz. O initramfs procura esse UUID, monta a partição e entrega o controle para o init do sistema instalado, que hoje quase sempre é o systemd. Se qualquer elo falha, o kernel não tem para onde ir e entra em pânico.

Como ler os números da mensagem

O par entre parênteses é o número do dispositivo. unknown-block(0,0) significa que o kernel nem encontrou um dispositivo de bloco para tentar. Isso é típico de initramfs ausente, corrompido ou sem o driver do controlador de disco. Números diferentes de zero indicam que o kernel achou um dispositivo, mas não conseguiu montá-lo, o que aponta para partição errada, sistema de arquivos sem suporte ou corrompido.

Há uma terceira tela, parecida mas diferente: no Debian e no Ubuntu, quando o initramfs existe e não acha o UUID, aparece algo como "ALERT! UUID=... does not exist. Dropping to a shell!" e um prompt (initramfs). Nesse caso o initramfs está lá. O problema é o identificador do disco, comum depois de clonar a máquina ou trocar o disco.

Causas que se repetem

• Atualização de kernel interrompida: o kernel novo foi instalado, mas o initramfs não foi gerado.
• /boot cheio: a geração do initramfs falhou por falta de espaço, e o aviso passou despercebido no meio da saída do apt.
• Disco clonado ou substituído: o UUID mudou e o root= ou o /etc/fstab apontam para o antigo.
• Controlador de disco trocado: numa VM, mudar o tipo do disco virtual, ou no PC, mudar o modo SATA no firmware, exige um driver que o initramfs não tem.
• Disco com defeito ou cabo solto, que você confirma se o disco nem aparece no firmware.

Como recuperar passo a passo

1. Fotografe ou copie a mensagem completa. Em nuvem, use o console serial ou a captura de tela do provedor.
2. Confirme que o disco aparece no firmware ou no painel da VM. Se não aparece, o problema é hardware ou anexo de volume, não software.
3. Abra o menu do GRUB. No Ubuntu, segure Shift durante o boot em BIOS ou aperte Esc em UEFI. Entre em "Advanced options" e escolha o kernel anterior.
4. Se o kernel anterior subir, termine a atualização e regenere os arquivos de boot, como no primeiro bloco abaixo.
5. Se nenhum kernel subir, arranque por um pendrive ou ISO da mesma distribuição, monte o sistema instalado e faça o mesmo conserto num chroot.
6. Reinicie no kernel novo. Só dê o assunto por encerrado quando ele subir sozinho, sem escolha manual no menu.

Com o sistema de pé pelo kernel anterior, no Debian ou Ubuntu:

df -h /boot
ls -l /boot
sudo dpkg --configure -a
sudo apt -f install
sudo update-initramfs -u -k all
sudo update-grub

O ls deve mostrar um initrd.img para cada vmlinuz com a mesma versão. Se o /boot estiver quase cheio, rode sudo apt autoremove --purge para remover kernels antigos antes de regenerar. O apt não remove o kernel em execução, mas leia a lista antes de confirmar.

Conserto pelo sistema externo, com chroot

Primeiro identifique as partições com lsblk -f. Nos comandos abaixo, a raiz é /dev/nvme0n1p2 e a partição EFI é /dev/nvme0n1p1. Troque pelos nomes da sua máquina. Se o /boot for uma partição separada, monte-a também em /mnt/boot antes do chroot.

sudo mount /dev/nvme0n1p2 /mnt
sudo mount /dev/nvme0n1p1 /mnt/boot/efi
for d in dev proc sys run; do sudo mount --rbind /$d /mnt/$d; done
sudo chroot /mnt

# dentro do chroot
dpkg --configure -a
apt -f install
update-initramfs -u -k all
update-grub
exit

sudo umount -R /mnt

Use -k all de propósito. Dentro do chroot, uname -r mostra a versão do kernel do pendrive, não a do sistema instalado, e regenerar para essa versão não conserta nada. Em Fedora, RHEL e derivados, o equivalente para o initramfs é dracut --regenerate-all --force, e a configuração do GRUB se regenera conforme a documentação da versão que você usa.

Se a suspeita é UUID, compare a saída de blkid com o /etc/fstab e com o root= que aparece em /boot/grub/grub.cfg. Depois de corrigir o fstab, rode update-grub de novo.

Erros comuns

• Reinstalar o sistema no impulso. Você perde configuração e às vezes dados por um problema que costuma ser dois arquivos faltando em /boot.
• Rodar fsck ou formatar a partição errada. Sob pressão, /dev/sda1 e /dev/sda2 se confundem. Confira com lsblk -f e nunca rode fsck em partição montada.
• Remover o kernel antigo antes de o novo subir. É exatamente o kernel que te salvaria na próxima falha.
• Regenerar o initramfs só para a versão do pendrive. O comando sai sem erro e o boot continua quebrado.
• Ignorar o /boot cheio. O conserto funciona hoje e a próxima atualização de kernel repete a mesma tela.
• Trocar o tipo de disco da VM sem planejar. O sistema perde o driver do controlador e para no boot seguinte.

Checklist

• A mensagem completa foi registrada, com os números entre parênteses.
• O disco aparece no firmware ou no painel da VM.
• Existe um initrd.img para cada vmlinuz em /boot.
• df -h /boot mostra folga para pelo menos mais um kernel.
• dpkg --configure -a roda sem pendências.
• O UUID do root= e do /etc/fstab bate com o blkid.
• O kernel novo sobe sozinho, sem escolha manual no GRUB.
• O kernel anterior continua instalado como reserva.

Quanto espaço livre tem o /boot do seu servidor agora, e quantos kernels ainda cabem nele antes de a próxima atualização falhar em silêncio?