Grub: instale apenas as partes do MBR, não o diretório de inicialização?

Quando o GRUB inicializa a partir de um MBR, o número de etapas de compatibilidade do BIOS herdado que ele precisa executar no início do processo de inicialização significa que o código realmente no MBR só é capaz de carregar um bloco de disco cujo número LBA é corrigido para o MBR código no momento da instalação. Esse bloco é geralmente o primeiro bloco da imagem principal do GRUB . Ele contém o código para carregar mais blocos e uma lista de números de bloco que definem onde o restante da imagem principal do GRUB está localizado.

Em um disco particionado por MBR, geralmente há espaço não utilizado entre o MBR e o início da primeira partição. Com o MS-DOS, a convenção original era iniciar a primeira partição no início da próxima faixa de disco, o que geralmente significa que haverá pelo menos 63 blocos de disco antes da primeira partição, incluindo o MBR. Em sistemas modernos, a primeira partição MBR é agora mais comumente colocada para iniciar exatamente 1MiB desde o início do disco, ou seja, no bloco #2048, para otimizar o alinhamento de dados para discos, SSDs e sistemas de armazenamento SAN que podem usar internamente um bloco tamanho maior que 512 bytes.

Portanto, em um disco particionado por MBR, o início do disco normalmente é organizado assim:

• bloco nº 0: MBR
• bloco #1: primeiro bloco da imagem principal do GRUB, contém a lista de blocos
• blocos #2...#n: o restante da imagem principal do GRUB
• bloco #2048: início da primeira partição.

Observe que o carregamento da imagem principal do GRUB funciona exclusivamente por números de bloco pré-determinados: até que a imagem principal do GRUB seja totalmente carregada e extraída, o GRUB não terá conhecimento de tabelas de partição nem sistemas de arquivos de qualquer tipo.

Em um disco particionado por GPT, os blocos imediatamente após o bloco #0 são ocupados pela tabela de partição GPT, portanto, a imagem principal do GRUB é incorporada em uma "partição de inicialização do BIOS". Isso significa apenas que o número do bloco incorporado ao MBR não será 1, mas sim o número do primeiro bloco da partição de inicialização do BIOS, e o restante dos blocos pertencentes à imagem principal também será deslocado. Portanto, em um disco particionado por GPT com GRUB no estilo BIOS, o layout físico será algo assim, supondo que a partição de inicialização do BIOS seja a primeira no disco:

• bloco #0: MBR de proteção GPT, com código GRUB MBR incorporado
• blocos #1...#(x-1): tabela de partição GPT real
• bloco #x: o primeiro bloco da partição de inicialização do BIOS, contém o primeiro bloco da imagem principal do GRUB com a lista de blocos
• blocos #(x+1)...#(x+n): o restante da imagem principal do GRUB

O fato de você ainda poder acessar o modo de recuperação do GRUB indica que, embora você tenha dito que removeu sua partição de inicialização do BIOS, você ainda não sobrescreveu seus blocos; embora o espaço ocupado pela partição de inicialização do BIOS agora possa ser espaço não alocado entre partições ou espaço não utilizado em outra partição redimensionada, ela ainda tem seu conteúdo antigo e o GRUB ainda pode carregar esses blocos e encontrar sua imagem principal. Mas nada em particular protege esses blocos agora de serem substituídos: assim que isso acontecer por qualquer motivo, a imagem principal do GRUB será destruída e o GRUB não conseguirá chegar até o modo de resgate.

Conteúdo da imagem principal do GRUB

A imagem principal do GRUB contém várias coisas:

• o kernel do GRUB: esta é a única parte tecnicamente necessária para entrar no modo de recuperação do GRUB.
• caminho raiz inicial do GRUB incorporado, para indicar qual disco, partição e diretório dentro dele contém o arquivo de configuração do GRUB e o diretório de módulos do GRUB. No Linux, eles normalmente aparecem como /boot/grub/grub.cfge /boot/grub/i386-pcrespectivamente quando o sistema Linux está rodando normalmente.
• um conjunto de módulos GRUB embutidos, contendo pelo menos o código para ler e entender a tabela de partição e o tipo de sistema de arquivos usado na partição referida pelo caminho raiz inicial do GRUB. Como a imagem principal pode precisar caber em menos de 63 blocos de disco, esse conjunto de módulos geralmente é mantido o mínimo possível em sistemas MBR.
• opcionalmente, um arquivo de configuração GRUB incorporado com um ou mais comandos GRUB
• opcionalmente, uma imagem de disco incorporada, semelhante às usadas pela memdiskferramenta da família de bootloader SYSLINUX
• opcionalmente, uma chave pública GPG usada para assinar outros módulos GRUB e o kernel do sistema operacional para segurança (e para atender aos requisitos de aceitação de inicialização segura nas versões UEFI do GRUB)

Tudo isso é compactado em LZMA para minimizar seu tamanho, portanto, não pode ser lido ou modificado manualmente com facilidade.

Como agora você está entrando no modo de recuperação e não pode listar suas partições, isso indica que a imagem principal do GRUB contém o módulo de particionamento para GPT ( part_gpt.mod), mas não para MBR ( part_msdos.mod). Sem o módulo de particionamento MBR, ele não pode acessar o /boot/grub/i386-pcdiretório que contém a partição, mesmo que a imagem principal do GRUB contenha o módulo de driver do sistema de arquivos aplicável a ele... e, portanto, o GRUB não pode carregar o normal.modque permitiria prosseguir além do modo de recuperação.

O que precisa acontecer agora

• A imagem principal do GRUB pode precisar ser reescrita em um local seguro, provavelmente no espaço entre o MBR e o início da primeira partição, que anteriormente era ocupada pelas estruturas da tabela de partição GPT. Como a partição de inicialização do BIOS foi removida, o local atual não é seguro: pode ser realocado para outra partição e ser substituído sem aviso no futuro.
• ao reescrever a imagem principal do GRUB, o módulo de particionamento GPT embutido nele precisa ser substituído pelo módulo de particionamento MBR. Como todos os componentes devem estar à mão em formato descompactado (at /usr/lib/grub/i386-pcou diretório similar), a maneira mais simples de fazer isso é apenas pegar todos os componentes descompactados apropriados, construir uma nova imagem principal a partir deles e compactá-la. Descompactar o antigo e modificá-lo simplesmente não vale a pena: por que escrever outro pedaço de código ao reutilizar o código usado ao instalar inicialmente o GRUB do zero funciona bem?
• Como a localização da imagem principal do GRUB provavelmente mudará, o código MBR também precisa ser reescrito.
• O grub-installcomando precisará de alguma forma garantir que o normal.mode outros módulos GRUB localizados /boot/grub/i386-pcsejam da mesma versão que a nova imagem principal do GRUB. Claro, ele poderia comparar os arquivos existentes com o conjunto de arquivos usado para reconstruir a imagem principal, mas novamente ... por que escrever e depurar código para outro caso especial ao simplesmente substituir o conteúdo existente pela /boot/grub/i386-pcrotina de instalação do GRUB já existente funciona direitinho?

O tamanho total não compactado de todos os i386-pccomponentes do GRUB é definitivamente menor que 4 MiB. Isso não é nada. Tentar evitar reescrever que, se já existe, simplesmente não vale a pena, a menos que você esteja trabalhando com algo especial como os antigos SSDs PATA de primeira geração com um número muito restrito de ciclos de gravação disponíveis.

Como o UEFI nativo faria isso?

Como o firmware UEFI inclui suporte ao sistema de arquivos FAT32 como padrão, a versão UEFI nativa do carregador de inicialização GRUB pode ser empacotada como um único grubx64.efiarquivo que contém todos os módulos necessários, inclusive normal.mod se você desejar. Ele é carregado como um arquivo normal: não há necessidade de mexer com números de bloco ou código embutido em locais de disco fixo.