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.
Artigos relacionados
Master Boot Record
Tabela de Partição GUID
Unified Extensible Firmware Interface
mkinitcpio
init
systemd
fstab
Inicialização automática
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
BIOS
UEFI
MBR
GPT
Clover
Sim
Sim
Não
Sim
Sim
Extensível
2,5
Consegue emular UEFI em sistemas com BIOS legado.
EFI boot stub
–
Sim
1
Sim
Sim
–
Herdado do firmware
1
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
3
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
4
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
1
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
3
Manual
Sim
Sim
4
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
3
Sim
Sim
–
Herdado do firmware
2
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 (
init
al
RAM
f
ile
s
ystem) 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.
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
.
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
(
m
essage
o
f
t
he
d
ay) 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.
Veja também
Wikipedia:Booting process of Linux
Inside the Linux boot process
Rod Smith - Managing EFI Boot Loaders for Linux
NeoSmart: The BIOS/MBR Boot Process
Lennart Poettering - Linux Boot Partitions and How to Set Them Up
Wikipedia:initrd
Early Userspace in Arch Linux
Kernel Newbie Corner: initrd and initramfs
bootup(7)
(aborda mais sobre o initrd do systemd + a porção do espaço de usuário)