Incidencia real en producción: Ubuntu cae a initramfs por corrupción del sistema de archivos (fsck / LVM)

Una máquina virtual con Ubuntu dejó de arrancar de forma repentina y terminó en el entorno BusyBox (initramfs). El mensaje en pantalla era el clásico aviso de emergencia: “UNEXPECTED INCONSISTENCY” sobre el sistema de archivos raíz, acompañado de la recomendación de ejecutar una comprobación manual.

En entornos virtualizados, este tipo de fallo es más habitual de lo que parece. El problema no suele ser “Ubuntu” en sí, sino la integridad del filesystem en el volumen donde vive / (root). Cuando el kernel detecta inconsistencias graves durante el montaje temprano, detiene el proceso de arranque para evitar que el daño se agrave.


Qué ocurrió exactamente

Síntoma observado

  • La VM no completa el arranque.
  • Entra en initramfs con BusyBox.
  • Aparece un error de inconsistencia y se solicita intervención manual (fsck).

Causa más probable

Inconsistencias en el sistema de archivos del volumen lógico raíz bajo LVM, típicamente por:

  • Apagados no controlados (crash, corte eléctrico, reset forzado).
  • Snapshots interrumpidos o restauraciones a medias.
  • Problemas en el almacenamiento del hypervisor (latencias extremas, timeouts, cortes del datastore, fallos en cabina/NAS/SAN, etc.).
  • Menos frecuente, pero posible: errores de kernel/panic o bugs asociados a I/O.

La clave es que el sistema de archivos quedó en un estado “sucio” o directamente inconsistente, y el arranque se para antes de montar / en modo lectura-escritura.


Resolución aplicada en el propio initramfs

Desde el prompt de BusyBox se lanzó una comprobación forzada con reparación automática sobre el volumen lógico raíz:

fsck -fy /dev/mapper/ubuntu--vg-ubuntu--lv

Qué hace cada parámetro

  • -f: fuerza la comprobación aunque el sistema crea que no es necesaria.
  • -y: responde “sí” a todas las reparaciones propuestas, evitando parar a mitad del proceso.

Tras finalizar fsck, se reinició el sistema.


Resultado

  • La VM volvió a arrancar correctamente.
  • No fue necesaria reinstalación.
  • No se reportaron pérdidas de datos a nivel funcional (aunque conviene revisar logs y aplicaciones).

Buenas prácticas después de “salvar” el arranque

  1. Revisar el motivo del apagado
    • logs del hypervisor, eventos de almacenamiento, watchdogs, reinicios del host, etc.
  2. Verificar salud del almacenamiento
    • latencias, rutas iSCSI/FC, estado del datastore, alarmas de cabina/NAS.
  3. Comprobar el journal y errores previos
    • journalctl -b -1, dmesg -T, /var/log/kern.log.
  4. Validar consistencia de servicios
    • bases de datos (recovery), colas, integridad de aplicaciones.
  5. Reducir probabilidad de repetición
    • apagar VM de forma ordenada, políticas de snapshot claras, timeouts y almacenamiento con garantías.

Conclusión operativa

Cuando Ubuntu cae a initramfs por un “UNEXPECTED INCONSISTENCY”, fsck desde el entorno de arranque sigue siendo una de las vías más directas y efectivas para recuperar un sistema, especialmente si el root está en LVM. Es una intervención simple, rápida y, bien aplicada, evita reinstalaciones innecesarias y reduce el tiempo de indisponibilidad en producción.

vía: LinkedIN

Suscríbete al boletín SysAdmin

Este es tu recurso para las últimas noticias y consejos sobre administración de sistemas, Linux, Windows, cloud computing, seguridad de la nube, etc. Lo enviamos 2 días a la semana.

¡Apúntate a nuestro newsletter!


– patrocinadores –

Noticias destacadas

– patrocinadores –

¡SUSCRÍBETE AL BOLETÍN
DE LOS SYSADMINS!

Scroll al inicio
×