Inicializacao do Sistema e systemd - GRUB, runlevels, systemctl

Inicializacao do Sistema e systemd - GRUB, runlevels, systemctl

O Que Voce Vai Alcancar

  • Explicar os quatro estagios de boot em ordem (BIOS/UEFI ate bootloader ate kernel ate init/systemd)
  • Alterar as configuracoes do GRUB2 com seguranca atraves de /etc/default/grub
  • Controlar inicio, parada e inicio automatico de servicos com systemctl
  • Responder o mapeamento entre boot targets e runlevels do SysVinit
  • Executar um reboot ou shutdown agendado com shutdown
  • Investigar logs de boot com dmesg / journalctl

Este e o nucleo dos objetivos 101.2 "Inicializar o sistema" e 101.3 "Alterar runlevels / boot targets e desligar ou reiniciar o sistema" do LPIC-1. E a base das operacoes de servidor.

Como o Processo de Boot Procede?

Desde o ligar ate um sistema utilizavel, o Linux passa por quatro estagios em ordem. Compreender essa estrutura de "revezamento de bastao", onde cada estagio carrega o proximo, permite isolar onde uma falha ocorreu.

Estagio Responsavel Funcao principal
1. Firmware BIOS / UEFI Inicializacao de hardware, selecao de disco
2. Bootloader GRUB2 Carregar kernel e initramfs na memoria
3. Kernel Linux kernel Detectar hardware, montar o sistema raiz
4. init systemd Iniciar servicos, alcancar um target

O BIOS carrega o bootloader a partir do MBR (os primeiros 512 bytes do disco), enquanto o UEFI carrega o bootloader (*.efi) a partir da EFI System Partition. Em ambos os ambientes, as principais distribuicoes modernas usam GRUB2 como bootloader e systemd como sistema init.

O initramfs (initial RAM filesystem) que o kernel carrega e um ambiente temporario contendo os drivers necessarios para montar o sistema de arquivos raiz. Isso permite montar mesmo quando o root esta em um volume criptografado, LVM ou armazenamento especial.

Onde Editar as Configuracoes do GRUB2?

O comportamento do GRUB2 deve ser alterado editando /etc/default/grub e /etc/grub.d/ e depois regenerando, nao editando o grub.cfg gerado. Nunca edite grub.cfg diretamente.

Os principais arquivos do GRUB2 sao os seguintes.

Arquivo Funcao
/boot/grub/grub.cfg (familia Debian) Configuracao final gerada. Nao editar diretamente
/boot/grub2/grub.cfg (familia RHEL) O mesmo. O caminho difere por distribuicao
/etc/default/grub Fonte de timeout, entrada padrao e parametros do kernel
/etc/grub.d/ Scripts que geram entradas de menu

Itens representativos em /etc/default/grub.

GRUB_TIMEOUT=5
GRUB_DEFAULT=0
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

GRUB_TIMEOUT e os segundos de exibicao do menu, GRUB_DEFAULT e a entrada selecionada por padrao, e GRUB_CMDLINE_LINUX_DEFAULT sao os parametros de boot passados ao kernel.

Regenerar grub.cfg

Apos editar, regenere grub.cfg para aplicar as alteracoes. O nome do comando difere por distribuicao.

sudo grub-mkconfig -o /boot/grub/grub.cfg
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.1.0-18-amd64
Found initrd image: /boot/initrd.img-6.1.0-18-amd64
done

A familia Debian / Ubuntu tem update-grub, que e um wrapper do comando acima. A familia RHEL / Fedora usa grub2-mkconfig -o /boot/grub2/grub.cfg.

Distribuicao Comando de regeneracao Saida
Debian / Ubuntu update-grub ou grub-mkconfig -o ... /boot/grub/grub.cfg
RHEL / Fedora / CentOS grub2-mkconfig -o ... /boot/grub2/grub.cfg

Mesmo que voce edite grub.cfg diretamente, ele sera sobrescrito e perdido na proxima vez que grub-mkconfig for executado. Para alteracoes permanentes, sempre edite /etc/default/grub ou /etc/grub.d/ e depois regenere.

Como Operar Servicos com systemctl?

No systemd, systemctl e o centro do controle de servicos. Inicio, parada, verificacao de status e configuracao de inicio automatico sao todos feitos com este comando.

O que o systemd gerencia e chamado de "unit", e a extensao difere por tipo.

Tipo de unit Extensao Conteudo
Service .service Daemon / processo
Target .target Um grupo de units (equivalente ao antigo runlevel)
Socket .socket Listener de ativacao por socket
Mount .mount Um ponto de montagem de sistema de arquivos

Principais subcomandos do systemctl

systemctl status sshd
systemctl start sshd
systemctl stop sshd
systemctl restart sshd
systemctl enable sshd
systemctl disable sshd
● sshd.service - OpenSSH server daemon
     Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; preset: enabled)
     Active: active (running) since Fri 2026-05-30 09:00:00 JST; 2h ago

A linha Active: do status e o estado de execucao atual, e enabled/disabled no final da linha Loaded: e a configuracao de inicio automatico. start inicia imediatamente, enquanto enable configura o inicio automatico a partir do proximo boot.

start e enable sao diferentes. start inicia imediatamente mas reverte apos reboot, enquanto enable configura o inicio automatico mas nao inicia agora. Para fazer ambos de uma vez, use systemctl enable --now sshd.

Como os Boot Targets se Mapeiam aos Runlevels?

Um boot target do systemd e o conceito que substituiu os runlevels do SysVinit (0 a 6). A tabela de mapeamento aparece frequentemente no exame.

Runlevel SysVinit Target do systemd Estado
0 poweroff.target Desligar (power off)
1 rescue.target Usuario unico (resgate)
2, 3, 4 multi-user.target Multiusuario (CLI)
5 graphical.target Multiusuario com GUI
6 reboot.target Reiniciar

Note que os runlevels 2, 3 e 4 todos mapeiam para multi-user.target. E mais facil lembrar que boot com GUI e graphical.target (antigo runlevel 5) e boot com CLI e multi-user.target (antigo runlevel 3).

Verificar e alterar o target padrao

systemctl get-default
sudo systemctl set-default multi-user.target
graphical.target
Removed "/etc/systemd/system/default.target".
Created symlink /etc/systemd/system/default.target → /usr/lib/systemd/system/multi-user.target.

get-default mostra o target no proximo boot, e set-default o altera. default.target e na verdade um link simbolico, e para onde ele aponta se torna o target padrao.

Alternar o target em execucao

sudo systemctl isolate multi-user.target
runlevel
N 5

isolate alterna o target atual sem reiniciar (units que nao pertencem ao target especificado sao paradas). O comando runlevel, compativel com SysVinit, mostra o "runlevel anterior" e o "runlevel atual" (acima, anterior N sem anterior, atual 5).

Como Desligar ou Reiniciar com Seguranca?

Desligamento e reinicializacao sao baseados no comando shutdown. Agendamento e mensagens de aviso mantem o impacto nos outros usuarios baixo.

Agendamento com shutdown

sudo shutdown -h now
sudo shutdown -r +10
sudo shutdown -h 23:30
sudo shutdown -c
Shutdown scheduled for Fri 2026-05-30 23:30:00 JST, use 'shutdown -c' to cancel.

-h desliga (halt/poweroff) e -r reinicia. O horario e dado como now (imediato), +m (m minutos a partir de agora), ou hh:mm (um horario). shutdown -c cancela um desligamento agendado.

Comandos relacionados

Comando Acao
shutdown -h +m Desligar em m minutos (recomendado; avisa todos os usuarios)
shutdown -r +m Reiniciar em m minutos
reboot Reiniciar imediatamente (equivalente a systemctl reboot)
poweroff Desligar imediatamente (equivalente a systemctl poweroff)
halt Parar o sistema (pode nao desligar a energia)
wall Enviar uma mensagem a todos os usuarios logados
echo "Maintenance reboot in 10 minutes" | wall

shutdown envia automaticamente um aviso estilo wall ao agendar. Para enviar um aviso arbitrario manualmente, use wall sozinho.

Onde Procurar Problemas de Boot?

Isole problemas relacionados ao boot a partir de mensagens do kernel e logs de boot. dmesg e journalctl sao os dois pilares.

dmesg | less
journalctl -k
journalctl -b
journalctl -b -1
[    0.000000] Linux version 6.1.0-18-amd64 ...
[    1.234567] EXT4-fs (sda1): mounted filesystem ...

dmesg mostra o ring buffer do kernel (deteccao de hardware e mensagens de drivers). journalctl -k mostra apenas mensagens do kernel, journalctl -b mostra o boot atual, e journalctl -b -1 mostra os logs do boot anterior. Poder rastrear a causa da falha do boot anterior com -b -1 e uma vantagem do systemd.

systemd-analyze permite analisar o tempo de boot. systemd-analyze blame lista quanto tempo cada servico levou para iniciar em ordem decrescente, ajudando a identificar causas de lentidao.

Erros Comuns e Correcoes

Aqui estao pontos que causam problemas tanto na pratica quanto no exame.

Erro 1: Inverter o mapeamento runlevel-target

Runlevel 5 e graphical.target (GUI) e runlevel 3 e multi-user.target (CLI). Lembre pela direcao: "o numero maior 5 e GUI". O ponto de que runlevels 2, 3 e 4 todos se consolidam em multi-user.target tambem e frequente.

Erro 2: Editar grub.cfg diretamente

Edicoes diretas em grub.cfg sao perdidas na regeneracao. O procedimento correto e editar /etc/default/grub e depois aplicar com grub-mkconfig (ou update-grub).

Erro 3: Confundir enable e start

enable configura o inicio automatico e nao inicia agora, enquanto start inicia imediatamente e reverte apos reboot. Para ambos, use enable --now.

Erro 4: Errar o agendamento do shutdown

shutdown -h +10 significa "em 10 minutos", nao "as 10 horas". Para especificar um horario, use a forma shutdown -h 22:00. shutdown sem horario depende do ambiente e pode se comportar como +1 em vez de desligamento imediato, entao adicione now explicitamente para imediato.

Erro 5: Confundir set-default e isolate

set-default altera o target padrao para o proximo boot (persistente). isolate alterna agora mas nao e persistente. Distinga alteracoes persistentes das temporarias.

Solucao de Problemas

Sintoma: enabled mas o servico nao esta rodando apos reboot

Causa: Somente enable foi executado e nao e wanted-by de um target dependente, ou a configuracao esta correta e voce simplesmente nao fez start

Verificacao:

systemctl is-enabled sshd
systemctl status sshd

Correcao: Se is-enabled mostra enabled, a configuracao esta correta. Se voce tambem precisa que ele inicie agora, use systemctl enable --now sshd. Se disabled, execute enable novamente.

Sintoma: Inicia na GUI (voce quer CLI)

Causa: O target padrao esta definido como graphical.target

Verificacao:

systemctl get-default

Correcao: Defina CLI como padrao com sudo systemctl set-default multi-user.target. Para alternar agora, use tambem sudo systemctl isolate multi-user.target.

Sintoma: Alteracoes de parametros do kernel nao sao aplicadas

Causa: Voce editou /etc/default/grub apenas e nao regenerou grub.cfg

Verificacao:

cat /proc/cmdline

Correcao: Execute sudo grub-mkconfig -o /boot/grub/grub.cfg (familia Debian: update-grub, familia RHEL: grub2-mkconfig) e reinicie. Voce pode verificar os parametros de boot atuais com /proc/cmdline.

Lista de Verificacao de Conclusao

  • [ ] Consegue explicar os quatro estagios de boot em ordem
  • [ ] Regenerou com grub-mkconfig apos editar /etc/default/grub
  • [ ] Distinguiu inicio automatico e inicio imediato com systemctl enable --now
  • [ ] Consegue responder a tabela de mapeamento runlevel-target
  • [ ] Executou um reboot agendado com shutdown -r +10
  • [ ] Verificou logs de boot com journalctl -b

Resumo

Cenario Comando Finalidade
Controle de servico systemctl start/enable --now Iniciar e inicio automatico
Verificacao de status systemctl status / is-enabled Verificar execucao e autostart
Target padrao systemctl get-default/set-default Estado no proximo boot
Alternancia temporaria systemctl isolate <target> Alternar sem reiniciar
Configuracao GRUB /etc/default/grub depois grub-mkconfig Alterar opcoes de boot
Desligar / reiniciar shutdown -h/-r Com seguranca e agendamento
Investigacao de log dmesg / journalctl -b Isolar problemas de boot

Inicializacao do sistema e systemd sao o ponto de partida de todas as operacoes de servidor. Combinados com gerenciamento de logs e controle de processos, elevam sua capacidade de isolamento de falhas a outro nivel.

Proximas Leituras

Continue Sua Jornada LPIC-1

Hub LPIC-1

  • Hub de Aprendizado LPIC-1 -- Mapa completo de artigos LPIC-1, acompanhamento de progresso e cobertura dos objetivos do exame

Artigos LPIC-1 Relacionados

Pratica