101.2 - Início (boot) do sistema

Peso: 3

Áreas chaves de conhecimento

Fornecer os comandos e opções mais comuns para o gerenciador de inicialização e para o kernel durante a inicialização.
Demonstrar conhecimento sobre a sequência de inicialização do BIOS/UEFI até sua conclusão.
Entendimento do SysVinit e do systemd.
Noções do Upstart.
Conferir os arquivos de log dos eventos de inicialização.

Lista parcial de arquivos, termos e utilitários utilizados

dmesg
journalctl
BIOS (Basic Input/Output System)
UEFI (Unified Extensible Firmware Interface)
MBR (Master Boot Record)
POST (Power-On Self-Test)
NVRAM (Non-Volatile Random-Access Memory)
ESP (EFI System Partition)
bootloader
GRUB (Grand Unified Bootloader)
kernel
initramfs (Initial RAM Filesystem)
init
SysVinit
systemd

BIOS

A BIOS é um programa armazenado em um chip de memória não volátil conectado à placa-mãe e que é executado sempre que o computador é ligado.

A BIOS pressupõe que os primeiros 440 bytes do primeiro dispositivo de armazenamento (chamado de MBR) contêm o primeiro estágio do bootloader. O processo é:

O POST verifica o hardware.
A BIOS ativa os componentes básicos (vídeo, teclado, armazenamento)
A BIOS carrega o primeiro estágio do bootloader a partir do MBR.
O primeiro estágio chama o segundo estágio, que exibe o menu e carrega o kernel.

UEFI

A UEFI assim como a BIOS também é um firmware, mas pode identificar partições e ler sistemas de arquivos nelas. A UEFI não depende do MBR, em vez disso, lê as configurações na NVRAM da placa-mãe para localizar aplicativos EFI armazenados na ESP.

Os aplicativos EFI podem ser carregadores de inicialização, seletores de sistema operacional, ferramentas para diagnóstico e reparo do sistema, etc.

A ESP é uma partição que contém os aplicativos EFI. Essa partição é compatível com FAT12, FAT16, FAT32 e ISO-9660 (mídia ótica) e não deve ser compartilhada com outros sistemas de arquivos. O diretório EFI na partição ESP contém os aplicativos apontados pelas entradas salvas na NVRAM.

POST verifica o hardware.
UEFI ativa componentes básicos.
UEFI lê a NVRAM e executa o aplicativo EFI pré-definido (geralmente o bootloader).
O bootloader carrega o kernel.

A UEFI também suporte o Secure Boot, que permite executar aplicativos EFI assinados pelo fabricante, aumentando a segurança contra hardware.

bootloader

O bootloader (carregador de inicialização) é o primeiro software que é executado quando o computador liga. Seu objetivo é carregar o kernel do sistema operacional e entregar o controle a ele. O kernel, por sua vez, carrega os drivers, inicializa o hardware e sobe o restante do sistema.

O bootloader mais usado no Linux é o GRUB. Ele exibe um menu com os sistema operacionais disponíveis e permite passar parâmetros para o kernel.

No menu do GRUB, é possível escolher qual dos kernels instalados no sistema deve ser carregado e passar novos parâmetros a ele. A maioria dos parâmetros segue o padrão opção=valor.

Aqui estão alguns dos parâmetros do kernel usados no GRUB:

Parâmetro	Descrição	Exemplo
`acpi`	Ativa ou desativa suporte a ACPI.	`acpi=off`
`init`	Define um inicializador de sistema alternativo.	`init=/bin/bash`
`systemd.unit`	Define o target do systemd a ser ativado.	`systemd.unit=graphical.target`
`mem`	Limita a quantidade de RAM disponível ao sistema.	`mem=512M`
`maxcpus`	Limita o número de processadores visíveis ao sistema.	`maxcpus=2`
`quiet`	Oculta a maioria das mensagens de boot.	`quiet`
`vga`	Seleciona um mode de vídeo.	`vga=ask`
`root`	Define a partição raiz do sistema.	`root=/dev/sda3`
`rootflags`	Opções de montagem para o sistema de arquivos raiz.	`rootflags=subvol=@`
`ro`	Monta o sistema de arquivos raiz como somente leitura na inicialização.	`ro`
`rw`:	Permite escrita no sistema de arquivos raiz montagem inicial.	`rw`

maxcpus=0: Desativa o suporte a multiprocessamento simétrico (SMP), equivalente ao parâmetro nosmp.

A alteração do kernel diretamente no GRUB não persistem na próxima inicialização. Para que persistam, os parâmetros do kernel devem ser adicionados ao arquivo /etc/default/grub na linha GRUB_CMDLINE_LINUX. Depois de alterado o arquivo, deve ser executado o comando update-grub ou grub-mkconfig -o /boot/grub/grub.cfg. Quando o sistema operacional estiver sendo executado, os parâmetros do kernel pode ser lidos no arquivo /proc/cmdline.

Nota: O GRUB2 é o padrão na maioria das distribuições Linux atuais. A configuração do GRUB será discutida em outra lição.

Inicialização do sistema

Após o GRUB carregar o kernel na RAM, o kernel assume o controle da CPU e começa a detectar e configurar o hardware. A partir desse ponto, o sistema passa por mais 3 etapas fundamentais antes de estar completamente disponível ao usuário: o initramfs, o init (SysVinit, systemd ou o Upstart) e a inicialização dos daemons.

Initramfs

O initramfs é um arquivo que contém um sistema de arquivo raiz temporário, carregado pelo kernel diretamente na memória RAM durante o boot.

Seu principal objetivo é fornecer os módulos de kernel necessários para que o sistema possa acessar o sistema de arquivos raiz real.

Assim que o sistema de arquivos real fica disponível, o kernel monta todos os sistema de arquivos configurados em /etc/fstab e executa o primeiro processo do sistema. Depois disso o initramfs é removido da memória RAM.

Daemons - Serviços do sistema

Além do kernel, o sistema operacional depende de programas chamados daemons (ou serviços) para funcionar completamente. Os daemons são processos que ficam ativos em segundo plano, sendo responsáveis por aspectos fundamentais do sistema.

Gerenciadores de serviços

Como o conjunto de daemons necessários varia conforme a finalidade do sistema e precisa ser ajustável em tempo de execução, todas as distribuições Linux oferecem um gerenciador de serviços para essa função. Historicamente, o SysVinit foi o gerenciador de serviços padrão, mas sua natureza sequencial e limitada cedeu espaço para soluções mais modernas. O Upstart surgiu como alternativa orientada a eventos para acelerar o boot via paralelização, sendo adotado pelo Ubuntu até 2025. Hoje, o systemd é o gerenciador de serviços padrão na grande maioria das distribuições Linux modernas.

SysVinit

O SysVinit (System V Init) é o gerenciador de serviços tradicional do Linux. Ele controla os daemons através de runlevels (níveis de execução), numerados de 0 a 6:

Nível	Finalidade
0	Encerramento do sistema
1/s/single	Modo single-user - manutenção, sem rede
2,3,4	Modo multiusuário (3 e 4 com rede; 2 raramente usado)
5	Modo multiusuário com interface gráfica
6	Reinicialização do sistema

O programa responsável é o /sbin/init, que lê o arquivo /etc/inittab para determinar o nível de execução padrão e quais scripts executar. Os scripts de serviço ficam em /etc/init.d/ e cada nível de execução possui um diretório /etc/rc<N>.d/ com links simbólicos para estes scripts, nomeados com:

S no início: serviço iniciado ao entrar no nível (Start).
K no início: serviço encerrado ao entrar no nível (Kill).

systemd

O systemd é o gerenciador de sistemas e serviços mais adotado atualmente pelas distribuições Linux. Ele substitui o SysVinit com uma abordagem mais moderna e eficiente, mantendo uma camada de compatibilidade com os comandos SysVinit.

Principais características:

Inicialização paralela de serviços.
Ativação de serviços via sockets e D-Bus.
Execução de daemons sob demanda.
Monitoramento de processos com cgroups.
Controle de serviços baseado em dependências.
Suporte a logs via journald.

O systemd organiza tudo em Units(unidades), com sete tipos principais:

Tipo	Descrição
`service`	Serviços que podem ser iniciados, parados e recarregados.
`socket`	Socket de sistemas de arquivos ou de rede.
`device`	Dispositivo de hardware reconhecido pelo kernel.
`mount`	Ponto de montagem no sistema de arquivos.
`automount`	Ponto de montagem automático.
`target`	Agrupamento de unidades (equivale aos runlevels do SysVinit).
`snapshot`	Estado salvo do systemd.

Em vez de runlevels o systemd usa targets. Os equivalentes são:

SysVinit Runlevel	systemd Target
0	`poweroff.target`
1	`rescue.target`
3	`multi-user.target`
5	`graphical.target`
6	`reboot.target`

Upstart

O Upstart é um substituto para o SysVinit. O foco do Upstart é acelerar o processo de inicialização, paralelizando o processo de carregamento dos serviços do sistema. O Upstart foi usado pelas distribuições baseadas no Ubuntu, mas hoje deu lugar ao systemd.

Inspeção de inicialização

Durante o processo de boot, erros nem sempre são críticos o suficiente para interromper o sistema, mas podem comprometer seu comportamento esperado. Por isso, o Linux oferece ferramentas para inspecionar o que aconteceu durante a inicialização, tanto em tempo real quanto após o fato.

Kernel ring buffer (Buffer de anel do kernel)

O kernel armazena suas mensagens de inicialização em uma área de memória chamada kernel ring buffer. Essas mensagens ficam disponíveis mesmo quando não são exibidas na tela durante o boot, por exemplo, quando uma animação substitui o log de texto. No entanto, o buffer é volátil: todas as mensagens são perdidas quando o sistema é desligado ou quando o comando dmesg --clear é executado.

Comando `dmesg`

O dmesg exibe as mensagens atuais do kernel ring buffer. Cada linha é precedida pelo tempo em segundos desde o início do carregamento do kernel.

[ 5.460286] systemd[1]: systemd 237 running in system mode.
[ 5.480138] systemd[1]: Detected architecture x86-64.
[ 5.481767] systemd[1]: Set hostname to <torre>.
[ 5.637085] systemd[1]: Listening on Journal Socket.
[ 5.641661] systemd[1]: Starting Load Kernel Modules...

Opções úteis do dmesg:

Opção	Descrição
`dmesg`	Exibe todas as mensagens do buffer.
`dmesg -H`	Habilita paginação automática.
`dmesg --clear`	Limpa o kernel ring buffer.
`dmesg --json`	Usa o formato de saída JSON.
`dmesg -T`	Mostra marca de tempo legível para humanos.

Comando `journalctl` (systemd)

Nos sistemas baseados em systemd, o journalctl é a ferramenta principal para inspecionar logs de inicialização. Ao contrário do dmesg, o journalctl persiste os logs entre inicializações, tornando possível inspecionar boots anteriores.

Listando inicializações disponíveis:

journalctl --list-boots

Exemplo de saída:

IDX BOOT ID   FIRST ENTRY                 LAST ENTRY
 -3 55b6ea... Wed 2026-06-03 19:10:48 -03 Wed 2026-06-03 21:33:55 -03
 -2 f074bf... Wed 2026-06-03 21:34:08 -03 Wed 2026-06-03 22:07:59 -03
 -1 4b92fb... Wed 2026-06-03 22:08:13 -03 Wed 2026-06-03 22:26:16 -03
  0 b77dca... Thu 2026-06-04 10:08:40 -03 Thu 2026-06-04 10:48:02 -03

IDX: Número relativo do kernel (0 = atual, -1 = anterior, -2 = antes do anterior, e assim por diante)

Consultando mensagens por boot:

journalctl -b 0        # inicialização atual
journalctl -b -1       # inicialização anterior
journalctl -b -2       # duas inicializações atrás

Outras opções essenciais do journalctl:

Opção	Descrição
`-k` ou `--dmesg`	Exibe apenas mensagens do kernel (equivalente ao `dmesg`).
`-p err`	Filtra por prioridade (emerg, alert, crit, err, warning, notice, info, debug).
`-n 20`	Exibe as 20 últimas linhas.
`--since "2026-01-01"`	Mensagens a partir de uma data.
`--until "19:07:00"`	Mensagens até um horário.
`_PID=1`	Mensagens de um processo específico.
`-D /mnt/hd/var/log/journal/`	Lê logs de um diretório alternativo.

Logs em `/var/log`

As mensagens de inicialização e do sistema operacional são armazenadas em arquivos dentro do diretório /var/log/. Isso é especialmente útil em situações de recuperação: se o sistema não conseguir completar o boot, uma mídia de inicialização alternativa pode ser usada para montar o sistema de arquivos e inspecionar os arquivos de log em busca da causa do problema.