Résoudre les problèmes de démarrage de la machine virtuelle Linux en raison d’erreurs de système de fichiers

Article
03/27/2024

Cet article fournit des conseils pour résoudre les problèmes de démarrage de machine virtuelle (VM) Linux causés par des erreurs de système de fichiers.

Symptômes

Vous ne pouvez pas vous connecter à une machine virtuelle (VM) Azure Linux à l’aide du protocole Secure Shell (SSH), ou l’état de l’agent VM dans le portail Azure n’est pas Prêt. Lorsque vous exécutez les diagnostics de démarrage dans le portail Azure ou que vous vous connectez à la console série, vous voyez des entrées de journal similaires aux exemples suivants :

Remarque

Tous les exemples ne seront pas présents.
Un échec de montage n’entraîne pas toujours le passage d’une machine virtuelle en mode d’urgence. Si le problème concerne certains systèmes de fichiers critiques, la machine virtuelle peut ne pas utiliser le mode d’urgence.

Exemple 1 : échec du montage du système de fichiers 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.

Exemple 2 : échec du montage du périphérique LVM (Logical Volume Manager) externe

[   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.

Exemple 3 : échec du montage du système de fichiers 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.

Exemple 4 : démarrer en mode d’urgence

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):

Cause

Les entrées de journal ci-dessus indiquent une corruption du disque. Dans certaines situations, la corruption du disque empêchera la machine virtuelle de démarrer complètement. Divers problèmes peuvent entraîner une corruption du disque, tels que des problèmes de noyau Linux, des erreurs de pilote, des erreurs dans le matériel physique ou virtuel sous-jacent, etc.

Résolution

Pour résoudre les problèmes de démarrage de la machine virtuelle Linux causés par des erreurs de système de fichiers, récupérez la machine virtuelle en réparant la corruption du disque. Pour réparer la défaillance du disque, procédez comme suit :

Identifiez quel disque est corrompu.
Identifiez le type de système de fichiers.
Sélectionnez le mode de récupération (en ligne ou hors ligne).
Préparez l’environnement de récupération en fonction du mode de récupération sélectionné :
- Préparer l’environnement pour la récupération en ligne
- Préparer l’environnement pour la récupération hors ligne
Utilisez des outils de ligne de commande pour réparer le système de fichiers problématique sur le disque.
- Réparer le système de fichiers ext4
- Réparer le système de fichiers xfs
Remarque
- Il est important de sauvegarder les données critiques car une perte de données peut se produire sur le disque récupéré.
- Avant d’apporter des modifications à un disque, prenez un instantané pour conserver l’état actuel du disque, même s’il est en état d’erreur. La réparation de la corruption du disque modifiera les données sur le disque, ce qui comportera des risques.

Identifier quel disque est corrompu

Pour déterminer quel disque est corrompu, téléchargez le journal série de votre machine virtuelle à l’aide de la console série ou des diagnostics de démarrage, examinez les entrées du journal lors du démarrage, puis recherchez l’erreur spécifique indiquant le disque ou le montage défaillant.

Voici trois exemples d’entrées de journal. Dans ces exemples, notez le texte entre parenthèses, qui signale le périphérique corrompu.

Dans l’exemple suivant, le périphérique défaillant est le suivant 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.

Dans l’exemple suivant, la partition où l’erreur de système de fichiers se produit est 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.

Dans l’exemple suivant, le périphérique défaillant est dm-2. C’est un périphérique Linux Device Mapper, qui indique un volume 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 le nom du périphérique de disque appelé est au format « sdXN », où X est une lettre de l’alphabet et N un numéro de partition facultatif, cela signifie que le disque est brut et peut être utilisé en utilisant le chemin /dev/sdXN.

Si le périphérique de disque en cours de montage utilise un nom tel que /dev/mapper/vgname/lvname, /dev/vgname/lvname ou dm-N, cela signifie qu’un périphérique LVM est utilisé. Veillez à reconnaître tous les volumes physiques de disque (PV) qui peuvent être utilisés.

Il n’est pas pris en charge que le groupe de volumes LVM (VG) contienne le disque du système d’exploitation et un nombre quelconque de disques de données. Dans un tel scénario, le risque de perte de données est élevé. Cependant, plusieurs disques de données sont autorisés dans un LVM VG.

Lors de la détermination du mappage des références de disque du système d’exploitation aux objets de disque Azure :

Pour les images du marché, le système de fichiers racine (/), /boot et /boot/efi se trouve sur le disque du système d’exploitation.
Pour les images basées sur LVM, de nombreux autres montages système peuvent exister, tels que /home, /tmp, /usr, /var, /var/log et /opt.
Les systèmes de fichiers supplémentaires créés pour les applications se trouvent sur des disques de données, par exemple, /data, /datadisk ou /sap. Configurez-les correctement afin que le système puisse démarrer même en cas d’erreur. Si un disque de données est un périphérique qui démarre en mode d’urgence, consultez prévenir l’échec du démarrage.

Identifier le type de système de fichiers

Lors de l’identification initiale, la seule méthode pour déterminer le type de disque consiste à utiliser le journal série tel qu’examiné précédemment dans Identifier quel disque est corrompu. Lorsque le périphérique de disque est signalé dans le journal série, les erreurs seront affichées à partir du module du noyau Linux pour le système de fichiers. Notez chaque ligne où EXT4-fs ou XFS est spécifié. Pour tous les autres types de système de fichiers, le journal se trouve dans la même zone. Le système de fichiers noté dans les entrées du journal est déterminé par le fichier /etc/fstab. Veillez à vérifier que le format spécifié est correct lorsque vous effectuez une réparation.

Une fois que vous avez accès à un shell interactif, exécutez la commande lsblk avec l’indicateur -f comme suit pour afficher les périphériques, les chemins (si le système de fichiers est monté) et le type de système de fichiers lu à partir du disque lui-même.

[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

Voici quelques points importants dans la sortie :

En utilisant l’affichage d’art ASCII, vous pouvez voir qu’il y a des volumes LVM présents car il y a un LVM2_MEMBER FSTYPE pour sda4 contenant des objets avec des noms tels que rootvg-rootlv et rootvg-homelv.
rootvg-homelv n’est pas monté, ce qui est indiqué par le champ MOUNTPOINT vide.
rootvg-homelv a le type de système de fichiers XFS. C’est un contraste avec l’erreur de montage EXT4 lors du démarrage. Si le type de système de fichiers est incohérent, faites confiance à la sortie lsblk plutôt qu’au contenu de fstab.

Sélectionner le mode de récupération

Vous pouvez récupérer une machine virtuelle en ligne via le mode d’urgence ou le mode mono-utilisateur ou hors ligne à l’aide d’une machine virtuelle de secours.

Exigences pour la récupération en ligne

L’accès console série à la VM.
Si le mode d’urgence est utilisé, la console série doit afficher une invite de mode d’urgence, le compte root doit être déverrouillé et le mot de passe doit être connu.
Si le mode mono-utilisateur est utilisé, le mot de passe root n’est pas nécessaire. Le mode mono-utilisateur peut être utilisé lorsqu’un système de fichiers autre que les partitions système requises telles que la racine (/) ou /usr est corrompu.

Conditions requises pour la récupération hors ligne

Si les exigences de la console série pour la récupération en ligne ne peuvent pas être satisfaites, effectuez une récupération hors ligne à l’aide d’une machine virtuelle de secours. Pour effectuer une récupération hors ligne, la possibilité de créer une machine virtuelle et de gérer des disques dans Azure est requise. Vous pouvez également utiliser une machine virtuelle Linux fonctionnelle avec un accès de niveau Azure aux disques corrompus.

Préparer l’environnement pour la récupération en ligne

Lorsque le mode d’urgence s’affiche dans l’invite de connexion comme suit, saisissez le mot de passe racine :

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 le mot de passe racine n’est pas connu ou si le compte racine est verrouillé, comme dans le résultat suivant, utilisez le mode mono-utilisateur :

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 l’environnement de récupération en ligne est inutilisable, passez à la récupération hors ligne.

Préparer l’environnement pour la récupération hors ligne

Dans les machines virtuelles à disque unique, ou lorsque le montage défaillant est une partition système telle que le système de fichiers racine (/) ou /usr, la méthode la plus fiable pour réparer le disque consiste à utiliser une machine virtuelle de secours pour accéder au disque. Vous pouvez créer une machine virtuelle de secours automatiquement ou manuellement.

Pour la création automatisée d’une machine virtuelle de secours, consultez Réparation de machine virtuelle Azure. Pour la création manuelle d’une VM de secours, voir Création d’une VM de secours. Dans les deux cas, ne montez pas les volumes à partir du disque problématique car un système de fichiers ne doit pas être monté pour que les utilitaires de réparation fonctionnent.

Effectuer la réparation du système de fichiers

Avant de réparer le système de fichiers, assurez-vous que les étapes suivantes ont été effectuées :

Le disque et la partition problématiques, ou la structure de volume LVM, ont été identifiés.
Le type de système de fichiers a été déterminé.
(Facultatif) Une copie du disque problématique, ou des disques d’un groupe de volumes LVM fractionné, a été attachée à une machine virtuelle de secours.
L’accès à un shell interactif a été sécurisé en utilisant l’accès au disque.

Pour effectuer la réparation du système de fichiers, allez dans Réparer le système de fichiers ext4 ou Réparer le système de fichiers XFS selon le type de système de fichiers.

Quel que soit le mode de récupération utilisé, les commandes pour effectuer la réparation du système de fichiers sont les mêmes. Le shell d’urgence peut avoir des limites. Si les commandes ne sont pas disponibles dans un environnement en mode d’urgence, ou s’il y a des erreurs concernant des types de systèmes de fichiers inconnus, préparez l’environnement pour la récupération hors ligne.

Les commandes de réparation du système de fichiers peuvent ne pas corriger toutes les erreurs. Ils contournent les corruptions de disque, mais une perte de données peut toujours se produire. Une fois que la sortie de la commande indique que le système de fichiers est propre, réassemblez la machine virtuelle d’origine avec le disque réparé et démarrez la machine virtuelle pour vérifier les données.

Dans les sections suivantes,/dev/sdc1 est le système de fichiers endommagé en mode brut, et le LV homelv dans le VG rootvg est le volume LVM. Remplacez ces valeurs par le système de fichiers corrompu réel dans toutes les instances.

Réparer le système de fichiers ext4

Utilisez la commande fsck [-y] FILESYSTEM pour réparer un système de fichiers ext4. Spécifiez le système de fichiers en tant que partition de disque pour un système de fichiers brut, par exemple /dev/sdc1, ou le chemin du volume logique LVM/dev/rootvg/homelv.

Voici un exemple de sortie de commande :

[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 sortie montre que la confirmation de modification du système de fichiers est demandée trois fois. S’il y a de nombreuses demandes, appuyez sur CTRL + C et redémarrez fsck avec l’indicateur -y pour répondre par « oui » à toutes les questions. Si des fichiers sont signalés comme étant placés dans lost+found, identifiez-les manuellement et placez-les aux emplacements appropriés.

Si des erreurs se produisent et sont corrigées par la suite, exécutez à nouveau la commande fsck. Répétez jusqu’à ce que la commande fsck se termine avec le statut clean. Consultez l’exemple de sortie suivant :

[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 ~]#

Réparer le système de fichiers xfs

Voici les commandes pour réparer un système de fichiers XFS :

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

Pour réparer le système de fichiers XFS, procédez comme suit :

Vérifiez les erreurs du système de fichiers à l’aide de la commande xfs_repair -n, comme illustré ci-dessous :
```
xfs_repair -n /dev/rootvg/homelv
```
Si la vérification réussit, continuez en mode de réparation et supprimez l’indicateur -n pour essayer de corriger les erreurs rencontrées. Pour ce faire, procédez comme suit :
```
xfs_repair /dev/rootvg/homelv
```

Pour les systèmes de fichiers XFS, les modifications journalisées mais non validées sont traitées en montant le système de fichiers. Si vous rencontrez l’erreur suivante lors du dépannage, essayez un montage et affichez les résultats.

ERREUR : Le système de fichiers contient des modifications de métadonnées importantes dans un journal qui doit être rejoué

Si une machine virtuelle de récupération est utilisée, créez un répertoire comme point de montage temporaire, comme /recovery et montez le système de fichiers. Si l’environnement de récupération est en mode d’urgence ou mono-utilisateur, montez le système de fichiers à l’emplacement prévu. Consultez les commandes suivantes à titre d’exemple :

mount /dev/rootvg/homelv /recovery

mount /home

Si les modifications journalisées ne sont pas écrites lorsque vous montez les systèmes de fichiers, utilisez l’indicateur -L pour supprimer le journal et monter le système de fichiers comme si toutes les modifications avaient été effectuées avec succès. Lorsque l’indicateur -L est utilisé, une perte de données se produit car le journal indique que les opérations de fichier incomplètes sont ignorées.

xfs_repair -L /dev/rootvg/homelv /recovery

Empêcher l’échec du démarrage

Si l’option nofail est spécifiée lors du montage des systèmes de fichiers, la défaillance d’un système de fichiers non critique peut ne pas empêcher Linux de démarrer complètement. Pour plus dʼinformations sur nofail, consultez l’article Monter le disque. La plupart des montages à part la racine (/),/usr et /var peuvent être effectués avec nofail.

Contactez-nous pour obtenir de l’aide

Pour toute demande ou assistance, créez une demande de support ou posez une question au support de la communauté Azure. Vous pouvez également soumettre des commentaires sur les produits à la communauté de commentaires Azure.