Como o Linux Inicializa: Do BIOS/UEFI ao Login

2026-06-06 Tempo de leitura: Cerca de 13 min Dificuldade: Intermediario

O Que Você Vai Aprender

• A ordem exata dos eventos do ligar o computador até o prompt de login, traçada como uma única linha
• Como identificar qual estágio falhou quando uma máquina não inicializa
• Como observar o boot da sua própria máquina com systemd-analyze e journalctl -b

Quantos Estágios Tem um Boot do Linux?

Conclusão: Cinco estágios: firmware → bootloader → kernel → init → login. O trabalho de cada estágio é apenas iniciar o próximo, então identificar onde travou aponta imediatamente a causa.

Inicializar não é mágica; é uma corrida de revezamento. Ao ligar o computador, a única coisa em que se pode confiar é a CPU, e a partir daí o "círculo de confiança" se amplia um passo de cada vez. Cada estágio carrega o próximo na memória, passa o controle e se retira.

Power ON
  │
  ▼  (1) Firmware (BIOS / UEFI)    inicializa hardware, escolhe dispositivo de boot
  ▼  (2) Bootloader (GRUB)         carrega kernel + initramfs
  ▼  (3) Kernel                    controla hardware, descompacta initramfs
  ▼  (4) init (systemd / PID 1)    inicia serviços, alcança target
  ▼  (5) Login (getty / DM)        exibe prompt
Sistema utilizável

"Até onde chegou?" é a informação mais útil para diagnóstico. Se você vê o menu do GRUB, os estágios (1) e (2) funcionaram; se mensagens do kernel aparecem na tela, você chegou ao (3). O sintoma visível permite trabalhar de trás para frente até o estágio.

O Que BIOS e UEFI Realmente Fazem?

Conclusão: O firmware (BIOS / UEFI) inicializa o hardware e localiza um dispositivo inicializável, depois carrega o primeiro programa na memória. O UEFI pode iniciar um arquivo .efi diretamente da Partição do Sistema EFI, que é a diferença principal em relação ao BIOS.

Após ligar o computador, a primeira coisa a executar é o firmware na placa-mãe. Ele tem dois trabalhos.

• POST (Power-On Self-Test): verifica que o hardware principal (CPU, RAM, armazenamento) está presente e funcionando
• Seleção do dispositivo de boot: varre discos, USB e rede na ordem configurada para encontrar algo inicializável

É aqui que BIOS e UEFI divergem.

Em uma máquina UEFI, o executável do bootloader (ex.: /EFI/ubuntu/grubx64.efi) fica na ESP (EFI System Partition), uma pequena área FAT32. O UEFI a inicia diretamente, então o antigo truque do BIOS de embutir código no MBR não é mais necessário.

# Verificar se você inicializou via UEFI (este diretório existe apenas em boots UEFI)
$ ls /sys/firmware/efi

Para Que Serve o Bootloader (GRUB)?

Conclusão: O bootloader lê o kernel e o initramfs do disco para a memória e passa o controle ao kernel com parâmetros de boot. O GRUB também pode exibir um menu, permitir escolher um kernel e editar parâmetros em tempo real.

O firmware inicia o bootloader, e no Linux isso é mais comumente o GRUB 2. As tarefas do GRUB são:

• Escolher qual kernel / SO inicializar (aquele menu de seleção em preto)
• Carregar o kernel escolhido (vmlinuz) e o initramfs (initrd.img) na memória
• Passar o controle ao kernel com parâmetros do kernel (a cmdline)

Sua configuração é gerada em /boot/grub/grub.cfg, mas esse é um arquivo gerado automaticamente que você nunca deve editar diretamente. As fontes são /etc/default/grub e um conjunto de templates.

# Exibir o kernel e os parâmetros usados neste boot
$ cat /proc/cmdline

BOOT_IMAGE=/boot/vmlinuz-6.8.0-31-generic root=UUID=... ro quiet splash

root=UUID=... diz "este é o sistema de arquivos root real", e ro significa "montá-lo somente leitura no início". Quando algo quebra, pressionar e no menu do GRUB permite editar esta linha diretamente (por exemplo, remover quiet splash e adicionar single) para inicializar em modo de recuperação.

O Que o Kernel e o initramfs Estão Fazendo?

Conclusão: O kernel assume o controle da memória, CPUs e dispositivos, depois descompacta o initramfs como root temporário. O initramfs tem apenas os drivers suficientes para montar o root real; quando estiver pronto, ele muda para o root real.

Depois que o GRUB passa o controle, o kernel se descompacta e começa a gerenciar o hardware. Ele ativa o gerenciamento de memória e o escalonador de processos, habilita todos os núcleos da CPU e inicializa os drivers.

O elemento-chave aqui é o initramfs (initial RAM filesystem). Por que ele é necessário? Se o sistema de arquivos root real está sobre criptografia (LUKS), LVM, RAID ou um driver de disco especial, o kernel precisa de "o driver para montá-lo" antes de poder montá-lo. É um problema de galinha e ovo.

O initramfs resolve isso como um pequeno root temporário. O GRUB carregou esse arquivo na memória junto com o kernel; o kernel o descompacta na RAM e executa seu script init, que aproximadamente:

1. Carrega os módulos de kernel necessários (armazenamento, criptografia, etc.)
2. Ativa LVM, descriptografa LUKS e torna o root real visível
3. Monta o root real e usa switch_root para trocar o root por ele

# A detecção e os passos de init do kernel ficam em um buffer circular
$ dmesg | head

O trabalho do initramfs termina aqui; de agora em diante, o /sbin/init (ou seja, systemd) no root real entra em cena. Esta troca "root temporário -> root real" é o ponto central do boot, e é onde aparece o prompt de senha do disco criptografado.

O Que o init (systemd / PID 1) Inicia?

Conclusão: O primeiro processo iniciado no root real é o init, hoje geralmente systemd (PID 1). O systemd resolve dependências e inicia serviços (units) em paralelo, com o objetivo de alcançar um estado alvo (um target).

Após o switch_root, o primeiro processo de espaço de usuário que o kernel inicia no root real é o PID 1, init. Na maioria das distribuições modernas, esse papel pertence ao systemd. Sua característica é tratar serviços como um grafo de dependências e iniciar os independentes em paralelo (em contraste com o antigo SysVinit, que executava scripts de boot em série).

As unidades de inicialização que o systemd gerencia são chamadas de units.

• *.service … daemons / programas (ex.: sshd.service)
• *.mount … montagens de sistema de arquivos
• *.socket … listeners de socket
• *.target … um objetivo agrupando muitas units (o sucessor dos runlevels)

O objetivo do boot é alcançar o target padrão. Servidores tipicamente usam multi-user.target (CLI); desktops usam graphical.target (GUI).

# Mostrar o target padrão (sucessor dos runlevels)
$ systemctl get-default

graphical.target

O systemd segue as dependências a partir de default.target e inicia as units necessárias. Como outras units continuam mesmo que uma falhe, você pode isolar casos como "inicializou, mas apenas este serviço está fora."

De Onde Vem o Prompt de Login?

Conclusão: No passo final de alcançar o target, uma CLI usa getty para exibir um prompt login: em um terminal virtual, enquanto uma GUI usa um gerenciador de display (ex.: gdm) para exibir um login gráfico. Quando você chega aqui, o boot está completo.

Alcançar o target traz o ponto de entrada com o qual você interage.

• CLI (multi-user.target): getty (agetty) exibe um prompt login: em cada terminal virtual (tty1, etc.). Os terminais de texto simples que você alcança com Ctrl+Alt+F2 são esses.
• GUI (graphical.target): um gerenciador de display (gdm / sddm / lightdm, etc.) exibe uma tela de login gráfica e, após a autenticação, inicia uma sessão de desktop.

A autenticação é tratada pelo PAM (Pluggable Authentication Modules). Com sucesso, um shell (CLI) ou ambiente de desktop (GUI) inicia e o sistema está finalmente "utilizável". Esta é a linha de chegada do revezamento de boot.

Como Observar o Boot da Minha Própria Máquina?

Conclusão: Use systemd-analyze para o tempo total e unidades lentas, e journalctl -b para o log completo do boot atual. "Está lento" e "este serviço não inicia" são quase sempre resolúveis com esses dois.

Vamos verificar a teoria na sua própria máquina. O systemd mede e registra cada estágio de boot, então visualizá-lo é fácil.

# Tempo total de boot (firmware -> kernel -> espaço de usuário)
$ systemd-analyze

Startup finished in 4.123s (firmware) + 2.001s (loader) + 1.892s (kernel) + 6.540s (userspace) = 14.557s

O detalhamento firmware / loader / kernel / userspace mapeia exatamente para os estágios (1)-(4) deste artigo, então você pode ver de relance onde o tempo vai.

# Units que atrasaram o boot, mais lentas primeiro
$ systemd-analyze blame

# Ler apenas o log do boot atual (-b = boot atual)
$ journalctl -b

Resumo: Estágios de Boot e Tabela de Diagnóstico

Conclusão: "O que apareceu na tela" indica o estágio alcançado. Menu GRUB = (1)(2) ok, log do kernel = alcançou (3), prompt de emergência = (4) falhou ao montar root, login = sucesso total. Traduza o sintoma em um estágio e o escopo da causa fica fixo.

Mantenha o fluxo de boot em mente como cinco estágios de responsabilidade, e um vago "não inicializa" se torna a questão de qual estágio falhou. A partir daí, ler o log daquele estágio (dmesg / journalctl -b) leva diretamente à causa.