Diagnóstico de Problemas de Arranque em Linux: Causa e Resolução

Linux · GRUB · boot · systemd · kernel panic · fsck · initramfs · chroot  |  ✎ Duarte Spínola  |  2026-07-11

Sistemas Operativos · Linux · GRUB · systemd · Kernel

Duarte Spínola · 11 de Julho de 2026

O servidor Linux não completa o arranque. Aparece a shell grub rescue> com o erro “no such partition”, ou um kernel panic com “VFS: Unable to mount root fs”, ou o sistema cai no emergency mode do systemd. O sintoma indica que uma de quatro camadas falhou: o GRUB (bootloader) não encontra a partição ou o kernel, o initramfs (ramdisk inicial) não consegue montar a raiz, o kernel entra em panic por falta de módulos, ou o systemd não consegue iniciar serviços críticos. A resolução depende de identificar qual camada falhou — usando um live USB para chroot ou ferramentas específicas como grub-install, mkinitcpio/dracut, fsck e journalctl. Referência geral: General troubleshooting — Arch Wiki.

1. O que Está a Acontecer — Camadas do Processo de Boot em Linux

O arranque de Linux segue uma sequência com cinco fases. Identificar onde a sequência falha determina a ferramenta de reparação correcta.

Sequência de boot de Linux (UEFI + GRUB)

Em sistemas com Legacy BIOS (MBR), a fase 2 usa GRUB stage1 (440 bytes no MBR) → stage1.5 (embed area) → stage2 (ficheiro em /boot). Em sistemas UEFI, o GRUB é um único binário EFI (grubx64.efi) na partição ESP (FAT32, normalmente /boot/efi/EFI/).

O GRUB e o grub.cfg

O GRUB (Grand Unified Bootloader) é o bootloader mais comum em Linux. A sua configuração está em /boot/grub/grub.cfg — um ficheiro gerado automaticamente por grub-mkconfig que não deve ser editado manualmente. O ficheiro diz ao GRUB onde encontrar o kernel (vmlinuz-linux ou vmlinuz-<versão>), o initramfs, e quais os parâmetros de boot (root=UUID=..., rw, quiet, etc.).

Quando o grub.cfg está em falta, corrompido, ou aponta para uma partição que já não existe (após redimensionamento ou restauração), o GRUB cai na shell grub rescue> — um ambiente mínimo onde se pode tentar carregar o kernel manualmente. Referência: GRUB — Arch Wiki.

O initramfs e a montagem da raiz

O initramfs (initial RAM filesystem) é um arquivo cpio comprimido (gz, zst ou xz) carregado em RAM pelo GRUB juntamente com o kernel. Contém os módulos de kernel necessários para aceder ao dispositivo onde a raiz (/) está — drivers de storage (ext4, xfs, btrfs, LVM, dm-crypt, NVMe, AHCI), binários (mount, udev, mdadm) e scripts de boot.

Se o initramfs não tiver o módulo correcto para o controlador de disco (por exemplo, depois de mudar de SATA para NVMe ou adicionar LVM), o kernel não consegue montar a raiz e entra em panic com “VFS: Unable to mount root fs on unknown-block(0,0)”. A reparação faz-se regenerando o initramfs com mkinitcpio -P (Arch), dracut --force (RHEL/Fedora) ou update-initramfs -u -k all (Debian/Ubuntu). Referência: Initramfs — Arch Wiki.

2. Cenários em que Este Problema Aparece

• Atualização de kernel com initramfs não regenerado — o novo kernel precisa de módulos que não estão no initramfs antigo. Comum em Arch Linux (rolling release) e Fedora.
• Atualização do GRUB interrompida — um apt upgrade ou pacman -Syu que atualiza o GRUB mas é interrompido antes de grub-mkconfig correr. O grub.cfg fica inconsistente.
• Redimensionamento ou reordenação de partições — alterar partições com gdisk ou parted muda os UUIDs. O GRUB e o /etc/fstab continuam a apontar para UUIDs antigos.
• Migração P2V ou V2V — mover um Linux de hardware físico para VM (ou entre hypervisors) sem regenerar initramfs. Os drivers de storage do hardware antigo não funcionam no novo.
• Corrupção do filesystem root — corte de energia durante escrita de metadados ext4/xfs. O kernel tenta montar a raiz, falha, e entra em panic.
• Disco cheio em /boot — atualizações de kernel acumulam-se em /boot até encher. O GRUB não consegue escrever o novo grub.cfg ou o initramfs. Sintoma: boot falha após update.
• Alteração de UUID ou PARTUUID — formatar uma partição acidentalmente gera um UUID novo. O fstab e o grub.cfg apontam para o UUID antigo.
• Kernel panic por módulo em falta — compilar kernel custom sem um módulo crítico (ext4, drivers de storage). Ou remover um módulo do initramfs com mkinitcpio.conf modificado incorretamente.
• systemd falha em serviço crítico — um serviço marcado como DefaultDependencies=yes no boot falha e o systemd cai em emergency mode. Comum após atualização de configuração de rede ou mount points incorrectos no fstab.
• Mudança de UEFI para Legacy (ou vice-versa) — instalar GRUB em modo Legacy num disco GPT ou em modo UEFI num disco MBR. O firmware não encontra o bootloader.

3. Passo 1 — Diagnosticar o Sintoma

O primeiro passo é identificar em que fase o boot falha. Cada sintoma aponta para uma camada diferente:

4. Passo 2 — Reparar o GRUB

4.1 GRUB rescue shell — boot manual

Se o ecrã mostra grub rescue>, o GRUB carregou o stage1 mas não encontrou o resto. É possível tentar boot manual:

Substituir (hd0,gpt2) pela partição correcta. Para listar partições disponíveis:

Se o normal carregar com sucesso, aparece o menu do GRUB. Arrancar o Linux e depois reinstalar o GRUB (Passo 2.3).

4.2 Boot com live USB + chroot

Se a shell rescue não resolver, é preciso arrancar com um live USB e fazer chroot para reparar o sistema instalado.

1. Arrancar com live USB (Ubuntu, Arch, SystemRescue — qualquer distribuição que tenha as ferramentas necessárias).

2. Identificar as partições:

Output típico:

3. Montar a raiz e partições auxiliares:

Se o sistema usa LVM ou LUKS (disk encryption), montar primeiro os layers necessários:

4. Montar os directórios virtuais para chroot:

5. Entrar no chroot:

A partir de aqui, os comandos executam como se estivessem dentro do sistema instalado. Referência: Chroot — Arch Wiki.

4.3 Reinstalar o GRUB e regenerar configuração

Dentro do chroot:

Sistemas UEFI (ESP em /boot/efi):

Sistemas Legacy BIOS (MBR):

Distribuições Debian/Ubuntu usam comandos equivalentes:

O update-grub é um wrapper Debian para grub-mkconfig -o /boot/grub/grub.cfg.

4.4 Se o UUID mudou (após redimensionamento de partições)

Se as partições foram redimensionadas ou recriadas, o /etc/fstab e o grub.cfg podem ter UUIDs antigos. Dentro do chroot:

Comparar os UUIDs actuais com os do /etc/fstab:

Actualizar os UUIDs no fstab com um editor (nano ou vim):

Depois regenerar o GRUB:

5. Passo 3 — Regenerar o initramfs

Se o GRUB está correcto mas o kernel entra em panic com “VFS: Unable to mount root fs”, o initramfs não tem os módulos necessários para aceder ao disco. Isto acontece frequentemente após mudança de hardware, atualização de kernel, ou modificação incorreta do ficheiro de configuração do initramfs.

5.1 Dentro do chroot (a partir de live USB)

Arch Linux / Manjaro (mkinitcpio):

O parâmetro -P regenera os initramfs de todos os kernels instalados. Se só se quer regenerar para um kernel específico:

Para verificar que módulos estão incluídos no initramfs:

Se um módulo crítico não aparece, verificar /etc/mkinitcpio.conf:

As HOOKS determinam que módulos e binários são incluídos. Para sistemas com LVM e LUKS:

Adicionar lvm2 se o sistema usa LVM, encrypt se usa LUKS. Referência: Mkinitcpio — Arch Wiki.

RHEL / Fedora / Rocky / Alma (dracut):

Para incluir drivers específicos:

Para ver o conteúdo do initramfs atual:

Debian / Ubuntu (initramfs-tools):

Para forçar regeneração de um kernel específico:

5.2 Verificar parâmetros de boot no grub.cfg

O kernel precisa de saber onde está a raiz. Verificar a linha linux no grub.cfg:

Deve aparecer algo como:

Se o root=UUID=... aponta para um UUID errado (partição que já não existe), o kernel não consegue montar a raiz. Corrigir o UUID ou usar root=/dev/sda3 temporariamente.

Para LVM:

Para LUKS:

6. Passo 4 — Diagnosticar e Reparar Problemas do systemd

Se o kernel arranca mas o systemd cai em emergency mode ou fica preso num “start job”, o problema está nos serviços ou mount points.

6.1 Emergency mode / rescue mode

O systemd tem três targets de recovery:

Para arrancar em rescue mode, editar a linha do kernel no GRUB (premir e no menu do GRUB) e adicionar no fim:

Ou para emergency mode:

Premir Ctrl+X ou F10 para arrancar.

6.2 Diagnosticar com journalctl

Dentro do sistema (ou em chroot a partir de live USB):

O parâmetro -b mostra apenas o boot atual. -p err filtra por prioridade error ou superior. Para ver todos os logs do boot:

Para ver logs do boot anterior (se o sistema reiniciou):

Procurar por entradas vermelhas (error) ou críticas. Referência: journalctl man page.

6.3 “A start job is running” — timeout de dispositivo

Se o systemd fica preso em “A start job is running for /dev/disk/by-uuid/…” durante 90 segundos, o fstab tem uma entrada para uma partição que já não existe ou não está montável.

Solução temporária: premir Ctrl+C para saltar o timeout, ou aguardar (após 90s o systemd continua).

Solução permanente: remover ou comentar a entrada problemática no fstab:

Comentar a linha com #:

6.4 Verificar mount points e fstab

Este comando verifica todas as entradas do fstab e reporta erros. Se houver mount points que referenciam dispositivos inexistentes, o systemd vai falhar no boot.

6.5 Reiniciar um serviço que falhou no boot

Se o serviço falha consistentemente no boot, verificar a sua configuração:

7. Passo 5 — Reparar Filesystem com fsck

Se o disco tem corrupção (corte de energia, bad sectors), o filesystem pode impedir o boot. O fsck repara erros de consistência.

7.1 fsck a partir de live USB

O fsck nunca deve ser corrido numa partição montada. Arrancar com live USB e desmontar tudo:

Parâmetros:

• -f — força verificação mesmo se o filesystem está marcado como clean
• -y — responde “yes” a todas as reparações automaticamente

Para XFS (não usa fsck da mesma forma):

Para Btrfs:

Referência: fsck man page.

7.2 fsck no boot automático

Se o filesystem está marcado como “dirty” (corrupção detectada), o kernel pode pedir fsck manual durante o boot. Para forçar fsck no próximo arranque:

Reiniciar. O sistema vai correr fsck automaticamente em todas as partições do fstab.

Em sistemas com systemd, usar:

7.3 Superblock de backup (ext4)

Se o superblock do ext4 está corrompido, o fsck pode falhar com “bad magic number in super-block”. O ext4 guarda cópias de backup do superblock em localizações calculadas:

O parâmetro -n (não destrutivo) lista os locais dos superblocks de backup:

Usar um dos superblocks de backup:

8. Passo 6 — kernel panic: Causas e Soluções

Um kernel panic significa que o kernel encontrou um erro fatal e não pode continuar. Os dois tipos mais comuns em boot:

8.1 “VFS: Unable to mount root fs”

O kernel não consegue montar a partição raiz. Causas:

1. initramfs sem módulo de disco — regenerar initramfs (Passo 3)
2. UUID errado nos parâmetros de boot — corrigir root=UUID=... no grub.cfg
3. Partição raiz corrompida — correr fsck (Passo 5)
4. Controlador de storage não suportado pelo kernel — instalar driver ou usar kernel com suporte

Para diagnosticar, adicionar rd.debug aos parâmetros de kernel no GRUB para ver logs detalhados do initramfs.

8.2 “kernel panic – not syncing: Attempted to kill init”

O processo init (PID 1) morreu. Isto pode acontecer se:

• O binário systemd está corrompido ou em falta
• Uma library compartilhada do systemd foi removida
• O /lib64/ld-linux-x86-64.so.2 (dynamic linker) está em falta

Solução: arrancar com live USB, chroot, e reinstalar o pacote systemd:

8.3 Kernel panic após atualização de kernel

Se o sistema arrancava bem e deixou de arrancar após uma atualização de kernel, arrancar com o kernel antigo a partir do menu do GRUB:

1. Ligar o sistema
2. No menu do GRUB, seleccionar “Advanced options for …”
3. Escolher a versão anterior do kernel
4. Arrancar

Depois, dentro do sistema, investigar porque é que o kernel novo falha:

Se for um problema de módulo em falta, regenerar o initramfs para o kernel novo. Se for um bug do kernel, manter o kernel antigo e reportar o bug.

Referência: Kernel panic — Arch Wiki.

9. Passo 7 — Parâmetros de Kernel para Diagnóstico (GRUB)

Ao editar a entrada do GRUB (premir e no menu), pode-se adicionar parâmetros ao kernel para obter mais informação de diagnóstico:

Com init=/bin/bash, o sistema arranca uma shell root sem systemd. É útil para reparar problemas onde o systemd não funciona de todo, mas nota-se que:

• O filesystem raiz é montado como read-only — remontar com mount -o remount,rw /
• Não há serviços (sem rede, sem udev)
• Para reiniciar: exec /sbin/init (para arrancar systemd) ou reboot -f

10. Outras Causas do Mesmo Sintoma

• /boot cheio — atualizações de kernel acumulam imagens antigas em /boot. Quando enche, o GRUB não consegue instalar o novo kernel ou initramfs. Sintoma: boot falha após apt upgrade. Fix: arrancar com kernel antigo, remover kernels antigos com pacman -R linux-old (Arch) ou apt-get autoremove --purge (Debian/Ubuntu).
• Driver NVIDIA proprietário incompatível com kernel — após atualização de kernel, o módulo NVIDIA pode não estar compilado para o kernel novo (em sistemas sem DKMS). Sintoma: ecrã preto após GRUB. Fix: arrancar com nouveau.modeset=0 ou kernel antigo, e reinstalar o driver NVIDIA com DKMS.
• Relógio do sistema incorrecto — se o RTC está desconfigurado (especialmente em dual-boot com Windows), o fsck pode recusar verificar filesystems com data futura. Fix: ajustar o relógio no UEFI/BIOS ou usar hwclock --systohc.
• Secure Boot bloqueia módulos não assinados — em sistemas com Secure Boot activado, módulos de kernel não assinados (como NVIDIA proprietário) são bloqueados. Sintoma: funciona sem Secure Boot, falha com. Fix: assinar módulos ou desactivar Secure Boot no UEFI.
• Btrfs corrupto — btrfs tem comportamentos diferentes de ext4/xfs quando corrompido. Se o fsck normal não funciona, usar btrfs check --repair (último recurso, pode piorar). Em casos graves, montar com -o ro,usebackuproot.
• RAID degradado ou em falta — em sistemas com mdadm (software RAID), se um disco falha e o array fica degradado, o boot pode falhar se o initramfs não tem mdadm hook. Fix: adicionar mdadm às HOOKS do mkinitcpio ou rd.md=1 nos parâmetros de kernel.
• fstab com mount point de rede sem _netdev — se o fstab tem um NFS/CIFS mount sem a opção _netdev, o systemd tenta montá-lo antes da rede estar disponível. Fix: adicionar _netdev às opções ou usar x-systemd.automount.
• kernel panic por hardware — RAM defeituosa, CPU overclock instável, ou PSU em falha. Correr memtest86+ para excluir problemas de RAM. Se o panic é intermitente e não reprodutível, considerar hardware.

11. Como Evitar Problemas de Boot no Futuro

• Manter pelo menos 2 kernels instalados — em Arch/Manjaro, instalar o pacote linux-lts como fallback. Se o kernel mainline tiver um bug, arrancar com o LTS. Em Debian/Ubuntu, o apt-get autoremove remove kernels antigos demasiado cedo — manter pelo menos o anterior manualmente.
• Usar snapshots do filesystem — se a raiz é btrfs ou ZFS, configurar snapshots automáticos pré-atualização com snapper ou zsys. Permite reverter em segundos com btrfs subvolume snapshot restore.
• Verificar boot após cada atualização major — após pacman -Syu ou apt upgrade que atualiza kernel ou GRUB, reiniciar imediatamente e verificar. Não esperar dias para descobrir que o sistema não arranca.
• Manter um live USB actualizado — ter um USB bootável com SystemRescue, Ubuntu ou Arch Linux live. Actualizar pelo menos uma vez por ano. SystemRescue é especialmente útil porque inclui gparted, testdisk, fsck e chroot tools.
• Backup do /boot e /etc — antes de atualizações major, fazer backup de /boot/grub/grub.cfg, /etc/fstab, /etc/mkinitcpio.conf (ou equivalente). Se algo correr mal, restaurar a configuração anterior.
• Usar DKMS para drivers de terceiros — instalar dkms e os drivers NVIDIA/VirtualBox com DKMS em vez de módulos compilados manualmente. O DKMS recompila automaticamente os módulos quando um kernel novo é instalado.
• Monitorizar S.M.A.R.T. dos discos — configurar smartd com alertas por email para bad sectors e temperaturas. Em servidores, usar smartmontools com relatórios diários.
• Não editar grub.cfg manualmente — o grub.cfg é gerado por grub-mkconfig. Para alterar parâmetros de kernel persistentemente, editar /etc/default/grub e depois correr grub-mkconfig -o /boot/grub/grub.cfg (ou update-grub em Debian/Ubuntu).
• Documentar a configuração de boot — guardar outputs de lsblk -f, blkid, cat /etc/fstab e grub-mkconfig -o /dev/stdout num ficheiro acessível. Isto permite comparar se algo mudar.
• UPS com shutdown gracioso — configurar apcupsd (APC), nut (Network UPS Tools) ou poweroff via ACPI para desligar o servidor antes de a bateria acabar. Previne corrupção de filesystem por cortes de energia.