01 - Estágios do GRUB (boot.img, core.img, -boot-grub)

A arquitetura do GRUB2 é uma obra-prima de engenharia de software desenhada para contornar uma das restrições de design mais arcaicas da computação: o limite físico do Master Boot Record (MBR). Como é matematicamente impossível alocar a complexidade de um sistema que suporta criptografia, redes e dezenas de sistemas de arquivos dentro de um único bloco magnético de $512 \text{ bytes}$, o GRUB2 fragmenta sua execução em estágios estritamente coreografados.

O carregamento em estágios é uma técnica de bootstrap onde cada minúsculo pedaço de código possui apenas a inteligência suficiente para localizar, carregar na memória e executar o próximo pedaço de código, ligeiramente maior e mais capaz, até que o ambiente completo seja estabelecido.

1. Estágio 1: boot.img (O Ponto de Ignição)

Em sistemas inicializados via BIOS/MBR, o Estágio 1 é representado pelo arquivo físico binário boot.img. Durante a instalação do GRUB (via comando grub-install), o conteúdo exato deste arquivo é gravado fisicamente no LBA 0 (Logical Block Addressing 0) do disco primário.

Devido à estrutura rígida do MBR, o código executável do boot.img está confinado aos primeiros $446 \text{ bytes}$ do setor (os bytes restantes são reservados para a Tabela de Partições primária e a assinatura mágica 0x55AA).

A inteligência do boot.img é virtualmente nula. Ele:

1. Não entende sistemas de arquivos.
2. Não entende partições (primárias ou lógicas).
3. Comunica-se com o disco usando apenas a interrupção legada do BIOS INT 13h (usualmente extensões LBA).

Sua única e exclusiva missão existencial é ler um endereço de bloco de disco codificado a hardcode em seu próprio binário durante o processo de instalação, carregar o primeiro setor correspondente ao próximo estágio para a memória RAM e realizar um salto de execução (JMP) para ele. Se o disco for desfragmentado em nível de bloco ou repartitionado incorretamente, os endereços físicos mudam e o boot.img apontará para o vazio, causando o temido erro "GRUB Loading".

2. O Post-MBR Gap e a Formação do core.img (Estágio 1.5)

O destino do salto do boot.img é o core.img, frequentemente chamado de Estágio 1.5. A genialidade e a complexidade do GRUB2 residem na construção e no posicionamento lógico deste arquivo.

Ao contrário do boot.img, que é estático, o core.img é um binário dinamicamente gerado e customizado no momento em que o administrador executa o grub-install. O utilitário concatena vários minibinários para formar um microkernel sob medida:

1. diskboot.img: O primeiro setor do core.img. Sua função é ler o restante do próprio core.img do disco para a RAM.
2. lzma_decompress.img: Uma rotina de descompressão microscópica.
3. kernel.img: O núcleo real do GRUB2 (compactado).
4. Módulos Embutidos (Built-in modules): Para que o GRUB2 consiga ler a partição /boot real, ele embute no core.img os drivers de disco estritamente necessários. Por exemplo, se o seu diretório /boot está em uma partição formatada em Btrfs sobre LVM, o grub-install injeta os módulos btrfs.mod e lvm.mod diretamente dentro do core.img.

O Desafio de Armazenamento: "Mapeamento em Bloco" vs "Embedding"

O problema central é onde armazenar fisicamente esse core.img (que geralmente tem entre $30 \text{ KB}$ e $100 \text{ KB}$). Existem duas abordagens possíveis, dependendo da topologia do disco:

• Abordagem 1: Embedding no "Post-MBR Gap" (Recomendado/Padrão):
  Historicamente, para manter alinhamento de cilindros e performance magnética, a primeira partição primária de um disco não começa no Setor 1. Ela começa no Setor 2048 (uma margem de $1 \text{ Megabyte}$).
  O espaço entre o MBR (Setor 0) e o início da primeira partição (Setor 2047) é chamado de Post-MBR Gap (ou DOS Compatibility Region). O GRUB2 considera esta área como uma terra de ninguém (uma zona sem formatação e sem sistema de arquivos). O comando de instalação grava o binário bruto do core.img diretamente nesses setores físicos ocultos. Isso blinda o GRUB2 contra corrupções causadas por modificações no sistema de arquivos do Linux.
• Abordagem 2: Blocklists (Falha/Desaconselhado):
  Se não houver espaço oculto (ex: partições que começam imediatamente após o MBR ou certas topologias RAID), o grub-install é forçado a colocar o core.img dentro de um sistema de arquivos normal (ex: /boot/grub/i386-pc/core.img) e gravar no boot.img a lista exata dos números de setores onde o arquivo caiu (blocklists). Esta abordagem é extremamente frágil; qualquer alteração no arquivo pelo SO destrói o mapa de setores e impede o boot.

Em discos particionados com GPT (GUID Partition Table) operando sob BIOS legado, a especificação GPT não deixa um "Post-MBR Gap" não documentado; a tabela de partições secundária ocupa espaço crítico. Para resolver isso, o administrador é obrigado a criar uma partição minúscula (geralmente de $1 \text{ a } 2 \text{ MB}$) com a flag específica bios_grub (Código GUID 21686148-6449-6E6F-744E-656564454649). O GRUB2 a utilizará estritamente como a zona de despejo bruta para o core.img.

3. Estágio 2: O Ambiente Dinâmico em /boot/grub/

Uma vez que o core.img (Estágio 1.5) é descomprimido na memória e executado, o GRUB2 ganha "consciência" do sistema de arquivos. Ele utiliza os módulos previamente embutidos (ext4.mod, part_gpt.mod, etc.) para montar lógica e abstratamente a partição onde reside o diretório /boot/grub/ (ou /boot/grub2/ em distribuições Red Hat).

Este evento marca a transição para o Estágio 2. A partir deste milissegundo, o GRUB2 deixa de se preocupar com limitações de tamanho e passa a se comportar como um sistema operacional independente:

1. Definição do prefix e da raiz (root): O GRUB define variáveis internas que apontam para o caminho absoluto do seu próprio ambiente de execução (ex: set prefix=(hd0,gpt2)/boot/grub).
2. Carregamento do módulo normal.mod: O core.img carrega o módulo principal responsável por prover toda a interface interativa e o terminal completo (o "Normal Shell").
3. Avaliação do grub.cfg: O interpretador de shell entra em ação, analisando os laços de repetição, condições booleanas, variáveis dinâmicas e blocos de menu do arquivo de configuração principal.
4. Carga Tardia de Módulos (Late Binding): Se o script do grub.cfg requerer recursos visuais sofisticados, ele instruirá o GRUB2 a carregar dinamicamente arquivos como gfxterm.mod (para alta resolução gráfica), png.mod (para ler o wallpaper de fundo) e carregará as fontes .pf2 do diretório fonts/.

Todo esse ecossistema reside fisicamente no sistema de arquivos do Linux na pasta /boot/grub/x86_64-efi/ (ou i386-pc/), expondo dezenas de binários .mod que podem ser chamados via comando interativo insmod a qualquer momento pelo usuário.

4. A Metamorfose sob UEFI: A Unificação de Estágios

É crucial notar que a narrativa detalhada acima (boot.img $\rightarrow$ Post-MBR Gap $\rightarrow$ core.img) descreve estritamente a arquitetura de resgate para o emaranhado histórico do BIOS legado.

Em sistemas puros operando sob a especificação UEFI, a dependência de hacks de setores físicos é completamente obliterada. O firmware UEFI já possui nativamente a inteligência de sistema de arquivos (lendo nativamente FAT32/ESP) e compreende o formato binário PE32+.

Sob UEFI:

• O arquivo boot.img não existe. O LBA 0 (MBR Protetor no disco GPT) não contém código de inicialização.
• Não existe a necessidade de um espaço oculto (Post-MBR Gap) nem a partição bios_grub.
• O core.img perde o seu papel de intermediário oculto. Em vez de ser embutido como blocos crus, o grub-mkimage empacota o núcleo do GRUB2 juntamente com os módulos iniciais em um arquivo executável UEFI nativo. O resultado é batizado de grubx64.efi.

Nesse paradigma, o firmware UEFI executa o aplicativo grubx64.efi localizado na Partição de Sistema EFI (ESP). Uma vez carregado, este executável assume diretamente o papel de transição para o Estágio 2, montando a partição /boot e buscando seu ecossistema modular no diretório /boot/grub/ exatamente como faria no ambiente BIOS, porém com endereçamento linear nativo de 64 bits e privilégios de execução providos pelos Boot Services da UEFI.