Read-only file system

Qué comprobar, y en qué orden

En el orden en que lo miramos nosotros. No es un ranking de frecuencia: no publicamos estadísticas que no hemos medido.

1. 1

   El kernel detectó un error de entrada/salida y remontó por seguridad. Es la primera hipótesis y hay que descartarla antes que nada.

   Comprobar

   sudo dmesg -T | grep -iE 'i/o error|remount|ext4-fs error|xfs' | tail -20

   Corregir

   # Si hay errores de E/S, el disco puede estar fallando. Antes de tocar nada,
   # asegura una copia de los datos y revisa el estado del dispositivo:
   sudo smartctl -H /dev/sda

2. 2

   El sistema de ficheros tiene inconsistencias y necesita revisión.

   Comprobar

   sudo touch /prueba-escritura 2>&1
   mount | grep ' / '

   Corregir

   # Con el sistema desmontado o desde un arranque de rescate:
   sudo fsck -f /dev/sda1
   # No se ejecuta fsck sobre un sistema de ficheros montado en lectura-escritura.
   # En XFS —el sistema por defecto en RHEL, Rocky y AlmaLinux— fsck.xfs no
   # hace nada a propósito: la herramienta es xfs_repair, y sobre el volumen
   # desmontado.
   #   sudo xfs_repair /dev/sda1

3. 3

   Está montado así a propósito en fstab, o es una imagen de contenedor de solo lectura.

   Comprobar

   findmnt -no OPTIONS /

   Corregir

   # Si es intencionado, escribe en el volumen que corresponda.
   # Si no, corrige la entrada de /etc/fstab.

4. 4

   En un proveedor de nube, el volumen se ha desconectado o ha entrado en modo degradado.

   Comprobar

   sudo dmesg -T | grep -iE 'detached|lost page write|blk_update_request' | tail -10

   Corregir

   # Revisar el estado del volumen en el panel del proveedor antes de reiniciar.