Arch boot process (Português)

Status de tradução: Esse artigo é uma tradução de Arch boot process. Data da última tradução: 2024-10-20. 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 (U)EFI são frequentemente usadas no lugar da palavra firmware.

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.

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]

Inicialização do sistema

Na BIOS

Sistema ligado, o power-on self-test (POST) (autoteste de inicialização) é executado.
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.

No UEFI

Sistema ligado, o power-on self-test (POST) (autoteste de inicialização) é executado;
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.

Multiboot no UEFI

Como cada sistema operacional ou fornecedor pode manter seus próprios arquivos dentro da partição de sistema EFI sem afetar o outro, a inicialização múltipla (multi-booting) usando UEFI é apenas uma questão de iniciar um aplicativo EFI diferente 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.

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.

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		Multiboot	Sistema de arquivos	Notas
Nome	BIOS	UEFI	MBR	GPT	Multiboot	Sistema de arquivos	Notas
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.
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	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/`.
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 raiz, ou root, do sistema de arquivos em / começa como um rootfs vazio, em outras palavras, começa com uma raiz de sistema de arquivos vazia. Esta é uma instância especial do sistema de arquivos em RAM (ramfs) ou do sistema de arquivos temporário (tmpfs). Como os próprios nomes sugerem, este é o local temporário que o sistema de arquivos root desempacota a imagem de iniciação do sistema de arquivos em RAM (initramfs: inital RAM file system).

O principal objetivo do initramfs é de instanciar o início do sistema ao ponto de conseguir acessar o sistema de arquivos root (veja FHS para detalhes). Isto inclui a configuração para encontrar a raiz de um armazenamento empilhado, ou seja, com um sistema por dentro de camadas, local do qual a raiz do sistema de arquivos pode estar; por exemplo nos casos com mapeamento de dispositivos com dm-crypt, dm-verity, systemd-repart(8), etc. Isto também determina qual será a nomeação persistente de dispositivo de bloco para o dispositivo real, através do udev. Não é um requerimento conter todo o tipo de módulo almejado para o uso; o mesmo só precisa dos módulos requisitados para o dispositivo root, como NVMe, SATA, SAS, eMMC ou USB (se iniciado a partir de uma unidade externa) e para criptografia. A maioria dos módulos irá carregar mais tarde pelo udev, isso ocorre após a troca de root para dentro da raiz do sistema de arquivos durante o processo de inicialização.

Primeiro, o kernel desempacota toda a integração do initramfs para dentro do root temporário. Os kernels oficiais do Arch Linux extraem um conjunto de arquivos vazios da integração do initramfs, tal comportamento é o padrão enquanto é montado o Linux no sistema. E então, o kernel desempacota os arquivos initramfs externos, que foram especificados pela linha de comando passada pelo gerenciador de boot, e estes comandos sobrescrevem qualquer arquivo que veio da integração do initramfs. Estas imagens initramfs externas podem ser geradas com mkinitcpio, dracut ou pelo booster, e estes são os métodos preferidos do Arch de configuração para o início do espaço de usuário (early userspace).

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 (early userspace) toma forma enquanto o rootfs temporário é montado, que opera conforme os arquivos providenciados pelo #initramfs.

A função de ínicio de espaço de usuário é configurável, mas geralmente ela faz o seguinte:

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 descriptografia do real sistema de arquivos root, se o mesmo for 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).

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), após isso a troca de root é realizada. O término do espaço de usuário começa ao ser executado o programa init a partir do real sistema de arquivos root.

Término do espaço de usuário

O começo do término 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.

Gerenciador de exibição

This article or section needs expansion.

Reason: Esta seção apenas descreve o processo com Xorg e não explica o que acontece com Wayland. (Discuss in Talk: Arch boot process)

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

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.