Solucionar problemas de arranque de máquinas virtuales Linux debidos a errores del sistema de archivos

Artículo
03/27/2024

Este artículo proporciona orientación para solucionar problemas de arranque de máquinas virtuales (VM) Linux causados por errores del sistema de archivos.

Síntomas

No puede conectarse a una máquina virtual (VM) Azure Linux mediante el protocolo Secure Shell (SSH) o el estado del agente VM en el portal Azure no es Listo. Cuando ejecuta el Diagnóstico de arranque en el portal de Azure o se conecta a la Serial Console, ve entradas de registro que se parecen a los siguientes ejemplos:

Nota:

No todos los ejemplos estarán presentes.
Un fallo de montaje no siempre provoca que una máquina virtual entre en modo de emergencia. Si el problema afecta a determinados sistemas de archivos críticos, es posible que la máquina virtual no utilice el modo de emergencia.

Ejemplo 1: Fallo al montar el sistema de ficheros ext4

EXT4-fs (sda1): INFO: recovery required on readonly filesystem
EXT4-fs (sda1): write access will be enabled during recovery
EXT4-fs warning (device sda1): ext4_clear_journal_err:4531: Filesystem error recorded from previous mount: IO failure
EXT4-fs warning (device sda1): ext4_clear_journal_err:4532: Marking fs in need of filesystem check.

Ejemplo 2: Fallo al montar el dispositivo ext Logical Volume Manager (LVM)

[   14.382472] EXT4-fs error (device dm-0): ext4_iget:4398: inode #8: comm mount: bad extra_isize 4060 (inode size 256)
[   14.389648] EXT4-fs (dm-0): no journal found
<snipped>
[FAILED] Failed to mount /opt/data.

Ejemplo 3: Fallo al montar el sistema de archivos xfs

[    8.543984] XFS (sdc1): Metadata CRC error detected at xfs_agi_read_verify+0xd0/0xf0 [xfs], xfs_agi block 0x10
[    8.553867] XFS (sdc1): Unmount and run xfs_repair
[    8.558993] XFS (sdc1): First 128 bytes of corrupted metadata buffer:
[    8.564893] 00000000: 58 41 47 49 00 00 00 01 00 00 00 00 00 1f ff c0  XAGI............
[    8.572847] 00000010: 00 00 00 40 00 00 00 06 00 00 00 01 00 00 00 3d  ...@...........=
[    8.580476] 00000020: 00 00 00 60 ff ff ff ff ff ff ff ff ff ff ff ff  ...`............
[    8.588219] 00000030: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
[    8.596280] 00000040: ff 07 f8 ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
[    8.603575] 00000050: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
[    8.610849] 00000060: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
[    8.619261] 00000070: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
[    8.629731] XFS (sdc1): metadata I/O error in "xfs_trans_read_buf_map" at daddr 0x10 len 8 error 74
[    8.637799] XFS (sdc1): xfs_imap_lookup: xfs_ialloc_read_agi() returned error -117, agno 0
[FAILED] Failed to mount /data.
See 'systemctl status data.mount' for details.
[DEPEND] Dependency failed for Local filesystems.

Ejemplo 4: Arrancar en modo de emergencia

You are in emergency mode. After logging in, type "journalctl -xb" to view
system logs, "systemctl reboot" to reboot, "systemctl default" or "exit"
to boot into default mode.
Give root password for maintenance
(or press Control-D to continue):

Causa

Las entradas de registro anteriores indican corrupción de disco. En determinadas situaciones, la corrupción del disco impedirá el arranque completo de la máquina virtual. Diversos problemas pueden causar la corrupción del disco, como problemas del kernel de Linux, errores de los controladores, errores en el hardware físico o virtual subyacente, etc.

Solución

Para resolver los problemas de arranque de la máquina virtual Linux causados por errores del sistema de archivos, recupere la máquina virtual reparando la corrupción del disco. Para reparar la corrupción del disco, siga estos pasos:

Identifique qué disco está dañado.
Identificar tipo de sistema de archivos.
Selecciona el modo de recuperación (online u offline).
Prepare el entorno de recuperación según el modo de recuperación que seleccione:
- Preparar el entorno para la recuperación en línea
- Preparar el entorno para la recuperación offline
Utilice herramientas de línea de comandos para reparar el sistema de archivos problemático del disco.
- Reparar sistema de archivos ext4
- Reparar sistema de archivos xfs
Nota:
- Es importante hacer una copia de seguridad de los datos críticos porque puede producirse una pérdida de datos en el disco recuperado.
- Antes de realizar cambios en un disco, haz una instantánea para conservar el estado actual del disco, aunque esté en estado de error. Arreglar la corrupción del disco cambiará los datos del disco, lo que conllevará riesgos.

Identificar el disco dañado

Para determinar qué disco está dañado, descargue el registro de serie de su máquina virtual utilizando la consola de serie o los diagnósticos de arranque, examine las entradas del registro durante el arranque y busque el error específico que indica qué disco o montaje está fallando.

He aquí tres ejemplos de entradas de registro. En estos ejemplos, observe el texto entre paréntesis, que informa del dispositivo dañado.

En el siguiente ejemplo, el dispositivo dañado es sdc1:

[   14.285807] XFS (sdc1): Mounting V5 Filesystem
[   14.426283] XFS (sdc1): Metadata CRC error detected at xfs_agi_read_verify+0xde/0x100 [xfs], xfs_agi block 0x10
[   14.426284] XFS (sdc1): Unmount and run xfs_repair
<snipped>
[FAILED] Failed to mount /opt/parent.

En el siguiente ejemplo, la partición en la que se produce un error del sistema de archivos es sda1:

EXT4-fs (sda1): INFO: recovery required on readonly filesystem
EXT4-fs (sda1): write access will be enabled during recovery
EXT4-fs warning (device sda1): ext4_clear_journal_err:4531: Filesystem error recorded from previous mount: IO failure
EXT4-fs warning (device sda1): ext4_clear_journal_err:4532: Marking fs in need of filesystem check.
<snipped>
[FAILED] Failed to mount /boot.

En el siguiente ejemplo, el dispositivo dañado es dm-2. Es un dispositivo Linux Device Mapper, que indica un volumen LVM.

[   18.014318] EXT4-fs (dm-2): VFS: Can't find ext4 filesystem
[FAILED] Failed to mount /home.
See 'systemctl status home.mount' for details.
[DEPEND] Dependency failed for Local File Systems.
[DEPEND] Dependency failed for Mark the need to relabel after reboot.

Si el dispositivo de disco al que se llama utiliza un nombre del formato "sdXN", donde X es una letra de la a-z y N es un número de partición opcional, significa que el disco está sin procesar y se puede operar con él utilizando la ruta /dev/sdXN.

Si el dispositivo de disco que se está montando utiliza un nombre como /dev/mapper/vgname/lvname, /dev/vgname/lvname, o dm-N, significa que se utiliza un dispositivo LVM. Tenga cuidado de reconocer todos los volúmenes físicos de disco (PV) que puedan estar en uso.

No se admite que el grupo de volúmenes LVM (VG) contenga el disco OS y cualquier número de discos de datos. En tal caso, existe un alto riesgo de pérdida de datos. Sin embargo, se permiten múltiples discos de datos en un LVM VG.

Al determinar la asignación de referencias de disco SO a objetos de disco Azure:

Para las imágenes de mercado, el sistema de archivos raíz (/), /boot y /boot/efi se encuentra en el disco del sistema operativo.
Para imágenes basadas en LVM, pueden existir muchos otros montajes del sistema como /home, /tmp, /usr, /var, /var/log y /opt.
Los sistemas de archivos adicionales creados para aplicaciones se encuentran en discos de datos, por ejemplo, /data, /datadisk o /sap. Configúrelos correctamente para que el sistema pueda arrancar aunque se produzca un error. Si un disco de datos es un dispositivo que arranca en modo de emergencia, consulte prevenir fallo de arranque.

Identificar el tipo de sistema de archivos

Mientras se realiza la identificación inicial, el único método para determinar el tipo de disco es utilizar el registro de serie como se examinó anteriormente en Identificar qué disco está dañado. Cuando se informa del dispositivo de disco en el registro de serie, se mostrarán los errores del módulo del kernel de Linux para el sistema de archivos. Observe cada línea en la que se especifique EXT4-fs o XFS. Para cualquier otro tipo de sistema de archivos, el registro se encuentra en la misma zona. El sistema de archivos anotado en las entradas del registro está determinado por el archivo /etc/fstab. Asegúrese de que el formato especificado es correcto cuando realice una reparación.

Una vez que tenga acceso a un shell interactivo, ejecute el comando lsblk con el indicador -f de la siguiente manera para mostrar los dispositivos, las rutas (si el sistema de archivos está montado) y el tipo de sistema de archivos que se lee del propio disco.

[root@localhost ~]# lsblk -f
NAME              FSTYPE      LABEL UUID                                   MOUNTPOINT
sda
|-sda1            vfat              93DA-8C20                              /boot/efi
|-sda2            xfs               d5da486e-fdfe-4ad8-bc01-aa72b91fd47d   /boot
|-sda3
`-sda4            LVM2_member       pdSI2Q-ZEzV-oT6P-R2JG-ZW3h-cmnf-iRN6pU
  |-rootvg-tmplv  xfs               9098eb05-0176-4997-8132-9152a7bef207   /tmp
  |-rootvg-usrlv  xfs               2f9ff36c-742d-4914-b463-d4152801b95d   /usr
  |-rootvg-optlv  xfs               aeacea8e-3663-4569-af25-c52357f8a0a3   /opt
  |-rootvg-homelv xfs               a79e43dc-7adc-41b4-b6e1-4e6b033b15c0
  |-rootvg-varlv  xfs               c7cb68e9-7865-4187-b3bd-e9a869779d86   /var
  `-rootvg-rootlv xfs               d8dc4d62-ada5-4952-a0d9-1bce6cb6f809   /
sdb
`-sdb1            ext4              1dac7c4c-bf8e-4964-8a59-7359eef53d0a   /mnt
sdc               LVM2_member       CRWEZQ-iLhH-ev0b-BAaA-dfLD-nbPT-GgtG0r
`-vgapp-lvapp     xfs               733e25ee-565f-4bfa-a2a1-2451efd25cd1
sdd
`-sdd1            ext4              704d9fb1-2207-4bb9-998c-029f776dc6d2   /opt/data

He aquí algunos puntos importantes del resultado:

Usando la pantalla de arte ASCII, puedes ver que hay volúmenes LVM presentes porque hay un LVM2_MEMBER FSTYPE para sda4 que contiene objetos con nombres como rootvg-rootlv y rootvg-homelv.
rootvg-homelv no está montado, lo que se denota por el campo MOUNTPOINT vacío.
rootvg-homelv tiene un sistema de archivos de tipo XFS. Es un contraste con el error de montaje EXT4 durante el arranque. Si el tipo de sistema de archivos es inconsistente, confíe en la salida lsblk en lugar de en el contenido de fstab.

Seleccione el modo de recuperación

Puede recuperar una máquina virtual en línea mediante el modo de emergencia o el modo de usuario único, o fuera de línea mediante una máquina virtual de rescate.

Requisitos para la recuperación en línea

La Consola Serial accede a la VM.
Si se utiliza el modo de emergencia, la consola serie debe mostrar un aviso de modo de emergencia, la cuenta root debe estar desbloqueada y se debe conocer la contraseña.
Si se utiliza el modo de usuario único, la contraseña de la raíz no es necesaria. El modo de usuario único puede utilizarse cuando un sistema de archivos distinto de las particiones del sistema necesarias, como raíz (/) o /usr, está dañado.

Requisitos para la recuperación offline

Si no se pueden cumplir los requisitos de la consola serie para la recuperación en línea, realice la recuperación fuera de línea utilizando una máquina virtual de rescate. Para realizar la recuperación sin conexión, se requiere la capacidad de crear una máquina virtual y gestionar discos en Azure. Como alternativa, puede utilizar una máquina virtual Linux en funcionamiento con acceso a nivel de Azure a los discos dañados.

Preparar el entorno para la recuperación en línea

Cuando aparezca el modo de emergencia en la pantalla de inicio de sesión, introduzca la contraseña de la raíz:

Welcome to emergency mode! After logging in, type "journalctl -xb" to view
system logs, "systemctl reboot" to reboot, "systemctl default" or ^D to
try again to Give root password for maintenance
(or press Control-D to continue):

Si no conoce la contraseña de la raíz, o la cuenta de la raíz está bloqueada, como en el siguiente resultado, utilice el modo de usuario único:

Welcome to emergency mode! After logging in, typ
Cannot open access to console, the root account is locked.
See sulogin(8) man page for more details.

Press Enter to continue.

Si el entorno de recuperación online es inutilizable, proceda a la recuperación offline.

Preparar el entorno para la recuperación offline

En las máquinas virtuales de un solo disco, o cuando el montaje que falla es una partición del sistema como el sistema de archivos raíz (/) o /usr, el método más fiable para reparar el disco es utilizar una máquina virtual de rescate para acceder al disco. Puede crear una máquina virtual de rescate automática o manualmente.

Para la creación automatizada de una VM de rescate, consulte Reparación de máquina virtual de Azure. Para la creación manual de una VM de rescate, consulte creación de una VM de recuperación. En cualquier caso, no monte los volúmenes del disco problemático porque un sistema de archivos no debe estar montado para que funcionen las utilidades de reparación.

Reparación del sistema de archivos

Antes de reparar el sistema de archivos, asegúrese de haber completado los siguientes pasos:

Se ha identificado el disco y la partición problemáticos, o la estructura de volumen LVM.
Se ha determinado el tipo de sistema de archivos.
(Opcional) Se ha adjuntado una copia del disco problemático, o de los discos de un grupo de volúmenes LVM extendido, a una máquina virtual de rescate.
El acceso a un intérprete de comandos interactivo se ha asegurado mediante el acceso al disco.

Para realizar la reparación del sistema de archivos, vaya a Reparar sistema de archivos ext4 o Reparar sistema de archivos XFS según el tipo de sistema de archivos.

Independientemente del modo de recuperación que se utilice, los comandos para realizar la reparación del sistema de archivos son los mismos. El caparazón de emergencia puede tener limitaciones. Si los comandos no están disponibles en un entorno de modo de emergencia, o hay errores sobre tipos de sistemas de archivos desconocidos, prepare el entorno para la recuperación sin conexión.

Es posible que los comandos para reparar el sistema de archivos no corrijan todos los errores. Funcionan cuando el disco está dañado, pero pueden producirse pérdidas de datos. Una vez que la salida del comando indique que el sistema de archivos está limpio, vuelva a montar la máquina virtual original con el disco reparado y arranque la máquina virtual para verificar los datos.

En las siguientes secciones, /dev/sdc1 es el sistema de archivos dañado en modo raw, y el LV homelv en el VG rootvg es el volumen LVM. Sustituya estos valores por el sistema de archivos dañado real en todos los casos.

Reparar el sistema de archivos ext4

Utilice el comando fsck [-y] FILESYSTEM para reparar un sistema de archivos ext4. Especifique el sistema de archivos como una partición de disco para un sistema de archivos raw, por ejemplo /dev/sdc1, o la ruta del volumen lógico LVM /dev/rootvg/homelv.

He aquí un ejemplo de salida de comandos:

[root@vm1dev ~]# fsck /dev/sdc1
fsck from util-linux 2.23.2
e2fsck 1.42.9 (28-Dec-2013)
ext2fs_check_desc: Corrupt group descriptor: bad block for block bitmap
fsck.ext4: Group descriptors look bad... trying backup blocks...
/dev/sdc1 was not cleanly unmounted, check forced.
Resize inode not valid.  Recreate<y>? yes
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Free blocks count wrong for group #0 (23508, counted=23509).
Fix<y>? yes
Free blocks count wrong (8211645, counted=8211646).
Fix<y>? yes

/dev/sdc1: ***** FILE SYSTEM WAS MODIFIED *****
/dev/sdc1: 11/2097152 files (0.0% non-contiguous), 176706/8388352 blocks
[root@vm1dev ~]#

La salida muestra que la confirmación para modificar el sistema de ficheros se solicita tres veces. Si hay muchas solicitudes, pulse CTRL C y reinicie fsck con la bandera -y para asumir "sí" a todas las preguntas. Si se informa de que algún archivo está colocado en lost+found, identifíquelo manualmente y colóquelo en la ubicación adecuada.

Si se producen algunos errores que posteriormente se solucionan, vuelva a ejecutar el comando fsck. Repita hasta que el comando fsck salga con el estado clean. Consulte la salida siguiente como ejemplo:

[root@vm1dev ~]# fsck /dev/sdc1
fsck from util-linux 2.23.2
e2fsck 1.42.9 (28-Dec-2013)
/dev/sdc1: clean, 11/2097152 files, 176706/8388352 blocks
[root@vm1dev ~]#

Reparación del sistema de archivos xfs

Estos son los comandos para reparar un sistema de archivos XFS:

xfs_repair [-n] FILESYSTEM
xfs_repair [-L] FILESYSTEM
mount FILESYSTEM MOUNTPOINT

Para reparar un sistema de archivos XFS, siga estos pasos:

Compruebe los errores del sistema de archivos mediante el comando xfs_repair -n, como se indica a continuación:
```
xfs_repair -n /dev/rootvg/homelv
```
Si la comprobación tiene éxito, continúe con el modo de reparación eliminando la bandera -n, que intentará solucionar los errores encontrados, como se indica a continuación:
```
xfs_repair /dev/rootvg/homelv
```

En los sistemas de archivos XFS, los cambios registrados pero no comprometidos se tratan montando el sistema de archivos. Si se encuentra con el siguiente error durante la resolución de problemas, intente un montaje y vea los resultados.

ERROR: El sistema de archivos tiene valiosos cambios de metadatos en un registro que necesita ser reproducido

Si se utiliza una máquina virtual de recuperación, cree un directorio para un punto de montaje temporal, como /recovery, y monte el sistema de archivos. Si el entorno de recuperación está en modo de emergencia o monousuario, monte el sistema de archivos en su ubicación prevista. Consulte los siguientes comandos a modo de ejemplo:

mount /dev/rootvg/homelv /recovery

mount /home

Si los cambios registrados en el diario no se escriben al montar los sistemas de archivos, utilice el indicador -L para descartar el diario y montar el sistema de archivos como si todos los cambios se hubieran completado correctamente. Cuando se utiliza el indicador -L, se producirá una pérdida de datos porque el registro muestra que se descartan las operaciones de archivo incompletas.

xfs_repair -L /dev/rootvg/homelv /recovery

Evitar fallos de arranque

Si se especifica la opción nofail al montar sistemas de archivos, es posible que la corrupción de un sistema de archivos no crítico no impida el arranque completo de Linux. Para obtener más información sobre nofail, consulte Montar el disco. La mayoría de los montajes aparte de la raíz (/), /usr y /var se pueden hacer con nofail.

Ponte en contacto con nosotros para obtener ayuda

Si tiene preguntas o necesita ayuda, cree una solicitud de soporte o busque consejo en la comunidad de Azure. También puede enviar comentarios sobre el producto con los comentarios de la comunidad de Azure.

Compartir a través de