Solución de Problemas del Proceso de Arranque de RHEL

Introducción

En este laboratorio, aprenderá técnicas esenciales para la solución de problemas y la reparación del proceso de arranque de Red Hat Enterprise Linux (RHEL). Explorará cómo interactuar con el sistema en diferentes etapas de la secuencia de arranque para diagnosticar y resolver problemas comunes que pueden impedir que un sistema se inicie correctamente. Esto incluye trabajar con los objetivos de arranque de systemd y utilizar modos de arranque especializados diseñados para la recuperación del sistema.

A lo largo de los ejercicios, obtendrá experiencia práctica en la gestión de objetivos de systemd con systemctl, el arranque en modo de rescate desde el menú GRUB para el mantenimiento del sistema y el restablecimiento de la contraseña de root utilizando el parámetro del kernel rd.break. Además, aprenderá a utilizar el modo de emergencia para reparar errores críticos en los archivos de configuración, como un /etc/fstab corrupto, asegurándose de que puede restaurar un sistema que no arranca a un estado operativo.

Gestionar los Objetivos de Arranque de Systemd con systemctl

En este paso, aprenderá a gestionar los objetivos de arranque de systemd. En systemd, un "objetivo" (target) es un punto de sincronización que agrupa varios servicios y otras unidades necesarias para llevar el sistema a un estado determinado. Este es el equivalente moderno de los "niveles de ejecución" (runlevels) en los sistemas SysV init más antiguos. Exploraremos cómo ver el objetivo predeterminado actual, cambiar el objetivo predeterminado para futuros arranques y cambiar temporalmente a un objetivo diferente.

Primero, comprobemos en qué objetivo se inicia su sistema de forma predeterminada. El graphical.target se utiliza para sistemas con un entorno de escritorio, proporcionando una interfaz gráfica de usuario (GUI). El multi-user.target es para una interfaz solo de línea de comandos.

Para ver el objetivo predeterminado actual, ejecute el siguiente comando:

systemctl get-default

Debería ver que el objetivo predeterminado es el objetivo gráfico.

graphical.target

Ahora, cambiemos el objetivo de arranque predeterminado a multi-user.target. Esto es útil para entornos de servidor o para solucionar problemas en situaciones donde la interfaz gráfica no es necesaria o está causando problemas. El comando systemctl set-default logra esto cambiando el enlace simbólico /etc/systemd/system/default.target.

Use sudo para ejecutar este comando con privilegios administrativos.

sudo systemctl set-default multi-user.target

La salida confirma que el enlace simbólico se ha actualizado.

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

Puede verificar que el valor predeterminado ha sido cambiado ejecutando el comando get-default de nuevo.

systemctl get-default

La salida ahora muestra el nuevo objetivo predeterminado.

multi-user.target

Con esta configuración, el sistema se iniciaría en una consola basada en texto después de un reinicio. Para este laboratorio, queremos mantener un entorno gráfico consistente. Volvamos a establecer el objetivo predeterminado en graphical.target.

sudo systemctl set-default graphical.target

Verá una salida similar a la anterior, lo que indica que el enlace simbólico ha sido cambiado de nuevo.

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

Ejecute una comprobación final para confirmar que el objetivo predeterminado se ha restaurado a graphical.target.

systemctl get-default

graphical.target

Además de cambiar el objetivo predeterminado para los reinicios, también puede cambiar los objetivos en la sesión actual utilizando systemctl isolate. Este comando detiene los servicios no asociados con el nuevo objetivo e inicia los que sí lo están. Por ejemplo, ejecutar sudo systemctl isolate multi-user.target terminaría su sesión gráfica y cambiaría a una consola solo de texto. Este es un comando potente pero potencialmente disruptivo, por lo que no lo ejecutaremos aquí.

Ahora ha utilizado con éxito systemctl para gestionar los objetivos de systemd.

Arrancar en Modo de Rescate desde el Menú GRUB

En este paso, aprenderá sobre rescue.target, un objetivo systemd especial diseñado para la recuperación del sistema. En un sistema RHEL estándar, accedería a este modo reiniciando, interrumpiendo el gestor de arranque (GRUB) y agregando un parámetro a las opciones de arranque del kernel. Esto proporciona un shell de usuario único con el sistema de archivos raíz montado y la mayoría de los servicios deshabilitados, lo cual es ideal para la solución de problemas.

Si bien no podemos realizar un reinicio real ni acceder al menú GRUB en este entorno de laboratorio en contenedores, aún podemos explorar la configuración del modo de rescate para comprender cómo funciona.

Primero, localicemos el archivo de unidad systemd para rescue.target. Estos archivos se almacenan típicamente en el directorio /usr/lib/systemd/system/.

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

Verá el archivo listado con sus permisos y propiedad.

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

Ahora, examinemos el contenido de este archivo para comprender su configuración. El comando cat mostrará el contenido del archivo en la terminal.

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

La salida muestra la definición del objetivo.

##  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

Las directivas clave en este archivo incluyen:

• Description=Rescue Mode: Un nombre legible para el objetivo.
• Requires=sysinit.target rescue.service: Esto asegura que tanto sysinit.target (inicialización básica del sistema) como rescue.service se inicien cuando este objetivo se activa. El servicio de rescate proporciona el shell de mantenimiento root.
• After=sysinit.target rescue.service: Esto especifica el orden de activación, asegurando que el modo de rescate se inicie después de la inicialización del sistema y el servicio de rescate.
• AllowIsolate=yes: Esto le permite cambiar a este objetivo desde otro objetivo utilizando el comando systemctl isolate rescue.target en un sistema en ejecución.

Para tener una mejor idea del entorno mínimo que proporciona el modo de rescate, puede ver sus dependencias. El comando systemctl list-dependencies muestra todas las unidades que se inician como parte de un objetivo.

systemctl list-dependencies rescue.target

La salida enumera las unidades requeridas para el modo de rescate. Verá un conjunto mínimo de servicios, lo que confirma que es un entorno optimizado diseñado para tareas de reparación.

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) ...

La conclusión clave es que rescue.target proporciona un shell root con el sistema de archivos montado en modo lectura-escritura, lo que le permite solucionar problemas del sistema. En los siguientes pasos, simularemos escenarios de recuperación que se basan en principios similares.

Restablecer la Contraseña de Root usando rd.break y chroot

En este paso, aprenderá el procedimiento para restablecer una contraseña de root perdida en un sistema RHEL. Esta es una habilidad de recuperación crítica. El método estándar implica interrumpir el proceso de arranque con el parámetro del kernel rd.break, lo que le da acceso a un shell antes de que el sistema se inicie por completo.

En una máquina física o virtual, reiniciaría, interrumpiría el gestor de arranque GRUB y agregaría rd.break al final de la línea del kernel linux. Esta acción detiene el proceso de arranque justo antes de que systemd tome el control, colocándolo en un shell initramfs. A partir de ahí, los pasos generales son:

1. Remontar el sistema de archivos raíz (que está montado en modo de solo lectura en /sysroot) en modo lectura-escritura con el comando mount -o remount,rw /sysroot.
2. Entrar en una jaula chroot en /sysroot con chroot /sysroot. Esto hace que el sistema de archivos raíz real del sistema sea su entorno actual, lo que le permite ejecutar comandos que afectan al sistema.
3. Cambiar la contraseña usando el comando passwd.
4. Abordar posibles problemas de contexto SELinux.
5. Salir del chroot y del shell initramfs para continuar el arranque.

Si bien no podemos realizar un reinicio real y usar rd.break en este entorno de laboratorio, simularemos los comandos más importantes que ejecutaría después de ingresar al entorno chroot.

Primero, simulemos el cambio de la contraseña de root. Imagine que ha ingresado con éxito en la jaula chroot. Ahora tendría acceso root para cambiar la contraseña de cualquier usuario. Usaremos el comando sudo passwd root para cambiar la contraseña del usuario root. Cuando se le solicite, establezca la nueva contraseña en redhat.

sudo passwd root

Se le pedirá que ingrese y vuelva a ingresar la nueva contraseña (por ejemplo, labex.io).

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

Después de cambiar la contraseña en este entorno de recuperación, el contexto de seguridad SELinux en el archivo de contraseña (/etc/shadow) puede volverse incorrecto. Para solucionar esto, debe forzar una reetiquetación completa del sistema SELinux en el próximo arranque. Esto se hace creando un archivo vacío llamado .autorelabel en el directorio raíz (/).

sudo touch /.autorelabel

Verifiquemos que el archivo se creó.

ls -l /.autorelabel

La salida debería mostrar el archivo recién creado.

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

En un sistema real, ahora escribiría exit dos veces y dejaría que el sistema se reiniciara. Realizaría el largo proceso de reetiquetado y luego arrancaría normalmente con la nueva contraseña. Dado que no queremos activar esto en nuestro laboratorio, limpiaremos eliminando el archivo que acabamos de crear.

sudo rm /.autorelabel

Esto concluye la simulación del restablecimiento de la contraseña de root. Ha practicado los comandos clave (passwd y touch /.autorelabel) que son fundamentales para el proceso de recuperación.

Reparar Errores en /etc/fstab usando el Modo de Emergencia

En este paso, aprenderá a diagnosticar y reparar errores en el archivo /etc/fstab. Este archivo es crítico para el proceso de arranque, ya que le indica al sistema qué sistemas de archivos montar y dónde. Una entrada incorrecta en /etc/fstab puede impedir que el sistema arranque, forzándolo a entrar en el modo de emergencia.

El modo de emergencia proporciona el entorno más mínimo posible para la reparación del sistema. A diferencia del modo de rescate, no intenta montar la mayoría de los sistemas de archivos ni iniciar muchos servicios. Crucialmente, el sistema de archivos raíz (/) se monta en modo de solo lectura (ro) para evitar daños mayores.

Si bien no podemos activar una falla de arranque real en este laboratorio, podemos simular el proceso de encontrar y solucionar un error de /etc/fstab.

Primero, agreguemos intencionalmente una entrada defectuosa a /etc/fstab. Usaremos el comando echo con sudo para agregar una línea que haga referencia a un dispositivo inexistente.

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

Ahora, veamos el contenido de /etc/fstab para confirmar que se agregó nuestra línea incorrecta.

cat /etc/fstab

Debería ver la línea incorrecta al final del archivo.

#
## /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

A continuación, simularemos el paso de diagnóstico. El comando mount -a intenta montar todos los sistemas de archivos enumerados en /etc/fstab que aún no están montados. Dado que nuestra entrada no es válida, este comando fallará.

sudo mount -a

El comando producirá un error, indicando claramente que el punto de montaje /data no existe. Esto es similar al error que vería durante un arranque fallido.

mount: /data: mount point does not exist.

Ahora, simulemos el proceso de reparación. En un shell de emergencia real, el primer paso es volver a montar el sistema de archivos raíz en modo lectura-escritura para permitir cambios.

sudo mount -o remount,rw /

Con el sistema de archivos ahora escribible, puede editar /etc/fstab para corregir el error. Use el editor nano para abrir el archivo.

sudo nano /etc/fstab

Dentro del editor nano, use las teclas de flecha para navegar a la línea defectuosa (/dev/nonexistent /data xfs defaults 0 0) y eliminarla. Puede eliminar toda la línea presionando Ctrl+k. Una vez que se elimina la línea, guarde el archivo presionando Ctrl+x, luego y y finalmente Enter.

Para confirmar la corrección, ejecute sudo mount -a nuevamente.

sudo mount -a

Esta vez, el comando debería ejecutarse silenciosamente sin ninguna salida, lo que indica que todas las entradas válidas en /etc/fstab están correctamente montadas. Ha reparado con éxito el archivo.

Resumen

En este laboratorio, aprendió técnicas esenciales para solucionar problemas del proceso de arranque de Red Hat Enterprise Linux. Practicó la gestión de objetivos de arranque de systemd, como ver el valor predeterminado actual y cambiarlo entre graphical.target y multi-user.target usando systemctl. También aprendió a interrumpir la secuencia de arranque para acceder a entornos de recuperación especializados, incluyendo el arranque en modo de rescate desde el menú GRUB para realizar tareas de mantenimiento del sistema en un shell de usuario único.

Además, ejecutó procedimientos de recuperación críticos para fallas comunes del sistema. Restableció con éxito una contraseña de root olvidada utilizando el parámetro del kernel rd.break, remontando el sistema de archivos raíz con permisos de escritura y utilizando un entorno chroot para establecer una nueva contraseña, al tiempo que abordó el contexto SELinux creando un archivo .autorelabel. Por último, aprendió a resolver fallas de arranque causadas por errores de /etc/fstab entrando en modo de emergencia, identificando la entrada problemática y comentándola para permitir que el sistema arranque con éxito.