Arch boot process (Portuguê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.

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

Tipos de firmware

BIOS

Uma BIOS (acrônimo para Basic Input-Output System) é o primeiro programa (firmware) que é executado assim que o sistema é ligado. Na maioria dos casos, é armazenado em uma memória flash na própria placa-mãe e é independente do armazenamento do sistema.

UEFI

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.8, seção 13.3.1.1), mas qualquer fornecedor em conformidade pode, opcionalmente, adicionar suporte para sistemas de arquivos adicionais; por exemplo, o Mac da Apple (e por padrão) oferece suporte a seus próprios drivers de sistema de arquivos HFS+. 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 sob a pasta . 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 BIOS legado com sua 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á inicializar a partir do MBR da unidade.

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 partição ou sem partição.
- a partição de inicialização de BIOS (GRUB em BIOS/GPT somente).
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 ( 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 EFISTUB
- 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.

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 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 o disco de RAM inicial com base nos arquivos de configuração. 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 para editar os parâmetros do kernel antes de inicializar.

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.
A criptografia mencionada no suporte a sistema de arquivos é uma criptografia a nível de sistema de arquivos, não influenciando criptografia a nível de bloco.

Nome	Firmware		Tabela de partição		Multiboot	Sistema de arquivos					Notas
Nome	BIOS	UEFI	MBR	GPT	Multiboot	Btrfs	ext4	ReiserFS	VFAT	XFS	Notas
EFISTUB											O kernel se tornou em um executável EFI para ser carregado diretamente do firmware UEFI ou de outro gerenciado de boot.
Clover					²		Sem criptografia				Fork do rEFIt modificado para funcionar em macOS em hardware que não seja da Apple.
GRUB											No BIOS/GPT, configuração requer uma partição de inicialização de BIOS. Possui suporte a RAID, LUKS1 e LVM (mas não volumes de provisionamento fino).
rEFInd					²		Sem criptografia				Possui suporte a autodetecção de kernels e parâmetros sem configuração explícita.
Syslinux						Sem: volumes de vários dispositivos, compressão, criptografia	Sem criptografia				Sem suporte a certos recursos de sistema de arquivos Não tem drivers de sistema de arquivos, podendo acessar apenas o sistema de arquivos para o qual foi instalado.
systemd-boot					¹						Não é possível iniciar binários de outras partições além da ESP ou da Extended Boot Loader Partition (partição XBOOTLDR).
											Descontinuado em favor do GRUB.
LILO							Sem criptografia				Descontinuado em razão de limitações (p.ex., com Btrfs, GPT, RAID).

O suporte ao sistema de arquivos é herdado do firmware. A especificação UEFI exige suporte para os sistemas de arquivos FAT12, FAT16 e FAT32, 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 drivers UEFI na inicialização, o suporte a sistemas de arquivos adicionais poderá ser adicionado carregando drivers de sistema de arquivos (adquiridos independentemente).
Um gerenciador de boot. Ele só pode iniciar outros aplicativos EFI, por exemplo, imagens de kernel do Linux criadas com e Windows .

Veja também Wikipedia:Comparison of boot loaders.

Kernel

O kernel é o núcleo de um sistema operacional. Ele funciona em um baixo nível (kernelspace ou espaço de kernel) interagindo entre o hardware da máquina e os programas que usam o hardware para funcionar. O kernel interrompe temporariamente os programas para executar outros programas, entretanto, conhecido como preemptividade ou preempção. Isso cria a ilusão de muitas tarefas sendo executadas simultaneamente, mesmo em CPUs de núcleo único. O kernel usa o agendador da CPU para decidir qual programa tem prioridade a qualquer momento.

Para fazer uso eficiente da CPU, o kernel usa um agendador para arbitrar quais tarefas têm prioridade em qualquer momento, criando a ilusão de que muitas tarefas são executadas simultaneamente.

initramfs

Depois que o gerenciador de boot carrega o kernel e os possíveis arquivos initramfs e executa o kernel, o kernel extrai os arquivos initramfs (sistema de arquivos RAM inicial) no (então vazio) rootfs (sistema de arquivos raiz inicial, especificamente um ramfs ou tmpfs). O primeiro initramfs extraído é aquele embutido no binário do kernel durante a construção do kernel, então os possíveis arquivos initramfs externos são extraídos. Assim, os arquivos no initramfs externo sobrescrevem arquivos com o mesmo nome no initramfs incorporado. O kernel então executa (no rootfs) como o primeiro processo. O early userspace é iniciado.

O Arch Linux usa um arquivo vazio para o initramfs incorporado (que é o padrão ao construir o Linux). Veja mkinitcpio para mais informações específicas do Arch sobre o initramfs externo.

Depois que o kernel é carregado, ele descompacta o initramfs (sistema de arquivos RAM inicial ou initial RAM filesystem), que se torna o sistema de arquivos raiz inicial. O kernel então executa como o primeiro processo. O early userspace é iniciado.

O objetivo do initramfs é inicializar o sistema até o ponto em que ele pode acessar o sistema de arquivos raiz (consulte FHS para obter detalhes). Isso significa que quaisquer módulos necessários para dispositivos como IDE, SCSI, SATA, USB/FW (se inicializando de uma unidade externa) devem poder ser carregados a partir do initramfs, se não estiverem embutidos no kernel; uma vez que os módulos apropriados são carregados (seja explicitamente através de um programa ou script, ou implicitamente via udev), o processo de inicialização continua. Por esse motivo, o initramfs precisa apenas conter os módulos necessários para acessar o sistema de arquivos raiz; não precisa conter todos os módulos que alguém desejaria usar. A maioria dos módulos será carregada mais tarde pelo udev, durante o processo de inicialização.

Processo init

No estágio final do início do espaço de usuário, a raiz real é montada e, em seguida, substitui o sistema de arquivos raiz inicial. /sbin/init é executado, substituindo o processo . Arch usa systemd como o init padrão.

getty

init chama getty uma vez para cada terminal virtual (geralmente seis deles), que inicializa cada tty e solicita um nome de usuário e senha. Uma vez que o nome de usuário e a senha são fornecidos, o getty os verifica em e , depois chama login. Alternativamente, o getty pode iniciar um gerenciador de exibição se houver um presente no sistema.

Gerenciador de exibição

Um gerenciador de exibição pode ser configurado para substituir o prompt de login do getty em um tty.

Para inicializar automaticamente um gerenciador de exibição após a inicialização, é necessário ativar manualmente a unidade de serviço através de systemd. Para obter mais informações sobre como ativar e iniciar unidades de serviço, consulte Systemd#Usando units.

O programa login começa uma sessão para o usuário definindo as variáveis de ambiente e iniciando o shell do usuário, com base no .

O programa login exibe o conteúdo de /etc/motd (message of the day ou, em português, mensagem do dia) após um login bem sucedido, logo antes dele executar o shell de login. É um bom lugar para exibir seus Terms of Service (Termos de Serviços) para lembrar seus usuários de suas políticas locais ou qualquer outra coisa que você deseje falar para eles.

Shell

Uma vez iniciado o shell do usuário, ele normalmente executará um arquivo de configuração de tempo de execução, como o bashrc, antes de apresentar um prompt ao usuário. Se a conta estiver configurada para iniciar X no login, o arquivo de configuração de tempo de execução chamará startx ou xinit.

GUI, xinit ou wayland

xinit executa o arquivo de configuração de tempo de execução xinitrc do usuário, que normalmente inicia um gerenciador de janelas. Quando o usuário terminar e sair do gerenciador de janelas, xinit, startx, o shell e o login serão encerrados nessa ordem, retornando ao getty.

Veja também

gollark: Why the 😆? I'm serious. PotatOS uses a few CC:T features, probably optionallyish.

gollark: It should *work*, but you'll lose SPUDNET and skynet connectivity, among other things. Also it's slower as it has to fall back to emergency backup very uncool reading mode.

gollark: After all, without CC:T you can't run potatOS properly.

gollark: > U r all making the server owner seem like a dumb person when he’s notHe is, however, dumb.

gollark: It uses the `load` function internally to dynamically load code.

This article is issued from Archlinux. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.