Solucionar Problemas no Processo de Inicialização do RHEL

Introdução

Neste laboratório, você aprenderá técnicas essenciais para solucionar problemas e reparar o processo de inicialização do Red Hat Enterprise Linux (RHEL). Você explorará como interagir com o sistema em diferentes estágios da sequência de inicialização para diagnosticar e resolver problemas comuns que podem impedir que um sistema inicie corretamente. Isso inclui trabalhar com alvos de inicialização do systemd e utilizar modos de inicialização especializados projetados para recuperação do sistema.

Ao longo dos exercícios, você obterá experiência prática gerenciando alvos systemd com systemctl, inicializando no modo de resgate a partir do menu GRUB para manutenção do sistema e redefinindo a senha root usando o parâmetro do kernel rd.break. Além disso, você aprenderá como usar o modo de emergência para reparar erros críticos em arquivos de configuração, como um /etc/fstab corrompido, garantindo que você possa restaurar um sistema não inicializável para um estado operacional.

Gerenciar Alvos de Inicialização do Systemd com systemctl

Nesta etapa, você aprenderá como gerenciar alvos de inicialização do systemd. No systemd, um "alvo" (target) é um ponto de sincronização que agrupa vários serviços e outras unidades necessárias para levar o sistema a um determinado estado. Este é o equivalente moderno dos "runlevels" em sistemas SysV init mais antigos. Exploraremos como visualizar o alvo padrão atual, alterar o alvo padrão para inicializações futuras e alternar temporariamente para um alvo diferente.

Primeiramente, vamos verificar em qual alvo seu sistema inicializa por padrão. O graphical.target é usado para sistemas com um ambiente de desktop, fornecendo uma interface gráfica do usuário (GUI). O multi-user.target é para uma interface somente de linha de comando.

Para ver o alvo padrão atual, execute o seguinte comando:

systemctl get-default

Você deve ver que o alvo padrão é o alvo gráfico.

graphical.target

Agora, vamos alterar o alvo de inicialização padrão para multi-user.target. Isso é útil para ambientes de servidor ou para solucionar problemas em situações em que a interface gráfica não é necessária ou está causando problemas. O comando systemctl set-default consegue isso alterando o link simbólico /etc/systemd/system/default.target.

Use sudo para executar este comando com privilégios administrativos.

sudo systemctl set-default multi-user.target

A saída confirma que o link simbólico foi atualizado.

Removed /etc/systemd/system/default.target.
Created symlink /etc/systemd/system/default.target -> /usr/lib/systemd/system/multi-user.target.

Você pode verificar se o padrão foi alterado executando o comando get-default novamente.

systemctl get-default

A saída agora mostra o novo alvo padrão.

multi-user.target

Com esta configuração, o sistema inicializaria em um console baseado em texto após uma reinicialização. Para este laboratório, queremos manter um ambiente gráfico consistente. Vamos definir o alvo padrão de volta para graphical.target.

sudo systemctl set-default graphical.target

Você verá uma saída semelhante à anterior, indicando que o link simbólico foi alterado novamente.

Removed /etc/systemd/system/default.target.
Created symlink /etc/systemd/system/default.target -> /usr/lib/systemd/system/graphical.target.

Execute uma verificação final para confirmar se o alvo padrão foi restaurado para graphical.target.

systemctl get-default

graphical.target

Além de alterar o alvo padrão para reinicializações, você também pode alternar alvos na sessão atual usando systemctl isolate. Este comando interrompe os serviços não associados ao novo alvo e inicia aqueles que estão. Por exemplo, executar sudo systemctl isolate multi-user.target terminaria sua sessão gráfica e mudaria para um console somente de texto. Este é um comando poderoso, mas potencialmente disruptivo, por isso não o executaremos aqui.

Você agora usou com sucesso systemctl para gerenciar alvos do systemd.

Inicializar no Modo de Resgate a partir do Menu GRUB

Nesta etapa, você aprenderá sobre rescue.target, um alvo systemd especial projetado para recuperação do sistema. Em um sistema RHEL padrão, você acessaria este modo reiniciando, interrompendo o carregador de inicialização (GRUB) e adicionando um parâmetro às opções de inicialização do kernel. Isso fornece um shell de usuário único com o sistema de arquivos root montado e a maioria dos serviços desativados, o que é ideal para solução de problemas.

Embora não possamos realizar uma reinicialização real ou acessar o menu GRUB neste ambiente de laboratório em contêineres, ainda podemos explorar a configuração do modo de resgate para entender como ele funciona.

Primeiro, vamos localizar o arquivo de unidade systemd para rescue.target. Esses arquivos são normalmente armazenados no diretório /usr/lib/systemd/system/.

ls -l /usr/lib/systemd/system/rescue.target

Você verá o arquivo listado com suas permissões e propriedade.

-rw-r--r--. 1 root root 500 Nov  1  2022 /usr/lib/systemd/system/rescue.target

Agora, vamos examinar o conteúdo deste arquivo para entender sua configuração. O comando cat exibirá o conteúdo do arquivo no terminal.

cat /usr/lib/systemd/system/rescue.target

A saída mostra a definição do alvo.

##  SPDX-License-Identifier: LGPL-2.1-or-later
#
##  This file is part of systemd.
#
##  systemd is free software; you can redistribute it and/or modify it
##  under the terms of the GNU Lesser General Public License as published by
##  the Free Software Foundation; either version 2.1 of the License, or
##  (at your option) any later version.

[Unit]
Description=Rescue Mode
Documentation=man:systemd.special(7)
Requires=sysinit.target rescue.service
After=sysinit.target rescue.service
AllowIsolate=yes

Diretivas-chave neste arquivo incluem:

• Description=Rescue Mode: Um nome legível por humanos para o alvo.
• Requires=sysinit.target rescue.service: Isso garante que tanto sysinit.target (inicialização básica do sistema) quanto rescue.service sejam iniciados quando este alvo é ativado. O serviço de resgate fornece o shell de manutenção root.
• After=sysinit.target rescue.service: Isso especifica a ordem de ativação, garantindo que o modo de resgate seja iniciado após a inicialização do sistema e o serviço de resgate.
• AllowIsolate=yes: Isso permite que você alterne para este alvo de outro alvo usando o comando systemctl isolate rescue.target em um sistema em execução.

Para ter uma ideia melhor do ambiente mínimo que o modo de resgate fornece, você pode visualizar suas dependências. O comando systemctl list-dependencies mostra todas as unidades que são iniciadas como parte de um alvo.

systemctl list-dependencies rescue.target

A saída lista as unidades necessárias para o modo de resgate. Você verá um conjunto mínimo de serviços, confirmando que é um ambiente simplificado projetado para tarefas de reparo.

rescue.target
○ ├─rescue.service
○ ├─systemd-update-utmp-runlevel.service
● └─sysinit.target
●   ├─dev-hugepages.mount
●   ├─dev-mqueue.mount
●   ├─dracut-shutdown.service
○   ├─iscsi-onboot.service
○   ├─iscsi-starter.service
●   ├─kmod-static-nodes.service
●   ├─ldconfig.service
●   ├─lvm2-lvmpolld.socket
... (output may vary) ...

A principal conclusão é que rescue.target fornece um shell root com o sistema de arquivos montado em modo leitura-gravação, permitindo que você corrija problemas do sistema. Nas etapas a seguir, simularemos cenários de recuperação que se baseiam em princípios semelhantes.

Redefinir a Senha Root usando rd.break e chroot

Nesta etapa, você aprenderá o procedimento para redefinir uma senha root perdida em um sistema RHEL. Esta é uma habilidade crítica de recuperação. O método padrão envolve interromper o processo de inicialização com o parâmetro do kernel rd.break, que lhe dá acesso a um shell antes que o sistema seja totalmente iniciado.

Em uma máquina física ou virtual, você reiniciaria, interromperia o carregador de inicialização GRUB e adicionaria rd.break ao final da linha do kernel linux. Essa ação interrompe o processo de inicialização logo antes de o systemd assumir o controle, colocando você em um shell initramfs. A partir daí, as etapas gerais são:

1. Remontar o sistema de arquivos root do sistema (que é montado em modo somente leitura em /sysroot) em modo leitura-gravação com o comando mount -o remount,rw /sysroot.
2. Entrar em uma "chroot jail" em /sysroot com chroot /sysroot. Isso torna o sistema de arquivos root real do sistema seu ambiente atual, permitindo que você execute comandos que afetam o sistema.
3. Alterar a senha usando o comando passwd.
4. Abordar possíveis problemas de contexto SELinux.
5. Sair do chroot e do shell initramfs para continuar a inicialização.

Embora não possamos realizar uma reinicialização real e usar rd.break neste ambiente de laboratório, simularemos os comandos mais importantes que você executaria após entrar no ambiente chroot.

Primeiro, vamos simular a alteração da senha root. Imagine que você entrou com sucesso na "chroot jail". Você agora teria acesso root para alterar a senha de qualquer usuário. Usaremos o comando sudo passwd root para alterar a senha do usuário root. Quando solicitado, defina a nova senha como redhat.

sudo passwd root

Você será solicitado a inserir e reinserir a nova senha (por exemplo, labex.io).

Changing password for user root.
New password:
Retype new password:
passwd: all authentication tokens updated successfully.

Após alterar a senha neste ambiente de recuperação, o contexto de segurança SELinux no arquivo de senha (/etc/shadow) pode se tornar incorreto. Para corrigir isso, você deve forçar uma reetiquetação SELinux completa do sistema na próxima inicialização. Isso é feito criando um arquivo vazio chamado .autorelabel no diretório root (/).

sudo touch /.autorelabel

Vamos verificar se o arquivo foi criado.

ls -l /.autorelabel

A saída deve mostrar o arquivo recém-criado.

-rw-r--r--. 1 root root 0 <date> <time> /.autorelabel

Em um sistema real, você agora digitaria exit duas vezes e deixaria o sistema reiniciar. Ele executaria o longo processo de reetiquetação e, em seguida, inicializaria normalmente com a nova senha. Como não queremos acionar isso em nosso laboratório, faremos a limpeza removendo o arquivo que acabamos de criar.

sudo rm /.autorelabel

Isso conclui a simulação da redefinição da senha root. Você praticou os comandos-chave (passwd e touch /.autorelabel) que são centrais para o processo de recuperação.

Reparar Erros em /etc/fstab usando o Modo de Emergência

Nesta etapa, você aprenderá como diagnosticar e reparar erros no arquivo /etc/fstab. Este arquivo é crítico para o processo de inicialização, pois informa ao sistema quais sistemas de arquivos montar e onde. Uma entrada incorreta em /etc/fstab pode impedir que o sistema inicialize, forçando-o a entrar no modo de emergência.

O modo de emergência fornece o ambiente mais mínimo possível para reparo do sistema. Ao contrário do modo de resgate, ele não tenta montar a maioria dos sistemas de arquivos ou iniciar muitos serviços. Crucialmente, o sistema de arquivos root (/) é montado em modo somente leitura (ro) para evitar mais danos.

Embora não possamos acionar uma falha real de inicialização neste laboratório, podemos simular o processo de encontrar e corrigir um erro em /etc/fstab.

Primeiro, vamos adicionar intencionalmente uma entrada defeituosa em /etc/fstab. Usaremos o comando echo com sudo para anexar uma linha que referencia um dispositivo inexistente.

echo '/dev/nonexistent /data xfs defaults 0 0' | sudo tee -a /etc/fstab

Agora, vamos visualizar o conteúdo de /etc/fstab para confirmar que nossa linha errada foi adicionada.

cat /etc/fstab

Você deve ver a linha incorreta no final do arquivo.

#
## /etc/fstab
## Created by anaconda on <date>
#
## Accessible filesystems, by reference, are maintained under '/dev/disk/'.
## See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info.
#
## After editing this file, run 'systemctl daemon-reload' to update systemd
## units generated from this file.
#
/dev/vda4 / xfs defaults 0 0
/dev/vda2 /boot xfs defaults 0 0
/dev/vda1 /boot/efi vfat umask=0077,shortname=winnt 0 0
/dev/vda3 swap swap defaults 0 0
/dev/nonexistent /data xfs defaults 0 0

Em seguida, simularemos a etapa de diagnóstico. O comando mount -a tenta montar todos os sistemas de arquivos listados em /etc/fstab que ainda não estão montados. Como nossa entrada é inválida, este comando falhará.

sudo mount -a

O comando produzirá um erro, indicando claramente que o ponto de montagem /data não existe. Isso é semelhante ao erro que você veria durante uma inicialização com falha.

mount: /data: mount point does not exist.

Agora, vamos simular o processo de reparo. Em um shell de emergência real, a primeira etapa é remontar o sistema de arquivos root em modo leitura-gravação para permitir alterações.

sudo mount -o remount,rw /

Com o sistema de arquivos agora gravável, você pode editar /etc/fstab para corrigir o erro. Use o editor nano para abrir o arquivo.

sudo nano /etc/fstab

Dentro do editor nano, use as setas para navegar até a linha defeituosa (/dev/nonexistent /data xfs defaults 0 0) e excluí-la. Você pode excluir a linha inteira pressionando Ctrl+k. Depois que a linha for removida, salve o arquivo pressionando Ctrl+x, depois y e, finalmente, Enter.

Para confirmar a correção, execute sudo mount -a novamente.

sudo mount -a

Desta vez, o comando deve ser executado silenciosamente, sem saída, o que indica que todas as entradas válidas em /etc/fstab estão corretamente montadas. Você reparou o arquivo com sucesso.

Resumo

Neste laboratório, você aprendeu técnicas essenciais para solucionar problemas no processo de inicialização do Red Hat Enterprise Linux. Você praticou o gerenciamento de alvos de inicialização do systemd, como visualizar o padrão atual e alterá-lo entre graphical.target e multi-user.target usando systemctl. Você também aprendeu como interromper a sequência de inicialização para acessar ambientes de recuperação especializados, incluindo a inicialização no modo de resgate a partir do menu GRUB para executar tarefas de manutenção do sistema em um shell de usuário único.

Além disso, você executou procedimentos críticos de recuperação para falhas comuns do sistema. Você redefiniu com sucesso uma senha root esquecida usando o parâmetro do kernel rd.break, remontando o sistema de arquivos root com permissões de gravação e usando um ambiente chroot para definir uma nova senha, ao mesmo tempo em que abordou o contexto SELinux criando um arquivo .autorelabel. Por fim, você aprendeu a resolver falhas de inicialização causadas por erros em /etc/fstab entrando no modo de emergência, identificando a entrada problemática e comentando-a para permitir que o sistema inicialize com sucesso.