Résoudre les problèmes de démarrage des machines virtuelles Linux en raison d’erreurs de système de fichiers

S’applique à : ✔️ Machines virtuelles Linux

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

Symptômes

Vous ne pouvez pas vous connecter à une machine virtuelle Linux Azure à l’aide du protocole SSH (Secure Shell Protocol) ou de l’état de l’agent de machine virtuelle 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 qui ressemblent aux exemples suivants :

Note

• Tous les exemples ne seront pas présents.
• Une défaillance de montage n’entraîne pas toujours l’entrée 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 de l’appareil LVM (Logical Volume Manager)

[   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 du journal ci-dessus indiquent l’altération du disque. Dans certaines situations, l’altération du disque empêche le démarrage complet de la machine virtuelle. Différents problèmes peuvent entraîner une altération du disque, comme 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 machine virtuelle Linux causés par des erreurs de système de fichiers, récupérez la machine virtuelle en réparant l’altération du disque. Pour réparer l’altération du disque, procédez comme suit :

1. Identifiez le disque endommagé.

2. Identifiez le type de système de fichiers.

3. Sélectionnez le mode de récupération (en ligne ou hors connexion).

4. Préparez l’environnement de récupération en fonction du mode de récupération que vous sélectionnez :

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

5. Utilisez des outils en 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

   Note

   • Il est important de sauvegarder des données critiques, car la 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 dans un état d’erreur. La correction de l’altération du disque modifie les données sur le disque, ce qui risque.

Identifier le disque endommagé

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

Voici trois exemples d’entrée de journal. Dans ces exemples, notez le texte entre parenthèses, qui signale l’appareil endommagé.

Dans l’exemple suivant, l’appareil endommagé est 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ù une 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, l’appareil endommagé est dm-2. Il s’agit d’un appareil 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 l’appareil de disque appelé utilise un nom du format « sdXN » où X est une lettre d’a-z et N est un numéro de partition facultatif, cela signifie que le disque est brut et peut être utilisé à l’aide du chemin /dev/sdXN .

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

Il n’est pas pris en charge pour le groupe de volumes LVM (VG) pour contenir le disque du système d’exploitation et n’importe quel nombre de disques de données. Pour un tel scénario, il existe un risque élevé de perte de données. Toutefois, plusieurs disques de données sont autorisés dans un groupe de machines virtuelles LVM.

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

• Pour les images de la Place de 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 comme /home, /tmp, /usr, /var, /var/log et /opt.
• Des 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 pour que le système puisse démarrer même en cas d’erreur. Si un disque de données est un appareil qui démarre en mode d’urgence, consultez Empêcher l’échec du démarrage.

Identifier le type de système de fichiers

Lors de l’identification initiale, la seule méthode permettant de déterminer le type de disque utilise le journal série comme précédemment examiné dans Identifier quel disque est endommagé. Lorsque l’appareil disque est signalé dans le journal série, les erreurs s’affichent à partir du module de noyau Linux pour le système de fichiers. Notez chaque ligne où EXT4-fs ou XFS est spécifiée. 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 lors de l’exécution d’une réparation.

Une fois que vous avez accès à un interpréteur de commandes interactif, exécutez la lsblk commande avec l’indicateur -f comme suit pour afficher les appareils, 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 existe des volumes LVM présents, car il existe 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. Il s’agit d’un contraste avec l’erreur de montage EXT4 lors du démarrage. Si le type de système de fichiers est incohérent, approuvez la lsblk sortie plutôt que le 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 connexion à l’aide d’une machine virtuelle de secours.

Configuration requise pour la récupération en ligne

• La console série accède à la machine virtuelle.

• Si le mode d’urgence est utilisé, la console série doit afficher une invite de mode d’urgence, le compte racine doit être déverrouillé et le mot de passe doit être connu.

• Si le mode mono-utilisateur est utilisé, le mot de passe racine 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 endommagée.

Configuration requise pour la récupération hors connexion

Si la configuration requise pour la console série pour la récupération en ligne ne peut pas être remplie, effectuez une récupération hors connexion à l’aide d’une machine virtuelle de secours. Pour effectuer une récupération hors connexion, 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 au niveau Azure aux disques endommagés.

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, entrez 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 la sortie suivante, 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 n’est pas utilisable, passez à la récupération hors connexion.

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

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 La réparation des machines virtuelles Azure. Pour la création manuelle d’une machine virtuelle de secours, consultez la création d’une machine virtuelle de récupération. Dans les deux cas, ne montez pas les volumes à partir du disque de problème, 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, vérifiez que les étapes suivantes ont été effectuées :

• Le disque et la partition problématiques, ou 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 réparti a été attachée à une machine virtuelle de secours.
• L’accès à un interpréteur de commandes interactif a été sécurisé à l’aide de l’accès au disque.

Pour effectuer la réparation du système de fichiers, accédez à Réparer le système de fichiers ext4 ou Réparer le système de fichiers XFS en fonction du type de système de fichiers.

Quel que soit le mode de récupération utilisé, les commandes permettant d’effectuer la réparation du système de fichiers sont identiques. L’interpréteur de commandes d’urgence peut avoir des limitations. Si les commandes ne sont pas disponibles dans un environnement en mode urgence ou qu’il existe des erreurs sur les types de système de fichiers inconnus, préparez l’environnement pour la récupération hors connexion.

Les commandes permettant de réparer le système de fichiers peuvent ne pas corriger toutes les erreurs. Ils fonctionnent autour des altérations de disque, mais la perte de données peut toujours se produire. Une fois que la sortie de 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 il s’agit du 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 endommagé réel dans toutes les instances.

Réparer le système de fichiers ext4

Utilisez la fsck [-y] FILESYSTEM commande 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 /dev/rootvg/homelvdu volume logique LVM.

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

Si certaines erreurs se produisent et sont par la suite corrigées, réexécutez la fsck commande. Répétez jusqu’à ce que la fsck commande se termine avec l’état clean . Reportez-vous à la sortie suivante à titre d’exemple :

[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 des commandes pour réparer un système de fichiers XFS :

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

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

1. Vérifiez les erreurs du système de fichiers à l’aide de la xfs_repair -n commande, comme suit :

   xfs_repair -n /dev/rootvg/homelv
   

2. Si la vérification réussit, poursuivez avec le mode de réparation en supprimant l’indicateur -n , ce qui tentera de résoudre les erreurs rencontrées, 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 de la résolution des problèmes, essayez un montage et affichez les résultats.

ERREUR : Le système de fichiers a des modifications de métadonnées précieuses dans un journal qui doit être relu

Si une machine virtuelle de récupération est utilisée, créez un répertoire pour un point de montage temporaire, par /recoveryexemple, 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 sur son emplacement prévu. Reportez-vous aux commandes suivantes comme exemples :

mount /dev/rootvg/homelv /recovery

or

mount /home

Si les modifications journalisé ne sont pas écrites lorsque vous montez des systèmes de fichiers, utilisez l’indicateur -L pour ignorer le journal et monter le système de fichiers comme si toutes les modifications sont correctement effectuées. Lorsque l’indicateur est utilisé, la -L perte de données se produit, car le journal affiche des opérations de fichier incomplètes sont ignorées.

xfs_repair -L /dev/rootvg/homelv /recovery

Empêcher l’échec de démarrage

Si l’option nofail est spécifiée lors du montage de systèmes de fichiers, l’altération d’un système de fichiers non critique peut ne pas empêcher Linux de démarrer entièrement. Pour plus d’informations sur nofail, consultez Monter le disque. La plupart des montages en dehors de la racine (/), /usret /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.