Arch boot process (Português)

Status de tradução: Esse artigo é uma tradução de Arch boot process. Data da última tradução: 2025-03-05. Você pode ajudar a sincronizar a tradução, se houver alterações na versão em inglês.

Para inicializar o Arch Linux, um carregador gerenciador de boot compatível com Linux deve ser configurado. O gerenciador de boot é responsável por carregar o kernel e o ramdisk inicial antes de iniciar o processo de inicialização. O procedimento é bastante diferente para sistemas BIOS e UEFI. A descrição detalhada é fornecida nesta página ou em páginas vinculadas.

Tipos de firmware

O firmware é o primeiro programa a ser executado a partir do momento que o sistema é ligado.

Dica: As palavras BIOS e UEFI são frequentemente usadas no lugar da palavra firmware.

UEFI

A Unified Extensible Firmware Interface tem suporte para ler a tabela de partições e os sistemas de arquivos. UEFI não inicia qualquer código de inicialização do Master Boot Record (MBR) independentemente de existir ou não - em vez disso, a inicialização depende de entradas de inicialização na NVRAM.

A especificação UEFI determina o suporte para os sistemas de arquivos FAT12, FAT16 e FAT32 (veja Especificação UEFI versão 2.10, seção 13.3.1.1), mas qualquer fornecedor em conformidade pode, opcionalmente, adicionar suporte para sistemas de arquivos adicionais; por exemplo, o suporte ao HFS+ ou APFS em alguns firmwares da Apple. As implementações da UEFI também suportam ISO-9660 para discos ópticos.

O UEFI inicia aplicativos EFI, por exemplo gerenciadores de boot, Shell UEFI, etc. Esses aplicativos geralmente são armazenados como arquivos na partição de sistema EFI. Cada fornecedor pode armazenar seus arquivos na partição do sistema EFI dentro do diretório /EFI/nome_fornecedor. Os aplicativos podem ser iniciados adicionando uma entrada de inicialização à NVRAM ou a partir do shell UEFI.

A especificação UEFI tem suporte para inicializar o legacy, no caso o legado da BIOS, e inicializar com seu Compatibility Support Module (CSM). Se o CSM estiver ativado no UEFI, o UEFI gerará entradas de inicialização do CSM para todas as unidades. Se uma entrada de inicialização do CSM for escolhida para ser inicializada, o CSM do UEFI tentará instanciar a partir do código de inicialização da unidade MBR.

Nota: A Intel está aos poucos deixando de dar suporte ao CSM, e depender do recurso pode não ser mais possível em um futuro próximo. [1]

BIOS

Uma BIOS (acrônimo para Basic Input-Output System) é na maioria dos casos armazenado em uma memória flash na própria placa-mãe e é independente do armazenamento do sistema. Originalmente ela servia para o IBM PC e cuidava do processo de inicialização do sistema e do hardware. Agora ela tem sido gradualmente substituída desde 2010 pela UEFI, da qual não sofre das mesmas limitações técnicas.

Inicialização do sistema

Ao ligar o sistema, o autoteste de inicialização, denominado no inglês como power-on self-test, é executado.

Veja também o texto, por Hugo Landau, em inglês, sobre as CPUs modernas possuírem um elenco nos bastidores se quiser saber um pouco mais sobre o papel das CPUs no processo de inicialização de um sistema.

UEFI

Após o POST, o UEFI inicializa o hardware necessário para carregar o sistema (disco, controladores de teclado etc.);
O firmware lê as entradas de inicialização na NVRAM para determinar qual aplicativo EFI deve ser iniciado e de onde (por exemplo, de qual disco e partição);
- Uma entrada de inicialização pode ser simplesmente um disco. Nesse caso, o firmware procura uma partição de sistema EFI nesse disco e tenta localizar o aplicativo EFI no caminho reserva de inicialização \EFI\BOOT\BOOTx64.EFI (BOOTIA32.EFI em sistemas com um IA32 (32 bits)). É assim que as mídias removíveis inicializáveis UEFI funcionam;
O firmware inicia o aplicativo EFI;
- Isso poderia ser um gerenciador de boot ou o kernel do Arch usando um stub de inicialização EFI;
- Ele poderia ser algum aplicativo EFI como um shell UEFI ou um gerenciador de boot, como systemd-boot ou rEFInd;

Se Secure Boot estiver habilitado, o processo de inicialização vai verificar a autenticidade do binário EFI pela assinatura.

Nota: Alguns sistemas UEFI só podem inicializar a partir do caminho reserva de inicialização.

Inicialização múltipla

Como cada sistema operacional ou fornecedor pode manter seus próprios arquivos dentro da partição de sistema EFI sem afetar um outro sistema, a inicialização múltipla, do inglês multibooting, usando UEFI é apenas uma questão de iniciar um aplicativo EFI diferente, que é correspondente ao gerenciador de boot do sistema operacional específico. Isso elimina a necessidade de contar com os mecanismos de carregamento em cadeia de um gerenciador de boot para carregar outro sistema operacional.

Veja também Dual boot com Windows.

BIOS

Após o POST, a BIOS inicializa o hardware necessário para inicializar (disco, controladores de teclado etc.).
A BIOS inicia os primeiros 440 bytes (a área de código de bootstrap do Master Boot Record) do primeiro disco na ordem de disco da BIOS.
O primeiro estágio do gerenciador de boot no código de inicialização da MBR, então, inicia o código de seu segundo estágio (se houver) de:
- próximos setores de disco após o MBR, ou seja, o chamado intervalo pós-MBR (somente em uma tabela de partição MBR).
- um registro de inicialização de volume (VBR) do disco com ou sem partição.
- para o GRUB em um disco particionado como GPT, usar uma partição de inicialização de BIOS específica para o GRUB (isto é usado no lugar do intervalo pós-MBR, do qual não existe em partições GPT).
O atual gerenciador de boot é iniciado.
O gerenciador de boot carrega um sistema operacional por encadeamento ou diretamente o kernel do sistema operacional.

Gerenciador de boot

Um gerenciador de boot é um peça de software iniciada pelo firmware (BIOS ou UEFI). Ele é responsável por carregar o kernel com os parâmetros do kernel desejados e qualquer imagem initramfs externa escolhida. No caso do UEFI, o kernel em si pode ser lançado diretamente pelo UEFI usando o stub de inicialização EFI. Um gerenciador de boot separado ainda pode ser usado com o propósito de editar os parâmetros do kernel antes de inicializar. Sistemas com 32-bit IA32 UEFI requerem um gerenciador de boot que dê suporte ao modo misto de inicialização.

Atenção: Para carregar a inicialização do Arch com sucesso, o gerenciador de boot precisa acessar o kernel e as imagens do initramfs, dos quais tipicamente residem no diretório /boot. Isto significa que o gerenciador de boot deve possuir suporte para tudo, desde os dispositivos de bloco, dispositivos de bloco stacked (empilhados/em camadas, como LVM, RAID, dm-crypt, LUKS, etc.), até ao sistema de arquivos no qual residem o(s) kernel(s) e as imagens initramfs.

Como quase nenhum dos gerenciadores de boot possuem suporte para dispositivos de bloco empilhados, e já que os sistema de arquivos podem introduzir novos recursos e funcionalidades que podem não ser compatíveis com qualquer tipo de gerenciador de boot (por exemplo, archlinux/packaging/packages/grub#7, FS#79857, FS#59047, FS#58137, FS#51879, FS#46856, FS#38750, FS#21733 e diretórios criptografados com fscrypt), usar uma partição /boot separada com um sistema de arquivos universalmente suportado, como FAT32, em diversas ocasiões é a opção mais viável.

Comparação de recursos

Nota:

Como o GPT é parte da especificação UEFI, todos os gerenciadores de boot UEFI oferecem suporte a discos GPT. O GPT em sistemas BIOS é possível, usando hybrid booting com Hybrid MBR ("inicialização híbrida") ou o novo protocolo somente GPT. Porém, esse protocolo pode causar problemas com certas implementações de BIOS; veja rodsbooks para mais detalhes.
Como Secure Boot faz parte das especificações UEFI, todos os gerenciadores de boot UEFI possuem este suporte, apesar de alguns terem limitações.

Nome	Firmware		Tabela de partição		Inicialização múltipla	Sistema de arquivos	Notas
Nome	BIOS	UEFI	MBR	GPT	Inicialização múltipla	Sistema de arquivos	Notas
Clover	Sim	Sim	Não	Sim	Sim	Extensível^2,5	Consegue emular UEFI em sistemas com BIOS legado.
EFI boot stub	–	Sim¹	Sim	Sim	–	Herdado do firmware¹	O kernel é um executável EFI válido que pode ser carregado diretamente do firmware UEFI ou de outro gerenciador de boot.
GRUB	Sim	Sim³	Sim	Sim	Sim	Já incorporado (built-in)	Fornece suporte a RAID, LUKS (porém não ao Argon2 PBKDFs) e LVM (porém não em volumes de provisionamento fino). Verifique a página do GRUB para conhecer limitações de configurações específicas.
Limine	Sim	Sim	Sim	Sim	Sim	Limitado
rEFInd	Não	Sim	Sim	Sim	Sim⁴	Extensível^2,5	Possui suporte a auto detecção de kernels e parâmetros sem configuração explícita, e possui suporte a inicialização rápida (fastboot) [2].
Syslinux	Sim	Parcial¹	Sim	Sim	Parcial	Limitado	Sem suporte a certos recursos de sistema de arquivos. Pode apenas acessar o sistema de arquivos para o qual foi instalado.
systemd-boot	Não	Sim³	Manual	Sim	Sim⁴	Extensível^2,5	Só pode carregar binários que foram instalados para o ESP ou da Partição de Gerenciador de Boot Estendida (partição XBOOTLDR) de dentro do mesmo disco. Automaticamente detecta imagens de kernel unificadas colocadas em `esp/EFI/Linux/`.
Imagem de kernel unificada	–	Sim³	Sim	Sim	–	Herdado do firmware²	systemd-stub(7), um kernel, o initramfs e a linha de comando do kernel empacotados dentro de um executável EFI para serem carregados diretamente do firmware UEFI ou de outro gerenciador de boot.
GRUB Legacy	Sim	Não	Sim	Não	Sim	Limitado	Descontinuado em favor do GRUB.
LILO	Sim	Não	Sim	Parcial	Sim	Limitado	Descontinuado em razão de limitações (por exemplo, com Btrfs, GPT, RAID, criptografia).

Mesmo que o binário seja assinado para Secure Boot, o mesmo não passa por nenhuma verificação após a assinatura, portanto isto quebra a cadeia de confiança.
O suporte ao sistema de arquivos é herdado do firmware. A especificação UEFI exige suporte para os sistemas de arquivos FAT12, FAT16 e FAT32 [3], mas os fornecedores podem opcionalmente adicionar suporte para sistemas de arquivos adicionais; por exemplo, o firmware dos Macs da Apple têm suporte ao sistema de arquivos HFS+. Se o firmware fornecer uma interface para carregar UEFI drivers na inicialização, o suporte a sistemas de arquivos adicionais poderá ser adicionado carregando drivers de sistema de arquivos (adquiridos independentemente).
Oferece suporte a inicialização de modo misto, ou seja, pode iniciar um kernel Linux x86_64 64-bit em uma UEFI IA32 32-bit.
Um gerenciador de boot. Ele só pode iniciar outros aplicativos EFI, por exemplo, imagens de kernel do Linux criadas com CONFIG_EFI_STUB=y e o Gerenciador de Boot do Windows (bootmgfw.efi).
Oferece suporte ao carregamento de programas de sistema de arquivos UEFI.

Veja também Wikipedia:Comparison of boot loaders.

Kernel

O gerenciador de boot inicializa a imagem vmlinux contendo o kernel.

O kernel funciona em um baixo nível (kernelspace, ou no caso a nível de espaço de kernel) que interage entre o hardware da máquina e os programas. O kernel inicialmente desempenha a enumeração do hardware e a inicialização antes de prosseguir para o espaço de usuário. Veja Wikipedia:Núcleo (sistema operacional) e Wikipedia:Linux (núcleo) para uma explicação detalhada.

initramfs

A imagem initramfs é o início em RAM de um sistema de arquivos (inital RAM file system) por um conjunto de arquivos compactado em cpio. Imagens initramfs podem ser geradas pelo mkinitcpio, dracut ou booster, e o método preferido do Arch é configurar o início do espaço de usuário, ou do inglês, early userspace.

O sistema de arquivos raiz, ou root, em / começa como um rootfs vazio, em outras palavras, começa como uma raiz vazia de um sistema de arquivos, e é uma instância especial do tmpfs ou do ramfs. Estes são nomes para uma raiz de sistema de arquivos temporária e é o local cuja a imagem initramfs será desempacotada.

O principal objetivo do initramfs é de fornecer os arquivos necessários para o início do espaço de usuário inicializar de forma bem sucedida os processos posteriores do espaço de usuário. Não é obrigatório que a imagem contenha todos os módulos de kernel que alguém almeje usar; a imagem deve possuir apenas os módulos requeridos para o dispositivo root como NVMe, SATA, SAS, eMMC ou USB (se inicializado por uma unidade externa) e de criptografia. A maioria dos módulos serão carregados mais tarde pelo udev, após a troca de root para dentro do sistema de arquivos raiz durante o processo de inicialização.

Primeiro, o kernel desempacota a integração do initramfs para dentro do root temporário. Os kernels oficialmente suportados por Arch Linux usam um arquivo compactado vazio da integração do initramfs, tal qual é o padrão ao montar o Linux.
E então, o kernel desempacota imagens initramfs externas na ordem que elas foram especificadas pela linha de comando, passadas pelo gerenciador de boot, e o mesmo sobrescreve qualquer arquivo que veio da integração do initramfs ou do desempacotamento dos arquivos prévio. Note que múltiplas imagens initramfs podem ser unidas em um único arquivo e o kernel irá processá-las na mesma ordem contida neste arquivo.
1. Se a primeira imagem initramfs é descomprimida, após ser desempacotada, o kernel irá procurar por atualizações do microcode da CPU e atualizações da tabela ACPI respectivamente em /kernel/x86/microcode/ e /kernel/firmware/acpi.
2. Depois de processar as atualizações do microcode da CPU e da tabela ACPI, o kernel continuará a desempacotar o resto das imagens initramfs, se caso houver.

Além disso, o kernel Linux fixa o root original de inicialização. Se um initramfs não é usado, o real sistema de arquivos root pode acabar falhando ao desmontar de forma limpa o sistema durante o desligamento.

Início do espaço de usuário

O estágio de início do espaço de usuário, ou early userspace, também conhecido por estágio do initramfs, começa dentro do sistema de arquivos root, do qual consiste de arquivos provenientes de #initramfs. O início do espaço de usuário inicia quando o kernel executa o binário /init como PID 1.

A função de início de espaço de usuário é configurável, mas o principal propósito é que o sistema inicialize por conta própria ao ponto que o mesmo possa acessar a raiz do sistema de arquivos. Isto inclui:

Configurar e preparar o armazenamento empilhado cujo o sistema de arquivos root está, por exemplo, por meio de dm-crypt, LVM, systemd-repart, etc.

Determinar os nomes persistentes de dispositivos de bloco aos dispositivos reais por meio do udev.

systemd-modules-load(8) carrega os módulos de kernel, assim como qualquer módulo de dispositivo de bloco necessário para montar o real sistema de arquivos root.

Lida com a desencriptação do real sistema de arquivos root, quando aplicável.

Carrega o módulo DRM, assim como o início do KMS já é habilitado por padrão para módulos em árvore (in-tree modules).

Note que o início do espaço de usuário serve mais do que apenas configurar o sistema de arquivos root. Há tarefas que só podem ser performadas antes que a raiz do sistema de arquivos seja montada, como no caso em fsck e ao retornar o sistema depois da hibernação.

No estágio final do início do espaço de usuário, o root real é montado em /sysroot/ (no caso de um initramfs baseado em systemd) ou em /new_root/ (no caso de um baseado em busybox), e com isso a troca é realizada ao ser usado systemctl switch-root, quando usando um initramfs baseado em systemd, ou switch_root(8), quando usado um initramfs baseado em busybox. Os processos posteriores do espaço de usuário começam quando executado o programa init a partir do real sistema de arquivos root.

Subsequência do espaço de usuário

A subsequência do espaço de usuário é executado pelo processo do init. Oficialmente o Arch usa systemd, e o processo é embasado no conceito de units e serviços, mas a funcionalidade descrita aqui é em grande parte sobreposta com a explicação de outros sistemas de inicialização.

getty

O processo do init chama getty uma vez para cada terminal virtual (geralmente seis deles), que inicializa cada terminal e protege o usuário de acesso não autorizado. Uma vez que o nome de usuário e a senha são fornecidos, o getty verifica-os em /etc/passwd e em /etc/shadow, e então chama o login(1).

Login

O programa login começa a sessão para o usuário ao configurar as variáveis de ambiente e ao iniciar o shell de usuário, baseado no que foi descrito em /etc/passwd. O programa login exibe os conteúdo da mensagem do dia /etc/motd (message of the day) após um login bem sucedido, pouco antes disto é executado o shell de login (login shell). Este é um bom lugar para exibir os termos de serviço e relembrar o usuário de suas diretivas locais, ou dizer qualquer outra coisa que você queira.

Shell

Uma vez que o shell do usuário é iniciado, tipicamente será executado um arquivo de configuração de tempo de execução (runtime) antes de apresentar o prompt ao usuário, no caso pode ser um arquivo como o bashrc. Se a conta é configurada para iniciar o X no login, o arquivo de configuração de tempo de execução irá chamar startx ou xinit. Para chegar ao fim desta explicação, pule para a seção de #Sessão gráfica (Xorg).

Gerenciador de exibição

Adicionalmente, o init pode ser configurado para iniciar um gerenciador de exibição ao invés de iniciar com getty em um terminal virtual específico. Isto requer manualmente habilitar o seu respectivo arquivo de serviço do systemd. O gerenciador de exibição pode então iniciar a sessão gráfica.

Sessão gráfica (Xorg)

xinit executa o arquivo de configuração de tempo de execução xinitrc do usuário, que normalmente inicia um gerenciador de janelas ou um ambiente desktop. Quando o usuário é encerrado e sai, xinit, startx, o shell e o login serão encerrados respectivamente, retornando ao getty ou ao gerenciador de exibição.