Pesquisar conteúdos

Encontre uma trilha ou aula pelo assunto.

Experimente pesquisar por “governança”, “ITIL” ou “planejamento”.

Como o computador inicia: firmware, bootloader, kernel e serviços

Acompanhe a inicialização desde o firmware e o carregador de boot até o kernel disponibilizar serviços e o ambiente de usuário.
Estações conectadas representam energia, firmware, escolha da imagem, carregamento do kernel, ativação de recursos e início dos serviços

O computador inicia por uma cadeia de entregas

Ao receber energia ou ser reiniciado, o computador ainda não possui navegador, terminal ou sistema de arquivos disponíveis para uso normal. Ele precisa executar uma sequência na qual cada componente prepara condições e transfere o controle ao próximo. Em um fluxo comum, firmware, gerenciador de boot, carregador, kernel, ambiente inicial e gerenciador de serviços participam dessa cadeia.

Chamamos esse processo de inicialização ou boot. Ele não é realizado por um único programa e não segue exatamente as mesmas etapas em todo equipamento. Um computador pessoal com UEFI, um servidor, um celular e um dispositivo embarcado podem armazenar imagens, verificar confiança e construir o espaço de usuário de maneiras diferentes.

Um modelo útil é preparar, escolher, carregar, assumir e disponibilizar. O firmware prepara a plataforma; uma política escolhe o que iniciar; um carregador posiciona o kernel e os dados necessários; o kernel assume os recursos; e processos de usuário disponibilizam serviços e acesso.

Cada etapa recebe e produz um contexto

Uma etapa não apenas “abre” a seguinte. Ela entrega informações: mapa de memória, descrição de hardware, opção selecionada, parâmetros, localização de uma imagem inicial ou estado de verificação. O próximo componente depende de um contrato para interpretar esses dados.

Sete etapas conectam reset e energia, firmware, opção de boot, carregador, kernel, primeiro processo de usuário e serviços disponíveis
A inicialização é uma cadeia de transferências. Uma etapa concluída prova apenas que o controle avançou até ali; ainda pode haver falhas posteriores.

As fronteiras também ajudam no diagnóstico. Se o menu do firmware aparece, parte da preparação da plataforma funcionou. Se surgem mensagens do kernel, o carregador conseguiu encontrá-lo e transferir o controle. Se o kernel monta a raiz, mas o serviço da plataforma não responde, procurar apenas no firmware desperdiça evidências.

Reset e firmware preparam a plataforma

No reset, o processador começa a executar a partir de um estado e de um ponto definidos por sua arquitetura. Esse primeiro código faz parte do firmware da plataforma: software persistente associado ao equipamento e disponível antes do sistema operacional instalado.

O firmware inicializa o suficiente do hardware para continuar. Isso pode envolver memória, temporizadores, controladores, console e descoberta de dispositivos. Testes de início, frequentemente agrupados sob o nome POST em computadores, podem identificar algumas falhas, mas não representam uma auditoria completa de cada componente.

Depois da preparação, o firmware precisa encontrar uma opção inicializável. Em computadores modernos, UEFI define interfaces e um gerenciador de boot no próprio firmware. A especificação descreve opções Boot#### e uma ordem BootOrder armazenadas em variáveis não voláteis. Cada opção pode apontar para um dispositivo e para uma aplicação UEFI, incluindo um carregador de sistema operacional.

Esse gerenciador de boot do firmware não deve ser confundido automaticamente com o carregador do sistema. O primeiro aplica a política da plataforma e inicia uma imagem escolhida. A imagem pode ser um bootloader que seleciona e prepara o kernel, uma ferramenta de recuperação ou, em alguns arranjos, uma imagem capaz de iniciar o kernel de forma mais direta.

UEFI e BIOS legado não são sinônimos

BIOS é usado informalmente para a tela de configuração de muitos computadores, mas BIOS legado e UEFI possuem modelos diferentes. Em um fluxo legado típico de PC, o firmware lia código inicial de um setor do dispositivo e o executava; etapas adicionais precisavam localizar estruturas e carregar componentes maiores.

Em UEFI, o firmware possui serviços, entende formatos definidos e pode carregar aplicações a partir de um sistema de arquivos acessível por seus protocolos. As opções de boot ficam associadas a caminhos de dispositivo e arquivos. Isso não elimina bootloaders: muda o ambiente e o contrato pelos quais eles são encontrados e iniciados.

Não existe regra de que todo computador use UEFI. Plataformas embarcadas podem adotar firmware, carregadores e descrições de hardware próprios. O fluxo universal é a transferência gradual de controle; BootOrder, partição de sistema EFI e aplicações .efi são elementos do exemplo UEFI.

O bootloader prepara a entrada do kernel

O bootloader ou carregador de inicialização recebe controle em um ambiente ainda limitado e prepara o software seguinte. Dependendo do projeto, ele pode:

  • localizar opções ou imagens disponíveis;
  • apresentar uma seleção ou aplicar uma escolha automática;
  • carregar a imagem do kernel em regiões adequadas da memória;
  • carregar uma imagem inicial de arquivos;
  • montar uma descrição do hardware ou parâmetros de boot;
  • verificar integridade e autorização;
  • transferir a execução para o ponto de entrada definido pelo kernel.

O contrato é específico da plataforma. O protocolo de boot Linux em x86, por exemplo, define campos que o carregador lê ou preenche, além da posição dos parâmetros e do ponto de entrada. Em sistemas UEFI, o EFI boot stub do Linux permite que certas imagens do kernel sejam tratadas como executáveis EFI. Assim, algumas configurações aparentam ter menos etapas visíveis, embora as responsabilidades de selecionar, carregar e entregar contexto continuem existindo.

O bootloader não permanece necessariamente administrando o computador depois da transferência. Quando o kernel assume, ele estabelece seus próprios mecanismos para memória, processadores, interrupções e dispositivos. O carregador cumpriu sua função ao criar condições válidas para essa entrada.

Secure Boot verifica uma cadeia autorizada

Durante a inicialização, código executa antes dos controles normais do sistema operacional. Se um invasor substituir o carregador, poderá tentar assumir o ambiente antes do kernel legítimo. Secure Boot reduz esse risco ao exigir, conforme a política e as bases de confiança configuradas, que imagens participantes sejam autenticadas antes da execução.

Em UEFI, o firmware mantém bases de assinaturas e revogações e decide se uma aplicação de boot pode executar. Um componente aceito pode verificar o próximo, formando uma cadeia. No fluxo do Windows, a Microsoft descreve a continuidade dessa verificação pelo carregador e por componentes críticos do sistema.

Secure Boot não significa que todo software carregado seja perfeito, que os dados do usuário estejam criptografados ou que nenhuma vulnerabilidade exista. Ele responde a uma pergunta mais restrita: a imagem está autorizada pela política de confiança aplicada nesta etapa? Configuração de chaves, atualização, revogação e proteção do firmware continuam relevantes.

Também não se deve concluir que desativar a verificação é a correção normal para qualquer falha de boot. Isso altera uma barreira de segurança e pode esconder o problema real: imagem não assinada, chave ausente, carregador modificado ou configuração incompatível. A abordagem combina-se ao princípio de selecionar controles segundo objetivo e risco, discutido em controles de segurança e defesa em profundidade.

O kernel assume o controle dos recursos

Ao receber a execução, o kernel ainda não encontra o ambiente completo que uma aplicação comum espera. Ele precisa preparar estruturas internas, gerenciamento de memória, processadores adicionais quando existentes, temporização, interrupções e drivers fundamentais. A ordem concreta varia com a arquitetura e com o núcleo estudado.

Esse é o mesmo componente cuja organização foi comparada na aula sobre kernel monolítico, microkernel, híbrido e modular. A arquitetura influencia onde alguns serviços aparecerão depois, mas todo fluxo precisa estabelecer mecanismos suficientes para sair do contexto inicial e construir o ambiente operacional.

O kernel interpreta informações recebidas do carregador, como parâmetros e descrições da plataforma. Também identifica ou inicializa dispositivos necessários para alcançar dados persistentes. Um desafio aparece: se o driver ou a ferramenta necessária para acessar o sistema instalado está justamente dentro desse sistema ainda inacessível, como começar?

Initramfs cria uma ponte temporária no Linux

Em muitos sistemas Linux, o carregador coloca na memória a imagem do kernel e um initramfs, além de parâmetros. O initramfs é um conjunto inicial de arquivos disponibilizado em memória. Ele contém as ferramentas e os módulos necessários para preparar o caminho até o sistema de arquivos raiz definitivo.

Esse ambiente pode carregar um driver de armazenamento, montar uma composição de volumes, desbloquear uma unidade protegida ou localizar uma raiz pela rede. Quando a raiz real está acessível, a inicialização transfere o ambiente para ela e executa o programa responsável por construir o espaço de usuário definitivo.

Bootloader entrega imagem do kernel, initramfs e parâmetros; o ambiente inicial prepara dispositivos, encontra a raiz real e inicia o gerenciador do sistema
O initramfs é uma ponte em memória. Seu conteúdo varia entre distribuições e configurações, e ele não deve ser confundido com o sistema de arquivos raiz definitivo.

Os termos initrd e initramfs aparecem juntos em explicações, mas não são rigorosamente idênticos. A documentação do Linux distingue o antigo disco RAM inicial, representado como imagem de sistema de arquivos em bloco, do initramfs baseado em um arquivo cpio extraído para o rootfs. Ferramentas e bootloaders podem conservar nomes históricos, por isso é importante verificar o formato e a implementação em uso.

O ambiente inicial também não é obrigatório em qualquer configuração. Um kernel com os drivers necessários integrados pode montar diretamente uma raiz simples. Em máquinas com armazenamento criptografado, volumes compostos ou drivers opcionais, a ponte inicial torna o processo mais flexível.

O primeiro processo constrói o espaço de usuário

Depois que a raiz adequada está disponível, o kernel executa um primeiro programa no espaço de usuário. Em sistemas Unix-like, ele ocupa tradicionalmente o identificador de processo 1 e assume responsabilidades especiais. O programa específico não precisa ser o mesmo em todas as instalações.

Em muitas distribuições Linux atuais, systemd funciona como gerenciador do sistema e de serviços em PID 1. Ele lê unidades e dependências e constrói uma transação para alcançar um objetivo configurado. Serviços, montagens, sockets e outros recursos podem ser iniciados em paralelo quando as relações permitem.

Isso corrige a imagem simplificada de uma lista sempre linear. Uma unidade de rede pode depender de dispositivos e configuração; a aplicação da plataforma pode depender do banco de dados; o login gráfico depende de um conjunto diferente daquele necessário para um servidor sem interface visual. O gerenciador organiza requisitos e ordem, mas “iniciado” também pode ter significados específicos para cada serviço.

No cenário do Guia Estudos, o sistema só está operacional para o leitor quando armazenamento, rede e processo da aplicação alcançam o estado esperado. O kernel pode estar executando corretamente enquanto um serviço aguarda credenciais ou falha ao abrir uma porta. A aula futura sobre serviços, daemons, systemd e registros aprofundará essas relações; aqui basta localizar essa responsabilidade depois da entrada no espaço de usuário.

Linux e Windows usam nomes diferentes

O fluxo geral pode ser aplicado a plataformas diferentes sem fingir que seus componentes são iguais.

ResponsabilidadeExemplo Linux em PC com UEFIExemplo Windows em PC com UEFI
preparar e escolherfirmware UEFI e sua política de bootfirmware UEFI e sua política de boot
selecionar/carregar o sistemabootloader, EFI stub ou arranjo equivalenteWindows Boot Manager e Windows OS Loader
iniciar o núcleoimagem do kernel Linux e parâmetroskernel do Windows e drivers necessários ao boot
preparar ambiente inicialinitramfs quando usadocomponentes e fases próprias do carregamento Windows
construir espaço de usuárioprograma init, frequentemente systemdprocessos de sistema iniciados segundo a arquitetura Windows

A tabela relaciona funções, não estabelece equivalência individual entre arquivos. A documentação de suporte da Microsoft divide a inicialização em PreBoot, Boot Manager, OS Loader e Kernel para localizar problemas. No Linux, distribuições podem combinar bootloader, imagem unificada, initramfs e gerenciador de sistema de maneiras diferentes.

Boot frio, reinício e retomada não são iguais

No boot frio, a plataforma parte de uma condição sem a execução normal anterior preservada. Em um reinício, alguns dispositivos ou estados da plataforma podem seguir caminhos diferentes de uma energização completa, embora o firmware e o sistema voltem a participar da inicialização.

Retomar de suspensão ou hibernação possui outra intenção: restaurar um estado previamente preservado. Na hibernação, o carregamento inicial precisa localizar e validar a imagem de retomada, e o kernel pode restaurar memória e dispositivos em vez de construir tudo como em um boot comum. Se a restauração não for possível, a política pode seguir uma inicialização normal.

Essas diferenças explicam por que “reiniciar resolveu” não identifica uma causa. O procedimento alterou estados e refez etapas, mas ainda é necessário examinar evidências para saber se havia configuração transitória, recurso preso, atualização pendente ou outro problema.

Diagnostique pela última entrega confirmada

Antes de mudar configurações, registre o que foi observado. Tela, códigos do equipamento, menu de boot, mensagens do carregador, console do kernel e registros do gerenciador pertencem a etapas diferentes.

Quatro colunas ligam firmware, bootloader, kernel e espaço de usuário aos sinais observáveis e à próxima evidência que deve ser procurada
A última entrega confirmada reduz o espaço de busca. Preserve mensagens e estado antes de alterar firmware, opções, parâmetros, discos ou serviços.

Use esta sequência segura:

  1. delimite a etapa: houve energia, firmware, seleção, entrada no kernel, raiz ou espaço de usuário?
  2. registre a evidência: copie a mensagem exata, horário, alteração recente e opção escolhida;
  3. compare o esperado: qual artefato ou dependência deveria ter sido entregue em seguida?
  4. teste a menor hipótese: prefira opção alternativa conhecida, modo de recuperação ou ambiente controlado;
  5. preserve reversibilidade: não apague entradas, formate volumes nem desative controles sem backup e plano de retorno.

Uma mensagem sobre ausência de opção de boot pertence a um momento diferente de uma falha ao montar a raiz. Um kernel panic ocorre depois de o núcleo receber controle. Uma tela de login sem conectividade indica que várias etapas anteriores funcionaram. A localização correta não fornece a correção automaticamente, mas impede misturar causas incompatíveis.

Erros comuns

  • “Firmware e bootloader são a mesma coisa.” Podem estar próximos ou combinados, porém cumprem responsabilidades distinguíveis de preparação, política e carregamento.
  • “UEFI é apenas uma tela nova para BIOS.” UEFI define serviços, formatos, variáveis e um modelo de carregamento diferente do BIOS legado.
  • “O bootloader é o kernel.” O carregador posiciona e inicia o núcleo; o kernel assume a administração dos recursos.
  • “Initramfs é a partição raiz.” Ele é um ambiente inicial em memória usado para alcançar ou preparar a raiz definitiva.
  • “PID 1 inicializa o hardware do zero.” Quando o primeiro processo executa, firmware e kernel já realizaram etapas fundamentais.
  • “Serviços sempre iniciam um após o outro.” Gerenciadores baseados em dependências podem executar trabalhos em paralelo.
  • “Secure Boot impede qualquer ataque.” Ele verifica autorização de imagens na cadeia prevista; não substitui atualização, configuração e demais controles.
  • “Se apareceu o login, todo serviço está saudável.” O marco comprova parte do ambiente, não cada aplicação esperada.

O que você deve guardar

A inicialização transforma um estado mínimo em um ambiente utilizável por transferências de controle. O firmware prepara a plataforma e escolhe uma opção; o bootloader carrega kernel e contexto; o kernel assume memória, processadores e dispositivos; um ambiente inicial pode tornar a raiz acessível; e o primeiro processo de usuário coordena serviços e pontos de acesso.

UEFI, initramfs, systemd e os componentes do Windows são implementações concretas dentro desse modelo. Use os nomes quando a plataforma estiver identificada, mas preserve as cinco perguntas: quem prepara, quem escolhe, quem carrega, quem assume e quem disponibiliza?

Para diagnosticar, encontre a última entrega comprovada antes de alterar o sistema. Na próxima aula, o ambiente já estará ativo para você diferenciar terminal, shell, comandos, fluxos e variáveis de ambiente.

Referências