03 - Outros Bootloaders (LILO, systemd-boot, EFISTUB)

Embora o GRUB2 domine a vasta maioria das distribuições Linux empresariais e de desktop devido à sua resiliência e suporte a múltiplas arquiteturas de armazenamento (LVM, LUKS, RAID), o ecossistema de bootloaders do Linux é um espectro que varia do primitivismo de mapeamento de blocos físicos à abstração absoluta onde o próprio kernel assume a inicialização. A compreensão dessas alternativas (LILO, systemd-boot e EFISTUB) é fundamental para entender a evolução do processo de bootstrap e as otimizações possíveis em arquiteturas modernas.

1. LILO (LInux LOader): O Paradigma Monolítico de Mapeamento Direto

O LILO é um artefato histórico crítico, sendo o carregador de inicialização padrão do Linux durante a década de 1990 e início dos anos 2000, antes da ascensão do GRUB Legacy. Arquiteturalmente, o LILO opera no nível mais baixo possível de abstração de software, o que constitui simultaneamente sua maior eficiência em sistemas arcaicos e sua falha fatal em sistemas modernos.

A Ausência de um VFS (Virtual File System)

Diferente do GRUB, que possui mini-drivers para ler sistemas de arquivos (ext4, btrfs), o LILO é completamente cego em relação ao conceito de arquivos, diretórios ou inodes. Durante a inicialização, o binário do LILO residente no LBA 0 (MBR) não sabe o que é um sistema de arquivos.

Para que o LILO consiga carregar a imagem do kernel (vmlinuz) para a RAM, ele depende de um mapa físico de setores estritamente codificado, conhecido como Arquivo de Mapa (/boot/map).

O Ciclo Obrigatório de Atualização (/sbin/lilo)

A mecânica de funcionamento do LILO exige uma rotina operacional perigosa:

1. O administrador edita o arquivo de texto de configuração (/etc/lilo.conf), especificando o caminho lógico do kernel e do initrd.

2. O administrador é obrigatoriamente forçado a executar o comando /sbin/lilo no espaço do usuário.

3. Este utilitário lê o sistema de arquivos, localiza fisicamente os arquivos apontados no disco, traduz esses arquivos em uma lista contígua de endereços de blocos físicos (Cilindro-Cabeça-Setor ou LBA) e grava essa lista crua diretamente no arquivo /boot/map e no setor de boot.

Se o kernel for atualizado ou se um arquivo for movido pelo desfragmentador e o administrador esquecer de rodar /sbin/lilo, a máquina sofrerá um colapso no próximo boot. O LILO tentará ler os blocos antigos, que agora podem conter lixo ou dados de outros arquivos, resultando no temido erro de tela "LI", "LIL", ou "LIL-". O advento de sistemas de arquivos baseados em Copy-on-Write (como Btrfs) e alocação dinâmica (LVM) tornou a arquitetura matemática de mapeamento de blocos absolutos do LILO obsoleta e insegura.

2. systemd-boot: O Minimalismo Nativo UEFI

À medida que o firmware UEFI tornou-se o padrão incontestável, a necessidade de um bootloader complexo e massivo como o GRUB2 começou a ser questionada. A UEFI já implementa nativamente a leitura de sistemas de arquivos FAT32, inicialização de dispositivos gráficos e um console de texto. O projeto systemd-boot (anteriormente conhecido como gummiboot) nasceu da filosofia de não duplicar código que já existe no firmware da placa-mãe.

Integração Direta com a ESP (EFI System Partition)

O systemd-boot é um gerenciador de inicialização desenhado estritamente para sistemas UEFI puros. Ele não suporta particionamento MBR clássico ou BIOS legado.

A sua arquitetura baseia-se na Boot Loader Specification (BLS), uma padronização idealizada pela freedesktop.org. Em vez de utilizar um script monolítico complexo gerado por comandos pesados (como o grub.cfg e o grub-mkconfig), o systemd-boot utiliza arquivos de configuração de texto plano (drop-in snippets).

• O executável principal (geralmente systemd-bootx64.efi) é instalado no caminho de fallback da ESP (/EFI/BOOT/BOOTX64.EFI) ou em seu próprio diretório via utilitário bootctl install.

• A configuração global reside em loader/loader.conf na raiz da ESP, definindo apenas o tempo de timeout e a entrada padrão.

Entradas de Inicialização Modulares (BLS)

Cada sistema operacional ou versão de kernel possui seu próprio arquivo isolado no diretório loader/entries/ na partição FAT32 (ex: loader/entries/arch.conf). A anatomia de uma entrada BLS é minimalista:

Plaintext

title   Arch Linux
linux   /vmlinuz-linux
initrd  /initramfs-linux.img
options root=UUID=1234abcd-56ef-78gh... rw quiet

O Paradoxo da Localização do Kernel

A limitação primária da elegância do systemd-boot é que ele se recusa a implementar drivers de sistemas de arquivos adicionais. Portanto, ele só consegue ler arquivos que residam na mesma partição FAT32 onde ele foi instalado (a ESP). Isso obriga os administradores de sistemas que adotam o systemd-boot a montar a própria ESP no diretório /boot do Linux, garantindo que o gerenciador de pacotes coloque os binários do kernel e o initramfs diretamente dentro do sistema de arquivos FAT32 compreendido pela UEFI, ao invés de em uma partição ext4 separada.

3. EFISTUB (EFI Boot Stub): A Abstração Máxima

A evolução final e mais drástica no processo de carregamento do Linux não é um novo software bootloader, mas sim a eliminação conceitual da necessidade de um. Através do recurso EFISTUB, o próprio núcleo do Linux é convertido em um aplicativo executável UEFI nativo.

O Spoofing do Cabeçalho PE/COFF

Firmwares UEFI só executam binários compilados no formato PE32+ (Portable Executable, o mesmo padrão de empacotamento herdado do ecossistema Windows NT). O kernel Linux padrão (vmlinux) é compilado no formato ELF (Executable and Linkable Format), que a placa-mãe é incapaz de ler nativamente.

Para resolver essa barreira, o código-fonte do Linux introduziu a opção de compilação CONFIG_EFI_STUB. Quando o kernel é compilado com esta diretiva, o linker injeta cirurgicamente um cabeçalho PE/COFF falso no início da imagem comprimida bzImage. Do ponto de vista do firmware da placa-mãe, o arquivo /boot/vmlinuz não é um kernel alienígena; ele se apresenta perfeitamente como um aplicativo .efi legítimo.

O Processo de Inicialização Autônoma

No ambiente EFISTUB, o fluxo arquitetural ignora ferramentas de terceiros:

1. O firmware UEFI, durante a fase BDS (Boot Device Selection), consulta sua própria memória NVRAM.

2. A NVRAM aponta diretamente para a imagem do kernel residente na partição FAT32 (ESP).

3. O firmware carrega o kernel na memória RAM e invoca a função StartImage().

A Injeção de Parâmetros via NVRAM

Como não há grub.cfg ou loader.conf para ditar as regras (como root= e a localização do initrd), esses parâmetros devem ser informados antecipadamente ao próprio firmware. O administrador utiliza o utilitário de espaço do usuário efibootmgr para gravar toda a Kernel Command Line diretamente nos transistores de memória flash da placa-mãe:

Bash

efibootmgr --create --disk /dev/nvme0n1 --part 1 --label "Linux Direto" --loader /EFI/debian/vmlinuz --unicode 'root=UUID=... ro initrd=\EFI\debian\initrd.img'

Vantagens e Fragilidades Arquiteturais

• Desempenho e Segurança: O EFISTUB elimina o overhead computacional de inicializar um programa intermediário. O tempo de power-on até o início da descompressão do kernel é reduzido ao mínimo fisicamente possível. A superfície de ataque do Secure Boot é reduzida a um único binário validado.

• Fragilidade de Manutenção: A dependência estrita da NVRAM é o calcanhar de Aquiles do EFISTUB. Se a bateria da CMOS falhar de forma anômala, ou se uma atualização do firmware da BIOS/UEFI limpar a NVRAM, a entrada de inicialização (junto com os parâmetros cruciais do kernel) é evaporada. Sem um bootloader de fallback (como o GRUB no caminho padrão BOOTX64.EFI) ou um shell EFI acessível, o sistema torna-se imediatamente inoperante, exigindo intervenção via Live USB para reescrever as variáveis do efibootmgr.