16 Introdução ao processo de boot #
A inicialização de um sistema Linux envolve componentes e tarefas diferentes. Após um processo de inicialização de firmware e de hardware, que depende da arquitetura da máquina, o kernel será iniciado pelo carregador de boot GRUB 2. A partir deste ponto, o processo de boot é completamente controlado pelo sistema operacional e administrado pelo systemd. O systemd oferece um conjunto de “destinos” que inicializam configurações para uso diário, manutenção ou emergências.
16.1 Terminologia #
Este capítulo usa termos que podem ter interpretação ambígua. Para entender como eles são usados neste documento, leia as definições a seguir:
initDois processos diferentes são normalmente chamados “init”:
O processo
initramfs, que monta o sistema de arquivos raizO processo do sistema operacional, que inicia todos os outros processos executados do sistema de arquivos raiz real
Nos dois casos, o programa
systemdé responsável por essa tarefa. Ele é executado doinitramfspara montar o sistema de arquivos raiz. Depois de bem-sucedido, ele será executado novamente no sistema de arquivos raiz como o processo inicial. Para evitar confusão entre esses dois processos dosystemd, chamamos o primeiro processo de init no initramfs e o segundo de systemd.-
initrd/initramfs Um
initrd(disco RAM inicial) é um arquivo de imagem que inclui a imagem do sistema de arquivos raiz, que é carregada pelo kernel e montada do/dev/ramcomo o sistema de arquivos raiz temporário. A montagem desse sistema de arquivos exige um driver.A partir do kernel 2.6.13, o initrd foi substituído pelo
initramfs(sistema de arquivos RAM inicial), que não exige a montagem de um driver do sistema de arquivos. O SUSE Linux Enterprise Desktop usa exclusivamente uminitramfs. No entanto, como oinitramfsé armazenado como/boot/initrd, ele costuma ser chamado de “initrd”. Neste capítulo, usamos exclusivamente o nomeinitramfs.
16.2 Processo de boot do Linux #
O processo de boot do Linux consiste em vários estágios, cada um deles representado por um componente diferente:
16.2.1 Fase de inicialização e do carregador de boot #
Durante a fase de inicialização, o hardware da máquina é configurado e os dispositivos são preparados. Esse processo varia bastante entre as arquiteturas de hardware.
O SUSE Linux Enterprise Desktop usa o carregador de boot GRUB 2 em todas as arquiteturas. Dependendo da arquitetura e do firmware, o processo para iniciar o carregador de boot GRUB 2 pode ter várias etapas. A finalidade do carregador de boot é carregar o kernel e o sistema de arquivos inicial baseado em RAM (initramfs). Para obter mais informações sobre o GRUB 2, consulte o Capítulo 18, Carregador de boot GRUB 2.
16.2.1.1 Fase de inicialização e do carregador de boot no AArch64 e no AMD64/Intel 64 #
Após ligar o computador, o BIOS ou a UEFI inicializa a tela e o teclado e testa a memória principal. Até esse estágio, a máquina não acessa nenhuma mídia de armazenamento em massa. Em seguida, as informações sobre a data e o horário atuais e sobre os periféricos mais importantes são carregadas dos valores do CMOS. Quando a mídia de boot e sua geometria são reconhecidas, o controle do sistema passa do BIOS/UEFI para o carregador de boot.
Em uma máquina equipada com BIOS tradicional, apenas o código do primeiro setor de dados físico de 512 bytes, MBR (Master Boot Record), do disco de boot pode ser carregado. Apenas o GRUB 2 mínimo é adequado ao MBR. Sua única finalidade é carregar uma imagem do núcleo do GRUB 2 com os drivers do sistema de arquivos do espaço entre o MBR e a primeira partição (tabela de partição MBR) ou da partição de boot BIOS (tabela de partição GPT). Essa imagem inclui os drivers do sistema de arquivos, portanto, ela pode acessar o /boot localizado no sistema de arquivos raiz. O /boot contém módulos adicionais para o núcleo do GRUB 2, além do kernel e da imagem initramfs. Quando ele tem acesso a essa partição, o GRUB 2 carrega o kernel e a imagem initramfs na memória e transfere o controle ao kernel.
Ao inicializar um sistema BIOS de um sistema de arquivos criptografado que inclui uma partição /boot criptografada, você precisa inserir a senha de decodificação duas vezes. O GRUB 2 precisa dela primeiro para decodificar o /boot e depois o systemd para montar os volumes criptografados.
Nas máquinas com UEFI, o processo de boot é muito mais simples do que nas máquinas com BIOS tradicional. O firmware pode ler a partição de discos do sistema formatado em FAT com uma tabela de partição GPT. Esta partição de sistema EFI (no sistema em execução montado como /boot/efi) contém espaço suficiente para hospedar um GRUB 2 de pleno direito, que é carregado diretamente e executado pelo firmware.
Se o BIOS/UEFI suportar inicialização por rede, também será possível configurar um servidor de boot que ofereça o carregador de boot. Em seguida, o sistema será inicializado por PXE. O BIOS/UEFI funciona como o carregador de boot. Ele obtém a imagem do servidor de boot e inicia o sistema. Isso é totalmente independente dos discos rígidos locais.
16.2.1.2 Fase de inicialização e do carregador de boot no IBM Z #
No IBM z , o processo de boot deve ser inicializado por um carregador de boot denominado zipl (carga inicial de programa z). Embora o zipl suporte a leitura de vários sistemas de arquivos, ele não suporta o sistema de arquivos padrão SLE (Btrfs) ou a inicialização de instantâneos. Portanto, o SUSE Linux Enterprise Desktop usa um processo de boot de duas fases que garante suporte total ao Btrfs no momento da inicialização:
O
ziplé inicializado da partição/boot/zipl, que pode ser formatada com o sistema de arquivos Ext2, Ext3, Ext4 ou XFS. Essa partição inclui um kernel mínimo e um initramfs, que são carregados na memória. O initramfs contém um driver Btrfs (entre outros) e o carregador de boot GRUB 2. O kernel é iniciado com um parâmetroinitgrub, que o instrui a iniciar o GRUB 2.O kernel monta o sistema de arquivos raiz para que
/bootse torne acessível. Agora, o GRUB 2 é iniciado do initramfs. Ele lê a configuração em/boot/grub2/grub.cfge carrega o kernel final e o initramfs do/boot. Agora, o novo kernel é carregado pelo Kexec.
16.2.2 Fase do kernel #
Depois que o carregador de boot passar no controle do sistema, o processo de boot será o mesmo em todas as arquiteturas. O carregador de boot carrega tanto o kernel quanto um sistema de arquivos inicial baseado em RAM (initramfs) na memória, e o kernel assume o controle.
Depois que o kernel configurar o gerenciamento de memória e detectar o tipo de CPU e seus recursos, ele inicializará o hardware e montará o sistema de arquivos raiz temporário que foi carregado com o initramfs da memória.
16.2.2.1 O arquivo initramfs #
O initramfs (sistema de arquivos RAM inicial) é um pequeno arquivo cpio que pode ser carregado pelo kernel em um disco RAM. Ele está localizado em /boot/initrd. É possível criá-lo com uma ferramenta chamada dracut. Consulte man 8 dracut para obter detalhes.
O initramfs fornece um ambiente Linux mínimo que permite a execução de programas antes da montagem do sistema de arquivos raiz real. Este ambiente mínimo do Linux é carregado na memória pelas rotinas do BIOS ou da UEFI e não tem outros requisitos de hardware específicos além de memória suficiente. O arquivo initramfs sempre deve incluir um executável denominado init, que executa o daemon systemd no sistema de arquivos raiz para realização do processo de boot.
Antes da montagem do sistema de arquivos raiz e da inicialização do sistema operacional, o kernel precisa dos drivers correspondentes para acessar o dispositivo em que o sistema de arquivos raiz está localizado. Esses drivers podem incluir drivers especiais para determinados tipos de unidades de discos rígidos ou até drivers de rede para acesso a um sistema de arquivos de rede. Os módulos necessários ao sistema de arquivos raiz são carregados pelo init no initramfs. Depois de carregados os módulos, o udev fornecerá os dispositivos necessários ao initramfs. Posteriormente no processo de inicialização, depois de mudar o sistema de arquivos raiz, será necessário gerar novamente os dispositivos. Esse procedimento é feito pela unidade systemd-udev-trigger.service do systemd.
16.2.2.1.1 Gerando o initramfs novamente #
Como o initramfs contém drivers, é necessário atualizá-lo sempre que uma nova versão de um dos drivers é disponibilizada. Isso é feito automaticamente ao instalar o pacote que contém a atualização de driver. O YaST ou o zypper informará você sobre isso mostrando a saída do comando que gera o initramfs. Em algumas ocasiões, entretanto, você precisa gerar um initramfs outra vez, manualmente:
- Adicionando drivers por causa de mudanças no hardware
Se você precisar mudar o hardware (por exemplo, discos rígidos), e esse hardware exigir drivers diferentes no kernel durante a inicialização, será necessário atualizar o arquivo
initramfsAbra ou crie o arquivo
/etc/dracut.conf.d/10-DRIVER.confe adicione a seguinte linha (observe o espaço em branco à esquerda):force_drivers+=" DRIVER1 "
Substitua DRIVER1 pelo nome do driver do módulo. Se for necessário adicionar mais do que um driver, liste-os separados com espaço:
force_drivers+=" DRIVER1 DRIVER2 "
Avance para o Procedimento 16.1, “Gerar um initramfs”.
- Movendo diretórios de sistema para um RAID ou LVM
Sempre que você mover arquivos de troca (swap) ou diretórios de sistema, como
/usr, em um sistema em execução para um RAID ou volume lógico, será necessário criar uminitramfsque ofereça suporte a drivers RAID ou LVM de software.Para isso, crie as respectivas entradas em
/etc/fstabe monte as novas entradas (por exemplo, commount -ae/ouswapon -a).Avance para o Procedimento 16.1, “Gerar um initramfs”.
- Adicionando discos a um grupo de LVM ou RAID Btrfs com o sistema de arquivos raiz
Sempre que você adicionar (ou remover) um disco de um grupo de volumes lógicos ou de um RAID Btrfs com o sistema de arquivos raiz, será necessário criar um
initramfsque ofereça suporte ao volume ampliado. Siga as instruções no Procedimento 16.1, “Gerar um initramfs”.Avance para o Procedimento 16.1, “Gerar um initramfs”.
- Mudando as variáveis do kernel
Se você mudar os valores das variáveis do kernel pela interface do
sysctl, editando os arquivos relacionados (/etc/sysctl.confou/etc/sysctl.d/*.conf), a mudança será perdida na próxima reinicialização do sistema. Mesmo que você carregue os valores comsysctl --systemem tempo de execução, as mudanças não são gravadas no arquivoinitramfs. Você precisa atualizá-lo de acordo com a instrução no Procedimento 16.1, “Gerar um initramfs”.
Veja que todos os comandos no procedimento a seguir precisam ser executados como usuário root.
Insira o diretório
/boot:#cd /bootGere um novo arquivo
initramfscomdracutsubstituindo MY_INITRAMFS pelo nome do arquivo de sua escolha:#dracut MY_INITRAMFSSe preferir, execute
dracut -fFILENAME para substituir um arquivo init existente.(Ignore esta etapa se você executou
dracut -fna etapa anterior.) Crie um link simbólico do arquivoinitramfscriado na etapa anterior para oinitrd:#ln -sf MY_INITRAMFSinitrdNa arquitetura do IBM Z, execute também o
grub2-install.
16.2.3 Fase do init no initramfs #
O sistema de arquivos raiz temporário montado pelo kernel do initramfs contém o executável systemd (que é denominado init no initramfs). Consulte também a Seção 16.1, “Terminologia”. Este programa executa todas as ações necessárias para montar o sistema de arquivos raiz apropriado. Ele oferece a funcionalidade do kernel para os drivers necessários de sistema de arquivos e de dispositivo para controladoras de armazenamento em massa com o udev.
O principal objetivo do init no initramfs é preparar a montagem e o acesso ao sistema de arquivos raiz real. Dependendo da configuração do sistema, o init no initramfs será responsável pelas tarefas a seguir.
- Carregando módulos do kernel
Dependendo da configuração do hardware, drivers especiais poderão ser necessários para acessar os componentes de hardware do computador (sendo que o componente mais importante é o disco rígido). Para acessar o sistema de arquivos raiz final, o kernel precisa carregar os drivers adequados do sistema de arquivos.
- Fornecendo arquivos especiais de bloco
O kernel gera eventos de dispositivo de acordo com os módulos carregados. O
udevprocessa esses eventos e gera os arquivos de blocos especiais necessários em um sistema de arquivos RAM em/dev. Sem esses arquivos especiais, o sistema de arquivos e outros dispositivos não estariam acessíveis.- Gerenciando configurações RAID e LVM
Se você configurar o sistema para armazenar o sistema de arquivos raiz no RAID ou no LVM, o
initnoinitramfsconfigurará o LVM ou o RAID para permitir acesso ao sistema de arquivos raiz posteriormente.- Gerenciando a configuração de rede
Se você tiver configurado o sistema para usar um sistema de arquivos raiz montado em rede (via NFS), o
initdeverá verificar se os drivers de rede corretos foram carregados e estão configurados para permitir acesso ao sistema de arquivos raiz.Se o sistema de arquivos residir em um dispositivo de blocos de rede, como iSCSI ou SAN, a conexão com o servidor de armazenamento também será configurada pelo
initnoinitramfs. O SUSE Linux Enterprise Desktop permitirá a inicialização de um destino iSCSI secundário se o destino primário não estiver disponível.
Se o sistema de arquivos raiz não puder ser montado no ambiente de boot, ele deverá ser verificado e consertado antes de prosseguir com a inicialização. O verificador de sistema de arquivos será iniciado automaticamente nos sistemas de arquivos Ext3 e Ext4. O processo de conserto não é automatizado nos sistemas de arquivos XFS e Btrfs, e o usuário vê as informações que descrevem as opções disponíveis para consertar o sistema de arquivos. Quando o sistema de arquivos é consertado com êxito, sair do ambiente de boot faz com que o sistema repita a montagem do sistema de arquivos raiz. Em caso de êxito, o boot continuará normalmente.
16.2.3.1 Fase do init no initramfs no processo de instalação #
Quando o init no initramfs é chamado durante o boot inicial como parte do processo de instalação, suas tarefas são diferentes das que foram mencionadas acima. Observe que o sistema de instalação não inicia também o systemd do initramfs. Esse tipo de tarefa é executado pelo linuxrc.
- Localizando o meio de instalação
Ao iniciar o processo de instalação, a máquina carrega um kernel de instalação e um
initespecial que inclui o instalador do YaST. O instalador do YaST é executado em um sistema de arquivos RAM e precisa ter informações sobre a localização do meio de instalação para acessá-lo e instalar o sistema operacional.- Iniciando o reconhecimento de hardware e carregando os módulos do kernel apropriados
Conforme mencionado na Seção 16.2.2.1, “O arquivo
initramfs”, o processo de boot começa com um conjunto mínimo de drivers que pode ser usado com a maioria das configurações de hardware. Em máquinas com AArch64, POWER e AMD64/Intel 64, olinuxrcinicializa um processo de varredura de hardware inicial que determina o conjunto de drivers adequado à sua configuração de hardware. No IBM Z, uma lista de drivers e seus parâmetros precisam ser fornecidos, por exemplo, por meio do linuxrc ou de um parmfile.Esses drivers são usados para gerar um
initramfspersonalizado necessário para inicializar o sistema. Se os módulos não forem necessários para inicialização, mas forem para coldplug, eles poderão ser carregados comsystemd. Para obter mais informações, consulte a Seção 19.6.4, “Carregando módulos do kernel”.- Carregando o sistema de instalação
Quando o hardware é adequadamente reconhecido, os drivers apropriados são carregados. O programa
udevcria os arquivos de dispositivo especiais, e olinuxrcinicia o sistema de instalação com o instalador do YaST.- Inicialização do YaST
Por fim, o
linuxrcinicia o YaST, que inicia a instalação do pacote e a configuração do sistema.
16.2.4 Fase do systemd #
Após encontrar o sistema de arquivos raiz “real”, será verificado se há erros nele e se ele foi montado. Se esse procedimento for bem-sucedido, o initramfs será limpo e o daemon systemd no sistema de arquivos raiz será executado. O systemd é um gerenciador de serviços e sistemas do Linux. Trata-se do processo pai que é iniciado como PID 1 e age como um sistema init que ativa e mantém os serviços no espaço do usuário. Consulte o Capítulo 19, Daemon systemd para obter os detalhes.