Arch boot process (Português)

From ArchWiki
Jump to: navigation, search
Status de tradução: Esse artigo é uma tradução de Arch boot process. Data da última tradução: 2018-10-24. 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

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 na 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.7, 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 /EFI/nome_fornecedor. Os aplicativos podem ser iniciados adicionando uma entrada de inicialização à NVRAM ou a partir do shell UEFI.

Inicialização do sistema

Na BIOS

  1. Sistema ligado, o power-on self-test (POST) (autoteste de inicialização) é executado.
  2. Após o POST, a BIOS inicializa o hardware de sistema necessário para inicializar (disco, controladores de teclado etc.).
  3. 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.
  4. 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:
  5. O atual gerenciador de boot é iniciado.
  6. O gerenciador de boot carrega um sistema operacional por encadeamento ou diretamente o kernel do sistema operacional.

No UEFI

  1. Sistema ligado, o power-on self-test (POST) (autoteste de inicialização) é executado.
  2. O UEFI inicializa o hardware necessário para carregar o sistema.
  3. 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 EFI IA32 (32 bits)). É assim que as mídias removíveis inicializáveis UEFI funcionam.
  4. O firmware inicia o aplicativo EFI.

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 de caminho de inicialização reserva.

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

O gerenciador de boot é o primeiro software iniciado pela BIOS ou pelo UEFI. Ele é responsável por carregar o kernel com os parâmetros de kernel desejados e o disco de RAM inicial com base nos arquivos de configuração.

Note: Carregar atualizações de microcódigo exige ajustes na configuração de gerenciador de boot. [1]

Comparação de recursos

Nota:
  • Gerenciadores de boot só precisam oferecer suporte ao sistema de arquivos no qual o kernel e o initramfs residem (o sistema de arquivos no qual /boot está localizado).
  • 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 Multiboot Sistema de arquivos Notas
BIOS UEFI Btrfs ext4 ReiserFS v3 VFAT XFS
EFISTUB Sim somente ESP O kernel se tornou em um executável EFI para ser carregado diretamente do firmware UEFI ou de outro gerenciado de boot.
Clover emula UEFI Sim Sim Não sem criptografia Não Sim Não Fork do rEFIt modificado para funcionar em macOS em hardware que não seja da Apple.
GRUB Sim Sim Sim Sem compressão zstd Sim Sim Sim Sim No BIOS/GPT, configuração requer uma partição de inicialização BIOS.
Possui suporte a RAID, LUKS1 e LVM (mas não volumes de provisionamento fino).
rEFInd Não Sim Sim sem: criptografia, compressão zstd sem criptografia sem recurso de tail-packing Sim Não Possui suporte a autodetecção de kernels e parâmetros sem configuração explícita.
Syslinux Sim Parcial Parcial sem: volumes de vários dispositivos, compressão, criptografia sem criptografia Não Sim v4 somente na MBR Sem suporte a certos recursos de sistema de arquivos [2]
systemd-boot Não Sim Sim Não Não Não somente ESP Não Não é possível iniciar binários de outras partições além de ESP.
GRUB Legacy sem GPT Não Sim Não Não Sim Sim somente v4 Descontinuado em favor do GRUB.
LILO sem GPT Não Sim Não sem criptografia Sim Sim Somente MBR [3] Descontinuado em razão de limitações (p.ex., com Btrfs, GPT, RAID).

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. 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 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 /init 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 /init. 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 /etc/passwd e /etc/shadow, 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.

Login

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 /etc/passwd.

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 sehll 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