Menu GRUB poluído por sistemas desinstalados

O distro hopping (prática de instalar e remover distribuições Linux sucessivamente no mesmo disco) é o caso clássico de geração de lixo no stack de boot. Cada instalação de uma distro (Android x86, Manjaro, PopOS, etc.) grava entradas na NVRAM da placa-mãe (via firmware UEFI) e deposita arquivos .efi na EFI System Partition (ESP), geralmente montada em /boot/efi.

O problema: na desinstalação, a maioria das distros não faz housekeeping de nenhuma dessas duas camadas. O resultado é um menu de boot poluído com entradas fantasmas que apontam para sistemas que não existem mais no disco, ou pior: o GRUB da distro ativa redescobre esses resíduos e os exibe no menu principal.

Neste guia documento a auditoria forense completa de ambas as camadas, com os comandos reais usados na resolução.

1) Introdução e o cenário de boot poluído#

A dinâmica de testes e migrações frequentes de sistemas operacionais gera resíduos persistentes nas tabelas de boot do hardware e do disco. Muitas distribuições Linux, ao serem removidas pela exclusão simples de suas partições de sistema, deixam rastros mortos nas tabelas de firmware da placa-mãe e arquivos binários órfãos na partição EFI. Esses resíduos causam lentidão na carga do menu do firmware, poluição visual do menu do GRUB e, em cenários extremos, problemas de priorização de boot que podem impedir a inicialização automática do sistema operacional principal. A resolução permanente desse quadro exige ação nas camadas lógica (filesystem) e física (NVRAM).

2) Backups preventivos obrigatórios (NVRAM, ESP e GRUB)#

Qualquer alteração nas tabelas da NVRAM da placa-mãe ou nos arquivos da partição EFI envolve riscos de travamento do ciclo de boot do hardware. Antes de iniciar qualquer remoção, execute a cópia de segurança exaustiva de todas as estruturas de inicialização do servidor. Execute os comandos no terminal como usuário root:

# 1. Exportar e salvar o estado detalhado atual das variáveis NVRAM
sudo efibootmgr -v > /root/efibootmgr-backup-$(date +%Y%m%d).txt

# 2. Realizar backup preventivo completo das configurações do GRUB
sudo cp /etc/default/grub /root/grub.bak.$(date +%Y%m%d)
sudo cp /boot/grub/grub.cfg /root/grub.cfg.bak.$(date +%Y%m%d)

# 3. Compactar e fazer backup completo de todos os binários da partição ESP
sudo tar czf /root/efi-backup-$(date +%Y%m%d).tar.gz /boot/efi/

Verifique se os backups foram gravados corretamente e possuem tamanho superior a zero utilizando:

cat /root/efibootmgr-backup-$(date +%Y%m%d).txt
tar -tzf /root/efi-backup-$(date +%Y%m%d).tar.gz | head -10

3) Verificação de estado do secure boot#

O Secure Boot exige que todos os bootloaders e módulos de kernel carregados possuam assinaturas digitais válidas registradas na NVRAM (chaves PK, KEK e db). Ao gerenciar ou remover entradas, verifique se a funcionalidade está ativa para evitar problemas de rejeição de assinatura do loader secundário:

1. Verifique o status operacional do Secure Boot na máquina:

mokutil --sb-state 2>/dev/null || echo "Ferramenta mokutil não instalada ou indisponível"

1. Certifique-se de que os arquivos do shim (carregador assinado e validado pela Microsoft) e o grubx64 (o GRUB convencional) correspondentes à distribuição atual estejam presentes:

ls -la /boot/efi/EFI/ubuntu/shimx64.efi
ls -la /boot/efi/EFI/ubuntu/grubx64.efi

Se o Secure Boot estiver Enabled, a NVRAM da placa-mãe deve priorizar o caminho do shimx64.efi para que o carregamento aconteça sem violações de segurança.

4) Auditoria física de hardware: NVRAM UEFI via efibootmgr#

A camada física de boot reside na NVRAM (Non-Volatile Random Access Memory) da placa-mãe. Liste o estado atual do hardware executando:

sudo efibootmgr

Saída real analisada no laboratório:

BootCurrent: 0001
BootOrder: 0001,0007,0004,0000
Boot0000  Windows Boot Manager	HD(3,GPT,5dfd8a4f-23e3-48e8-8ec8-f640fd4b2c02,0xbe57000,0x32000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)...
Boot0001* Ubuntu	HD(3,GPT,5dfd8a4f-23e3-48e8-8ec8-f640fd4b2c02,0xbe57000,0x32000)/File(\EFI\ubuntu\shimx64.efi)
Boot0004  Network Card 	BBS(Network,,0x0)...
Boot0007* ubuntu	HD(3,GPT,5dfd8a4f-23e3-48e8-8ec8-f640fd4b2c02,0xbe57000,0x32000)/File(\EFI\Ubuntu\grubx64.efi)

Análise técnica detalhada da saída:

• BootCurrent: 0001: O kernel do Linux ativo iniciou pelo slot Boot0001.
• Boot0001* (com asterisco): Indica que a entrada está ativa e utilizável no firmware UEFI.
• Boot0007*: Uma entrada duplicada apontando diretamente para o grub desprotegido (grubx64.efi), que deve ser limpa caso o Secure Boot esteja ativo.

Remoção cirúrgica de entrada zumbi na NVRAM: Caso identifique um sistema antigo (por exemplo, Boot0003 Manjaro ou Boot0007 redundante), efetue a deleção informando o ID hexadecimal correspondente:

sudo efibootmgr -b 0007 -B

• A flag -b seleciona a entrada.
• A flag -B deleta a entrada da NVRAM da placa-mãe.

5) Auditoria lógica de disco: ESP e partições zumbis#

Com a NVRAM ajustada, passo para a camada de armazenamento lógico do disco. O utilitário os-prober (chamado no script de geração do GRUB) varre a partição de sistema EFI montada no diretório /boot/efi e as tabelas de partições brutas do disco em busca de assinaturas de bootloaders antigos.

A contaminação acontece através de duas fontes:

1. Pastas antigas de distribuições desinstaladas dentro do diretório /boot/efi/EFI/.
2. Partições de sistema remanescentes no disco físico que ainda retêm rótulos (labels), arquivos /etc/fstab ou estruturas de boot instaladas.

6) Verificação e diagnóstico de BIOS/UEFI firmware#

Parâmetros internos do setup físico da placa-mãe podem interferir diretamente na reconstrução da ordem de boot do sistema. Durante a auditoria, verifique as especificações do firmware do hardware:

1. Obtenha a versão, data de compilação e fabricante do firmware BIOS/UEFI:

sudo dmidecode -t bios | head -10

1. Certifique-se de acessar o setup físico da placa-mãe durante o reinício e validar as seguintes políticas:

• Fast Boot: Desative essa opção temporariamente. O Fast Boot ignora etapas críticas de carregamento de drivers USB e de discos secundários durante o ciclo de POST, podendo mascarar alterações de hardware feitas pelo efibootmgr.
• Boot Order: Verifique se o primeiro dispositivo listado na prioridade de inicialização aponta exatamente para a entrada ativa correspondente da NVRAM (como "Ubuntu" ou "shimx64.efi").

7) Verificação de partições ativas antes da formatação#

Antes de formatar ou remover qualquer partição identificada como zumbi no disco (como um antigo filesystem do Manjaro ou Android x86), certifique-se de que a partição não está sob uso ativo por processos do sistema, o que evitará a corrupção do disco:

1. Verifique se a partição alvo (exemplo: /dev/sda4) está montada no sistema de arquivos ativo:

mount | grep -i "/dev/sda4" || echo "A particao nao esta montada."

1. Caso esteja montada, identifique e finalize quaisquer arquivos abertos ou processos vinculados ao ponto de montagem:

# Listar processos com arquivos abertos na particao
sudo lsof +D /mnt/zombie_mount/ 2>/dev/null

# Identificar IDs de processos usando a particao
sudo fuser -v /mnt/zombie_mount/ 2>/dev/null

Apenas execute a formatação (mkfs) se a partição estiver desmontada (umount) e sem processos ativos associados.

8) Remoção de pastas zumbis e auditoria de permissões da ESP#

Acesse o diretório de dados do sistema de arquivos EFI para identificar pastas remanescentes:

sudo ls -la /boot/efi/EFI/

8.1 auditoria de permissões do diretório EFI#

Como a partição ESP utiliza o sistema de arquivos FAT32 (vfat) devido à exigência das especificações UEFI, ela possui mapeamento diferenciado de permissões no Linux. Execute o comando stat para auditar a saúde da montagem:

stat /boot/efi/

As permissões esperadas da pasta de montagem são 0700 ou 0755 com proprietário atribuído como root:root.

8.2 auditoria de integridade do shim e GRUB#

Antes de remover diretórios zumbis, teste o tipo de arquivo e a assinatura do bootloader principal atual para certificar-se de que não há corrupção:

file /boot/efi/EFI/ubuntu/shimx64.efi

8.3 remoção cirúrgica#

Proceda com a remoção dos diretórios que correspondem a sistemas desinstalados. ⚠️ ATENÇÃO: Nunca delete os diretórios "Microsoft", "ubuntu" ou "BOOT", pois isso inviabilizará o boot da máquina.

# Remover os rastros do Manjaro e do Android
sudo rm -rf /boot/efi/EFI/manjaro
sudo rm -rf /boot/efi/EFI/android

# Confirmar a delecao limpa do diretorio
sudo ls /boot/efi/EFI/

9) Verificação e proteção de dual boot com Windows#

Em cenários de dual boot híbridos contendo sistemas operacionais Windows, a partição e as pastas do Windows Boot Manager devem ser preservadas e validadas:

1. Certifique-se de que os arquivos do gerenciador de inicialização do Windows estão presentes no disco na pasta apropriada:

ls -la /boot/efi/EFI/Microsoft/Boot/bootmgfw.efi

1. Certifique-se de que o utilitário os-prober está instalado e habilitado nas configurações do GRUB em /etc/default/grub para detectar o Windows (em distribuições como Ubuntu 22.04+, caso o utilitário não venha instalado, instale-o previamente com sudo apt install os-prober). A linha abaixo deve estar configurada:

GRUB_DISABLE_OS_PROBER=false

1. Gere o menu executando update-grub (que regrava /boot/grub/grub.cfg) e confira se a detecção do Windows Boot Manager aparece na saída:

sudo update-grub | grep -i "Windows"

10) Regeneração e validação de integridade do bootloader#

Caso haja necessidade de reescrever ou corrigir os arquivos binários do GRUB na partição EFI (por exemplo, após corrupção ou exclusão acidental de arquivos de sistema), proceda com a reinstalação física dos loaders:

1. Instale o GRUB apontando para a partição de sistema EFI montada:

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

1. Atualize o arquivo initramfs para certificar-se de que os módulos do kernel de boot estão consistentes:

sudo update-initramfs -u -k all

1. Valide se a imagem do kernel e o initrd correspondentes estão presentes no diretório /boot/:

ls -la /boot/vmlinuz-*
ls -la /boot/initrd.img-*

11) Validação pós-limpeza e monitoramento#

Após efetuar a remoção na NVRAM e na partição EFI, confirme que o menu final foi regenerado sem apontar para as pastas fantasmas:

1. Execute a regeneração do arquivo de configuração do GRUB:

# Em distribuições Debian / Ubuntu / Pop!_OS:
sudo update-grub

# Em distribuições Arch Linux / Manjaro:
sudo grub-mkconfig -o /boot/grub/grub.cfg

1. Verifique se as distribuições excluídas sumiram da saída e do log de compilação:

# Debian / Ubuntu / Pop!_OS:
sudo update-grub 2>&1 | tee /tmp/grub-rebuild.log

# Arch Linux / Manjaro:
# sudo grub-mkconfig -o /boot/grub/grub.cfg 2>&1 | tee /tmp/grub-rebuild.log

grep -i -E "manjaro|android" /tmp/grub-rebuild.log || echo "Sucesso: Sistemas fantasmas limpos."

1. Exiba novamente o layout de partições para atestar que os discos zumbis foram limpos ou formatados:

lsblk -f

12) Procedimento de rollback e recuperação de desastres#

Se o sistema operacional falhar ao reiniciar ou se você remover acidentalmente uma entrada ativa da NVRAM, siga este roteiro de recuperação:

1. Se a entrada da NVRAM foi removida incorretamente, recrie-a apontando para o arquivo de shim assinado do disco:

sudo efibootmgr --create --disk /dev/sda --part 1 --loader /EFI/ubuntu/shimx64.efi --label "Ubuntu" --unicode

(Ajuste o parâmetro --disk e --part com o disco e número da partição EFI correspondentes).

1. Se as pastas da ESP foram removidas por engano, restaure os arquivos a partir do backup compactado exato gerado na seção 2:

sudo tar -xzf /root/efi-backup-$(date +%Y%m%d).tar.gz -C /

(Caso a restauração ocorra em data diferente da criação, substitua a variável pela data exata do arquivo gerado).

1. Reinstale o GRUB e atualize os arquivos de configuração para estabilizar as alterações:

sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=ubuntu

# Debian / Ubuntu / Pop!_OS:
sudo update-grub

# Arch Linux / Manjaro:
# sudo grub-mkconfig -o /boot/grub/grub.cfg

13) Checklists de limpeza e matriz de riscos#

13.1 checklist operacional de limpeza do boot#

Siga a lista de verificação abaixo antes e após os procedimentos de manutenção:

• [ ] Criados os backups preventivos da NVRAM, do arquivo /etc/default/grub e do diretório /boot/efi.
• [ ] Verificado o status do Secure Boot e a presença dos loaders assinados.
• [ ] Auditados os parâmetros BIOS/UEFI (Fast Boot desativado).
• [ ] Listadas e identificadas as entradas fantasmas na NVRAM do hardware via efibootmgr.
• [ ] Removidas as entradas zumbis da NVRAM através da flag -B.
• [ ] Verificado se as partições zumbis estão desmontadas e sem processos em execução antes de formatar.
• [ ] Auditadas as permissões e o proprietário da partição ESP.
• [ ] Excluídas as pastas órfãs das distros antigas no diretório /boot/efi/EFI/.
• [ ] Validada a presença e detecção da partição de boot do Windows.
• [ ] Reinstalado o GRUB e regeneradas as configurações de boot via update-grub (ou grub-mkconfig).
• [ ] Realizado teste de reinicialização para validação prática das modificações.

13.2 matriz de riscos de boot e severidade#

Conclusão#

Neste guia cobri as duas camadas de resíduos — a física na NVRAM via efibootmgr e a lógica na partição ESP via arquivos órfãos — e o procedimento de rollback para cada falha. Ao isolar a limpeza em etapas independentes, fazer backups preventivos exaustivos e validar a integridade dos bootloaders com assinaturas do Secure Boot ativas, você garante um sistema estável, sem entradas fantasmas e com tempo de inicialização otimizado. Se o boot não responder após uma limpeza incorreta, o backup preventivo da seção 2 é o seu caminho seguro de volta.

Veja também

Infraestrutura Anatomia de um subsistema fantasma: debugging bluetooth no Linux

Infraestrutura Tempestade perfeita em hardware legado

Infraestrutura Migração arquitetural WSL: integrando Podman e Distrobox para um workflow enterprise bare-metal

Este post está licenciado sob CC BY-NC.