Solución de problemas en el proceso de arranque de RHEL

Introducción

En este laboratorio, aprenderás técnicas esenciales para diagnosticar y reparar el proceso de arranque de Red Hat Enterprise Linux (RHEL). Explorarás cómo interactuar con el sistema en diferentes etapas de la secuencia de inicio para identificar y resolver problemas comunes que impiden que el sistema se inicie correctamente. Esto incluye trabajar con los objetivos (targets) 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ás experiencia práctica gestionando objetivos de systemd con systemctl, arrancando en modo rescate desde el menú de GRUB para realizar mantenimiento del sistema y restableciendo la contraseña de root mediante el parámetro del kernel rd.break. Además, aprenderás a utilizar el modo de emergencia para reparar errores críticos en archivos de configuración, como un /etc/fstab corrupto, asegurando que puedas restaurar un sistema que no arranca a un estado operativo.

Gestión de objetivos de arranque de systemd con systemctl

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

Primero, dirígete al directorio de prácticas de este laboratorio.

cd /home/labex/project

Comencemos verificando en qué objetivo arranca tu sistema de forma predeterminada. El graphical.target se utiliza para sistemas con entorno de escritorio, proporcionando una interfaz gráfica de usuario (GUI). El multi-user.target es para una interfaz exclusiva de línea de comandos.

Para ver el objetivo predeterminado actual y guardar el resultado para su revisión posterior, ejecuta el siguiente comando:

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

Deberías 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 situaciones de resolución de problemas donde la interfaz gráfica no es necesaria o está causando conflictos. El comando systemctl set-default logra esto cambiando el enlace simbólico /etc/systemd/system/default.target.

Usa sudo para ejecutar este comando con privilegios administrativos.

sudo systemctl set-default multi-user.target

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

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

Puedes verificar que el valor predeterminado ha cambiado ejecutando el comando get-default nuevamente y guardando el resultado.

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

La salida ahora muestra el nuevo objetivo predeterminado.

multi-user.target

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

sudo systemctl set-default graphical.target

Verás una salida similar a la anterior, indicando que el enlace simbólico ha vuelto a su estado original.

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

Ejecuta una comprobación final para confirmar que el objetivo predeterminado se ha restaurado a graphical.target y guarda el resultado.

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

graphical.target

Además de cambiar el objetivo predeterminado para los reinicios, también puedes cambiar de objetivo en la sesión actual usando 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 tu sesión gráfica y cambiaría a una consola de solo texto. Este es un comando potente pero potencialmente disruptivo, por lo que no lo ejecutaremos aquí.

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

Arranque en modo rescate desde el menú de GRUB

En este paso, aprenderás sobre rescue.target, un objetivo especial de systemd diseñado para la recuperación del sistema. En un sistema RHEL estándar, accederías a este modo reiniciando, interrumpiendo el cargador de arranque (GRUB) y añadiendo un parámetro a las opciones de arranque del kernel. Esto proporciona una 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 resolución de problemas.

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

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

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

Verás el archivo listado con sus permisos y propietario.

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

Ahora, examinemos el contenido de este archivo para entender su configuración. El comando cat mostrará el contenido del archivo en la terminal, y tee guardará una copia en tu directorio de prácticas.

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

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 se activa este objetivo. El servicio de rescate proporciona la shell de mantenimiento raíz.
After=sysinit.target rescue.service: Especifica el orden de activación, asegurando que el modo rescate se inicie después de la inicialización del sistema y del servicio de rescate.
AllowIsolate=yes: Esto permite cambiar a este objetivo desde otro objetivo usando 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 rescate, puedes ver sus dependencias. El comando systemctl list-dependencies muestra todas las unidades que se inician como parte de un objetivo. Guarda esa salida también.

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

La salida enumera las unidades requeridas para el modo rescate. Verás un conjunto mínimo de servicios, confirmando 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
... (la salida puede variar) ...

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

Restablecimiento de la contraseña de root usando rd.break y chroot

En este paso, aprenderás 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 te da acceso a una shell antes de que el sistema se inicie por completo.

En una máquina física o virtual, reiniciarías, interrumpirías el cargador de arranque GRUB y añadirías 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ándote en una shell de initramfs. A partir de ahí, los pasos generales son:

Volver a montar el sistema de archivos raíz del sistema (que está montado en modo solo lectura en /sysroot) en modo lectura-escritura con el comando mount -o remount,rw /sysroot.
Entrar en una jaula chroot en /sysroot con chroot /sysroot. Esto hace que el sistema de archivos raíz real del sistema sea tu entorno actual, permitiéndote ejecutar comandos que afectan al sistema.
Cambiar la contraseña usando el comando passwd.
Abordar posibles problemas de contexto de SELinux.
Salir del chroot y de la shell de initramfs para continuar con el arranque.

Aunque no podemos realizar un reinicio real y usar rd.break en este entorno de laboratorio, simularemos los comandos más importantes que ejecutarías después de entrar en el entorno chroot.

Primero, simulemos el cambio de la contraseña de root. Imagina que has entrado con éxito en la jaula chroot. Ahora tendrías acceso de 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 te solicite, establece la nueva contraseña como redhat.

sudo passwd root

Se te pedirá que ingreses y vuelvas a ingresar la nueva contraseña. Establécela como redhat.

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 de SELinux en el archivo de contraseñas (/etc/shadow) puede volverse incorrecto. Para solucionar esto, debes forzar un reetiquetado completo de SELinux en el sistema 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 haya creado.

ls -l /.autorelabel

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

-rw-r--r--. 1 root root 0 <fecha> <hora> /.autorelabel

En un sistema real, ahora escribirías exit dos veces y dejarías que el sistema se reiniciara. Realizaría el largo proceso de reetiquetado y luego arrancaría normalmente con la nueva contraseña. Deja el archivo /.autorelabel en su lugar para la verificación en este laboratorio; el paso de verificación lo eliminará automáticamente después de comprobarlo.

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

Reparación de errores en /etc/fstab usando el modo de emergencia

En este paso, aprenderás 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 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 rescate, no intenta montar la mayoría de los sistemas de archivos ni iniciar muchos servicios. Fundamentalmente, el sistema de archivos raíz (/) se monta en modo solo lectura (ro) para evitar daños mayores.

Aunque no podemos provocar un fallo de arranque real en este laboratorio, podemos simular el proceso de encontrar y corregir un error en /etc/fstab.

Primero, añadamos intencionalmente una entrada defectuosa a /etc/fstab. Usaremos el comando echo con sudo para añadir una línea que hace 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 añadió nuestra línea incorrecta, y guarda una copia antes de repararlo.

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

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

#
## /etc/fstab
## Created by anaconda on <fecha>
#
## 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 listados en /etc/fstab que aún no están montados. Dado que nuestra entrada no es válida, este comando fallará. Guarda la salida del error para que puedas compararla con el estado reparado más adelante.

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

El comando producirá un error, indicando claramente que la entrada incorrecta /dev/nonexistent no se puede montar. Esto es similar al tipo de error que verías durante un arranque fallido.

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

Ahora, simulemos el proceso de reparación. En una 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, puedes editar /etc/fstab para corregir el error. Usa nano, vi u otro editor de terminal con el que te sientas cómodo para abrir el archivo.

sudo vi /etc/fstab

Dentro del editor, navega hasta la línea defectuosa (/dev/nonexistent /data xfs defaults 0 0) y elimínala, luego guarda el archivo.

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

sudo mount -a

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

Resumen

En este laboratorio, aprendiste técnicas esenciales para solucionar problemas en el proceso de arranque de Red Hat Enterprise Linux. Practicaste 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 aprendiste cómo interrumpir la secuencia de arranque para acceder a entornos de recuperación especializados, incluyendo el arranque en modo rescate desde el menú de GRUB para realizar tareas de mantenimiento del sistema en una shell de usuario único.

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