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 a inicialização correta do sistema. Isso inclui trabalhar com alvos de inicialização do systemd e utilizar modos de inicialização especializados projetados para a recuperação do sistema.

Ao longo dos exercícios, você ganhará experiência prática no gerenciamento de alvos do systemd com o systemctl, na inicialização em modo de resgate a partir do menu GRUB para manutenção do sistema e na redefinição da senha de root usando o parâmetro de kernel rd.break. Além disso, você aprenderá a 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 que não inicializa para um estado operacional.

Gerenciar alvos de inicialização do Systemd com systemctl

Nesta etapa, você aprenderá a gerenciar alvos (targets) de inicialização do systemd. No systemd, um "alvo" é 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" nos sistemas de inicialização SysV 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.

Primeiro, vá para o diretório de prática deste laboratório.

cd /home/labex/project

Primeiro, 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 de usuário (GUI). O multi-user.target é para uma interface apenas de linha de comando.

Para ver o alvo padrão atual e salvar o resultado para revisão posterior, execute o seguinte comando:

systemctl get-default | tee step1-initial-target.txt

Você 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 situações de solução de problemas onde a interface gráfica não é necessária ou está causando problemas. O comando systemctl set-default realiza isso alterando o link simbólico /etc/systemd/system/default.target.

Use o 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 e salvando o resultado.

systemctl get-default | tee step1-multi-user-target.txt

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

multi-user.target

Com essa 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 de volta.

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 que o alvo padrão foi restaurado para graphical.target e salve o resultado.

systemctl get-default | tee step1-final-target.txt

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 encerraria sua sessão gráfica e alternaria para um console apenas de texto. Este é um comando poderoso, mas potencialmente disruptivo, por isso não o executaremos aqui.

Agora você usou com sucesso o systemctl para gerenciar alvos do systemd.

Nesta etapa, você aprenderá sobre o rescue.target, um alvo especial do systemd projetado para a 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 raiz 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 conteinerizado, ainda podemos explorar a configuração do modo de resgate para entender como ele funciona.

Primeiro, vamos localizar o arquivo de unidade do systemd para o rescue.target. Esses arquivos geralmente são 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 proprietário.

-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, e o tee salvará uma cópia em seu diretório de prática.

cat /usr/lib/systemd/system/rescue.target | tee /home/labex/project/rescue-target.txt

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

As diretivas principais neste arquivo incluem:

Description=Rescue Mode: Um nome legível para o alvo.
Requires=sysinit.target rescue.service: Isso garante que tanto o sysinit.target (inicialização básica do sistema) quanto o rescue.service sejam iniciados quando este alvo for ativado. O serviço de resgate fornece o shell de manutenção raiz.
After=sysinit.target rescue.service: Isso especifica a ordem de ativação, garantindo que o modo de resgate inicie após a inicialização do sistema e o serviço de resgate.
AllowIsolate=yes: Isso permite que você alterne para este alvo a partir 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. Salve essa saída também.

systemctl list-dependencies rescue.target | tee /home/labex/project/rescue-dependencies.txt

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
... (a saída pode variar) ...

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

Redefinir a senha de root usando rd.break e chroot

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

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:

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

Embora não possamos realizar uma reinicialização real e usar o 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 de root. Imagine que você entrou com sucesso na prisão chroot. Agora você 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 redigitar a nova senha. Defina-a como redhat.

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 do SELinux no arquivo de senha (/etc/shadow) pode ficar incorreto. Para corrigir isso, você deve forçar uma reetiquetagem completa do SELinux do sistema na próxima inicialização. Isso é feito criando um arquivo vazio chamado .autorelabel no diretório raiz (/).

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 <data> <hora> /.autorelabel

Em um sistema real, você agora digitaria exit duas vezes e deixaria o sistema reiniciar. Ele realizaria o longo processo de reetiquetagem e, em seguida, inicializaria normalmente com a nova senha. Deixe o arquivo /.autorelabel no lugar para verificação neste laboratório; a etapa de verificação o removerá automaticamente após a verificação.

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

Reparar erros no /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 no /etc/fstab pode impedir a inicialização do sistema, 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 raiz (/) é montado no modo somente leitura (ro) para evitar danos adicionais.

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

Primeiro, vamos adicionar intencionalmente uma entrada defeituosa ao /etc/fstab. Usaremos o comando echo com sudo para anexar uma linha que faz referência a um dispositivo inexistente.

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

Agora, vamos visualizar o conteúdo do /etc/fstab para confirmar que nossa linha incorreta foi adicionada e salvar uma cópia antes de repará-la.

cat /etc/fstab | tee /home/labex/project/step4-fstab-before.txt

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

#
## /etc/fstab
## Created by anaconda on <data>
#
## 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 no /etc/fstab que ainda não estão montados. Como nossa entrada é inválida, este comando falhará. Salve a saída de erro para que você possa compará-la com o estado reparado posteriormente.

sudo mount -a 2>&1 | tee /home/labex/project/step4-mount-error.txt

O comando produzirá um erro, indicando claramente que a entrada incorreta /dev/nonexistent não pode ser montada. Isso é semelhante ao tipo de erro que você veria durante uma inicialização com falha.

mount: /data: fsconfig system call failed: /dev/nonexistent: Can't lookup blockdev.
       dmesg(1) may have more information after failed mount system call.

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

sudo mount -o remount,rw /

Com o sistema de arquivos agora gravável, você pode editar o /etc/fstab para corrigir o erro. Use nano, vi ou outro editor de terminal com o qual você se sinta confortável para abrir o arquivo.

sudo vi /etc/fstab

Dentro do editor, navegue até a linha defeituosa (/dev/nonexistent /data xfs defaults 0 0) e exclua-a, depois salve o arquivo.

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 no /etc/fstab estão montadas corretamente. 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 alterná-lo entre graphical.target e multi-user.target usando o 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 realizar tarefas de manutenção do sistema em um shell de usuário único.

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