Cómo iniciar Ubuntu Server en modo de emergencia: una guía de rescate paso a paso

Tu servidor Ubuntu se reinicia tras una actualización o un corte de energía y se detiene en el mensaje "Entrando en modo de emergencia". SSH no está disponible, los servicios están caídos y la consola solicita mantenimiento. Esto suele significar que systemd no pudo completar un paso de arranque necesario, a menudo porque falló una comprobación del sistema de archivos o no se encontró un punto de montaje necesario. Considera este mensaje como una pista: identifica la unidad defectuosa antes de editar archivos o ejecutar un comando de reparación.

Esta guía se aplica a las instalaciones convencionales de Ubuntu Server que utilizan systemd. Los comandos y menús de arranque pueden variar en Ubuntu Core, sistemas cifrados, imágenes en la nube y servidores gestionados por el proveedor. Las páginas man actuales de Ubuntu describen emergency.target como un intérprete de comandos mínimo que no inicia servicios normales ni monta sistemas de archivos convencionales; según cómo se acceda a él, el sistema de archivos raíz puede ser de solo lectura o de lectura y escritura. Por ello, los primeros pasos son la inspección y una copia de seguridad.

1. Lea el informe de error antes de cambiar nada.

Inicie sesión en la consola local o del proveedor si se le solicita. En una máquina física, conecte un teclado y un monitor; en un servidor virtual, utilice la consola serie o de recuperación del proveedor. Fotografie o copie el error completo, especialmente el nombre de la unidad systemd-fsck@dev-disk-by-uuid-....serviceo una unidad de montaje que termine en .mount. Un UUID faltante, una comprobación del sistema de archivos fallida y un servicio dañado requieren soluciones diferentes.

Desde la consola de emergencia, inspeccione las unidades que fallaron y el registro de arranque actual:

systemctl --failed
journalctl -xb

Busque el primer error significativo, no solo la línea final de "fallo de dependencia". Si el registro identifica un montaje, anote su punto de montaje y el UUID del dispositivo. Si identifica un servicio no relacionado con el almacenamiento, no realice cambios /etc/fstabal azar; inspeccione esa unidad específica systemctl status unit-namey sus mensajes de registro recientes.

2. Compruebe si el sistema de archivos raíz permite ediciones.

Antes de editar un archivo de configuración, vea cómo está montado el sistema de archivos raíz:

findmnt /

Si las opciones muestran ro, el sistema de archivos raíz es de solo lectura. Si el sistema de archivos está en buen estado y necesita realizar una pequeña reparación de configuración, vuelva a montarlo en modo lectura/escritura:

mount -o remount,rw /

Vuelva findmnt /a ejecutar el proceso para confirmar el cambio. Si el remontaje falla, deténgase y registre el error. Un volumen raíz de solo lectura puede ser una medida de protección ante problemas en el sistema de archivos; forzar escrituras o intentar repetidamente el montaje puede dificultar la recuperación. Si el volumen raíz parece dañado, utilice un entorno de recuperación o póngase en contacto con el soporte técnico del proveedor.

3. Inspeccione los discos y compárelos con /etc/fstab.

Una causa común es una /etc/fstabentrada obsoleta: se eliminó un disco, se cambió un UUID o se escribió incorrectamente una ruta de montaje. Primero, enumere los sistemas de archivos detectados y sus identificadores:

lsblk -f
blkid

A continuación, lea la configuración de la tabla de montaje:

cat /etc/fstab

Compare cada UUID configurado con la salida de lsblk -fo blkid, y verifique que el punto de montaje y el tipo de sistema de archivos sean correctos. No sustituya un nombre de dispositivo, como , /dev/sdb1basándose únicamente en su letra actual; el orden de los dispositivos puede cambiar. Los UUID suelen ser más estables, pero aun así deben coincidir con el sistema de archivos real.

El /etc/fstabarchivo se traduce a unidades de montaje de systemd durante el arranque. Sus campos y opciones tienen significados específicos, por lo que si alguna entrada le resulta desconocida, consulte el manual oficial de fstab de Ubuntu .

4. Omitir temporalmente un montaje opcional faltante

Si la entrada que falla apunta a un disco de datos no esencial que está ausente intencionalmente, haga una copia de seguridad /etc/fstaby luego comente solo esa línea colocando #al principio. Esto le permite comprobar si el punto de montaje faltante es el que bloquea el arranque. No comente el sistema de archivos raíz, /bootni una entrada de volumen cifrado a menos que comprenda la estructura de almacenamiento del sistema.

cp -a /etc/fstab /etc/fstab.before-emergency-fix
nano /etc/fstab

Alternativamente, si el disco debe ser opcional en el funcionamiento normal, considere la nofailopción de montaje tras verificar el comportamiento previsto. Úsela solo para un montaje realmente opcional: agregarla a un volumen del sistema obligatorio puede ocultar un fallo real de almacenamiento. Los sistemas de archivos de red pueden requerir opciones adicionales específicas de systemd y dependencias de red; no copie opciones de una configuración no relacionada.

Después de editar, pídale a systemd que recargue las unidades generadas y pruebe el archivo:

systemctl daemon-reload
mount -a

Lea toda la salida. Un resultado correcto no garantiza que todas las aplicaciones puedan usar los datos montados, pero un error de UUID, sintaxis o montaje indica qué queda por corregir. El manual systemd-fstab-generator explica cómo systemd convierte las entradas de fstab en unidades de montaje.

5. Reparar una UUID, ruta o opción de montaje incorrecta.

Si el disco está presente pero su UUID difiere, verifique que haya identificado el sistema de archivos correcto antes de actualizar el UUID=...campo correspondiente. Confirme que existe el directorio del punto de montaje, que el tipo de sistema de archivos es correcto y que las opciones son válidas para ese sistema de archivos. Corrija una entrada a la vez, luego vuelva a ejecutar systemctl daemon-reloady mount -a.

Para un disco de datos extraíble o secundario opcional, configurar una política de montaje opcional adecuada puede evitar que un dispositivo ausente bloquee el arranque. Para un volumen crítico, repare el dispositivo, el cable, la asignación de cifrado o el identificador en lugar de enmascarar el fallo. Si la unidad defectuosa identifica un dispositivo LUKS o LVM, inspeccione la asignación y el estado del volumen correspondientes; no reemplace su UUID con una partición de nombre similar.

6. Ejecutar una comprobación del sistema de archivos solo cuando el destino esté desmontado.

Si la consola informa específicamente de errores del sistema de archivos, identifique el tipo de sistema de archivos y el dispositivo antes de repararlo. No ejecute una utilidad de reparación en un sistema de archivos montado, especialmente en el sistema de archivos raíz activo. El manual de fsck de Ubuntu describe el comando auxiliar; las opciones correctas de verificación y reparación dependen del sistema de archivos.

Para una partición de datos ext2, ext3 o ext4, primero confirme que no esté montada con findmnt. Si está montada, desmóntela antes de comprobarla. Una comprobación típica de ext4 desde un entorno de recuperación adecuado es:

sudo e2fsck -f /dev/DEVICE

Reemplace /dev/DEVICEsolo después de que coincida con la partición correcta de lsblk -f. Lea las preguntas y el estado del verificador; no agregue una opción automática de "sí a todo" sin comprender el riesgo de pérdida de datos. Para un sistema de archivos raíz que no se puede desmontar desde la consola de emergencia en ejecución, inicie un entorno de recuperación en vivo o del proveedor y verifíquelo sin conexión. Btrfs, XFS y otros sistemas de archivos utilizan diferentes herramientas y procedimientos de reparación. En particular, no considere un fsckcomando genérico como prueba de que se reparó cada tipo de sistema de archivos.

7. Utilice GRUB o la recuperación externa solo cuando la consola no esté disponible.

Si el servidor nunca llega a una consola de emergencia, abra el menú GRUB e intente acceder a la entrada de recuperación de la distribución cuando esté disponible. En una instalación estándar de Ubuntu, el menú suele accederse manteniendo pulsada la tecla Mayús en sistemas BIOS heredados o pulsando Esc en sistemas UEFI, pero las máquinas virtuales alojadas pueden usar un flujo de consola diferente. Para un arranque de emergencia único de systemd, un administrador puede editar la entrada GRUB seleccionada y añadirla systemd.unit=emergency.targeta la línea de comandos del kernel de Linux. El cambio se aplica solo a ese arranque; elimínelo antes del siguiente arranque normal. Consulte la referencia oficial del menú GNU GRUB .

Si no se puede montar el volumen de arranque, utilice un entorno Ubuntu Live o el sistema de recuperación del proveedor de la nube para inspeccionarlo. Desbloquee el almacenamiento cifrado y active LVM solo si coincide con la instalación. Montar el sistema de archivos raíz de un servidor desde la recuperación conlleva riesgos adicionales; evite escribir en él hasta que se hayan identificado el disco y el sistema de archivos. Ubuntu Core utiliza su propio flujo de trabajo de recuperación y no se repara siguiendo ciegamente los pasos de GRUB de escritorio o de servidor convencionales.

8. Reinicie y verifique la reparación.

Cuando se corrija la causa reportada y las pruebas de montaje se realicen correctamente, reinicie el sistema:

reboot

Tras el arranque, verifique que el host alcance su objetivo multiusuario habitual, que los sistemas de archivos esperados estén montados y que los servicios importantes estén activos:

systemctl is-system-running
systemctl --failed
findmnt --target /

Compruebe los puntos de montaje de datos esperados con findmnt /path/to/mounty confirme los servicios críticos con systemctl status service-name. Si vuelve a aparecer el modo de emergencia, revise de nuevo el primer fallo del nuevo arranque en lugar de repetir la misma reparación. Un rescate exitoso significa que el servidor completa un arranque normal y que su almacenamiento y servicios necesarios están disponibles; simplemente llegar a la pantalla de inicio de sesión no es suficiente.

Para conocer el comportamiento actual de systemd, consulte el manual de unidades especiales de Ubuntu . Las versiones de los paquetes y los menús de recuperación pueden variar según la versión de Ubuntu y la plataforma de alojamiento, por lo que, si un comando o una unidad difieren, consulte la documentación de la versión instalada.