04 - Recuperação e Reinstalação do GRUB

1. A Taxonomia da Falha de Inicialização

A falha do GRUB2 raramente é o resultado de uma corrupção de software interna ao próprio bootloader; na vasta maioria dos cenários estruturais, a interrupção da cadeia de inicialização decorre de uma violação externa da topologia de armazenamento ou de variáveis de firmware. Para que a recuperação seja cirúrgica e bem-sucedida, o administrador deve primeiro diagnosticar a natureza arquitetural da falha:

• Vetor de Falha em BIOS/MBR: A instalação de sistemas operacionais concorrentes (notoriamente o ecossistema Windows NT) sobrescreve o LBA 0 (Master Boot Record) de forma indiscriminada com seu próprio código binário de bootstrap. Adicionalmente, a clonagem incorreta de discos ou operações agressivas de particionamento podem destruir os blocos lógicos residentes no Post-MBR Gap, aniquilando o core.img (Estágio 1.5).

• Vetor de Falha em UEFI/GPT: A falha neste paradigma não envolve sobrescrita de setores ocultos, mas sim inconsistências de sistema de arquivos ou NVRAM. Pode ocorrer devido à formatação acidental da ESP (Partição de Sistema EFI), à exclusão inadvertida do diretório /EFI/ pelo usuário ou, mais frequentemente, à perda das variáveis BootXXXX na NVRAM da placa-mãe (causada por atualizações de firmware, reset CMOS ou baterias descarregadas em hardwares problemáticos).

2. O Paradigma do Chroot (Change Root) e Pseudo-sistemas de Arquivos

A técnica definitiva e incontornável para a recuperação de um bootloader destruído em nível de produção é o uso de um ambiente Live (como um pen drive USB contendo uma distribuição Linux funcional) combinado com o isolamento de espaço de nomes (namespace isolation) fornecido pela chamada de sistema chroot().

O utilitário chroot altera o diretório raiz visível para o processo em execução e seus filhos. Contudo, simplesmente apontar o chroot para uma partição montada no disco falho é insuficiente. Para que os binários utilitários do GRUB (grub-install e grub-mkconfig) consigam operar, eles precisam de acesso direto e de baixo nível aos barramentos físicos, aos blocos do disco e às variáveis da UEFI, recursos que o kernel host do Live USB gerencia através de pseudo-sistemas de arquivos em RAM.

Antes da transição via chroot, o administrador é obrigado a realizar montagens de vínculo (bind mounts). Uma montagem bind não cria um novo sistema de arquivos; ela espelha uma árvore de diretórios já existente do kernel host (o Live USB) diretamente para dentro da árvore do sistema quebrado.

3. Preparação Algorítmica do Ambiente de Resgate

O procedimento matemático de resgate exige uma ordem estrita de montagem para garantir a integridade dos caminhos absolutos:

I. Montagem da Topologia de Armazenamento Físico:

O administrador identifica a partição raiz (/) do sistema inoperante via lsblk ou blkid e a monta em um ponto temporário:

mount /dev/nvme0n1p3 /mnt

Se o sistema possui as partições /boot e /boot/efi (ESP) separadas, elas devem ser montadas rigorosamente respeitando a hierarquia da raiz recém-montada:

mount /dev/nvme0n1p2 /mnt/boot
mount /dev/nvme0n1p1 /mnt/boot/efi

II. Injeção das Interfaces do Kernel (Bind Mounts):

Esta é a etapa crítica onde o hardware e o estado do kernel do sistema de resgate são expostos ao sistema quebrado. Sem isso, o grub-install será incapaz de enxergar os discos (/dev) ou manipular a NVRAM (/sys).

mount --bind /dev /mnt/dev
mount --bind /dev/pts /mnt/dev/pts
mount --bind /proc /mnt/proc
mount --bind /sys /mnt/sys
mount --bind /run /mnt/run

Nota arquitetural: A montagem do /sys é de suma importância em sistemas UEFI, pois nela reside o subsistema efivarfs (/sys/firmware/efi/efivars), a única ponte de comunicação do Linux com o chip flash da placa-mãe.

III. A Transição de Contexto:

chroot /mnt /bin/bash

A partir da execução deste comando, o shell operará como se o sistema inoperante estivesse rodando nativamente. As bibliotecas ligadas, os binários e as configurações acessadas pertencem ao disco rígido resgatado, enquanto os recursos de hardware são passados passivamente pelo kernel do Live USB.

4. A Restauração Física e Lógica: O Comando grub-install

Com o ambiente isolado preparado, o utilitário grub-install é invocado. Este utilitário não é um binário simples, mas um orquestrador complexo que executa sub-rotinas dependendo da arquitetura detectada.

Cenário A: Recuperação em Modo BIOS/MBR

No ambiente legado, o GRUB precisa escrever bytes crus no disco. O comando aponta estritamente para o dispositivo de bloco raiz (o disco inteiro), não para uma partição:

grub-install /dev/sda

Operações subjacentes:
1. O GRUB compila um novo core.img (Estágio 1.5) contendo os módulos necessários para ler o /boot.
2. O utilitário grava silenciosamente este core.img nos setores do Post-MBR Gap físico do /dev/sda.
3. O utilitário reescreve o LBA 0 do disco (boot.img), configurando o ponteiro estático para apontar para o setor exato onde o novo core.img foi ancorado.

Cenário B: Recuperação em Modo UEFI/GPT

Em hardware moderno, não há edição de blocos raw fora das partições. O comando deve especificar o alvo da arquitetura e o caminho da ESP:

grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=GRUB_DEBIAN --recheck

Operações subjacentes:

1. O utilitário compila o aplicativo nativo UEFI grubx64.efi e o copia (junto com os módulos) para a árvore do sistema de arquivos FAT32 em /boot/efi/EFI/GRUB_DEBIAN/.
2. Após a cópia do arquivo, o grub-install invoca nos bastidores o utilitário efibootmgr.
3. O efibootmgr se comunica com o diretório /sys/firmware/efi/efivars e grava uma nova entrada de inicialização diretamente na NVRAM da placa-mãe, apontando o ponteiro de hardware para o arquivo recém-copiado, restaurando assim o sistema na lista de prioridades de boot do firmware.

5. Recalibração do Arquivo de Configuração (grub-mkconfig)

O comando grub-install apenas restabelece o vetor primário de execução (os estágios de transição). Ele não se importa com quais kernels estão instalados ou quais parâmetros eles exigem. Para finalizar a recuperação, a lógica interna do GRUB2 deve ser sincronizada com a realidade do disco.

Especialmente após a clonagem de discos para um novo SSD, as assinaturas UUID das partições mudam. Se o grub.cfg antigo não for atualizado, o bootloader restaurado carregará, mas entrará em Pânico ao tentar passar para o kernel um UUID que não existe mais.

grub-mkconfig -o /boot/grub/grub.cfg

A execução deste comando forçará a leitura do arquivo base em /etc/default/grub, a reavaliação de todos os scripts em /etc/grub.d/ e a exploração do /boot/ e UUIDs atuais via os-prober. O resultado será uma substituição integral do mapa lógico do boot, garantindo que as diretivas search dinâmicas reflitam o hardware contemporâneo.

6. O Caminho de Fallback (Contorno de Falhas Críticas de NVRAM)

Um cenário de borda notório em recuperação de sistemas UEFI ocorre quando a NVRAM da placa-mãe está fisicamente bloqueada, lotada (devido a falhas de firmware que não limpam despejos de falhas, como em alguns hardwares mais antigos) ou quando a mídia é projetada para ser portátil (um disco SSD externo transportado entre máquinas).

Nesses casos, a chamada interna do efibootmgr durante o grub-install falha catastroficamente (retornando erros de No space left on device na gravação da variável EFI).

Para garantir o sucesso do resgate, o administrador pode forçar o grub-install a explorar a regra de contingência estipulada pela arquitetura UEFI (a mídia removível padrão):

grub-install --target=x86_64-efi --efi-directory=/boot/efi --removable

A flag --removable instrui o GRUB2 a abandonar a tentativa de registrar variáveis na placa-mãe. Em vez disso, ele compila o binário de boot e o renomeia agressivamente para \EFI\BOOT\BOOTX64.EFI na partição FAT32. Virtualmente todo firmware UEFI Classe 2 e 3 do planeta está codificado internamente para buscar por este caminho exato como último recurso, permitindo o boot do Linux mesmo que o subsistema NVRAM esteja completamente corrompido ou inacessível.****