For the complete documentation index, see llms.txt. This page is also available as Markdown.

Échec du démarrage des VM de la famille RHEL 9 après clonage ou restauration d’un snapshot

Comment corriger les échecs de démarrage dans les VM de la famille RHEL 9 (AlmaLinux, Rocky, CentOS Stream) après clonage ou restauration d’un snapshot dans VergeOS, causés par le fichier LVM system.devices qui épingle les numéros de série des disques d’origine.

Ce guide couvre un échec de démarrage spécifique : une VM de la famille RHEL 9 (RHEL, AlmaLinux 9, Rocky Linux 9 ou CentOS Stream 9) qui démarre correctement sur l’hôte source, puis échoue sur l’instance clonée ou restaurée à partir d’un instantané, car le fichier system.devices de LVM ne correspond plus aux numéros de série de disque de la VM. Les étapes ci-dessous réparent la VM depuis le mode de secours. si vous n’avez pas encore effectué le clonage ou la restauration, voir la note «Empêcher cela sur les futurs clones, instantanés ou exportations » plus loin.

Symptômes

  • Après la restauration d’une VM depuis un instantané, ou le clonage d’une VM, la VM RHEL 9 ne parvient pas à démarrer (elle bascule en mode d’urgence ou se bloque au démarrage)

  • En mode de secours, vgchange -ay n’affiche rien et lvdisplay n’affiche rien

Vue d’ensemble

RHEL 9 et ses dérivés (AlmaLinux 9, Rocky Linux 9, CentOS Stream 9) utilisent un fichier de périphériques LVM à /etc/lvm/devices/system.devices qui met explicitement en liste blanche les périphériques de bloc selon leurs identifiants uniques — notamment les numéros de série de disque. Au démarrage, LVM ne prend en compte que les périphériques listés dans ce fichier lors de l’assemblage des groupes de volumes. Si les numéros de série qu’il voit ne correspondent pas à ceux enregistrés lors de la création du fichier, LVM n’activera pas le groupe de volumes racine et la VM basculera dans un shell d’urgence dracut.

Cela signifie que toute opération qui donne à une VM de nouveaux numéros de série de disque — le clonage d’une VM avec génération de nouveaux numéros de série matériels, ou la restauration d’un instantané d’une manière qui modifie les numéros de série — fera échouer le démarrage.

VergeOS 26.1.5 et versions ultérieures

À partir de VergeOS 26.1.5, les clones de VM et les restaurations d’instantanés conservent par défaut les numéros de série d’origine des disques, éliminant ainsi la discordance des numéros de série pour la plupart des opérations de clonage et de restauration. Ce problème affecte le plus souvent :

  • Les clones ou restaurations où l’option de générer de nouveaux numéros de série matériels a été explicitement sélectionnée

  • Les environnements exécutant des versions de VergeOS antérieures à 26.1.5

Importations depuis un autre hyperviseur

Le même échec de démarrage peut se produire lors de l’importation d’une VM depuis un autre hyperviseur si la VM a été exportée sans conserver ses numéros de série de périphériques d’origine. De plus, les VM importées peuvent ne pas démarrer en raison de l’absence de pilotes virtio pour le matériel VergeOS. Voir Guide d’importation d’une VM Linux pour des instructions incluant l’ajustement de la configuration de la VM et la régénération de l’initramfs avec les pilotes virtio.

Empêcher cela sur les futurs clones, instantanés ou exportations

Si vous avez encore accès à une VM source fonctionnelle, vous pouvez éviter l’échec de démarrage sur les futurs clones, instantanés ou exportations depuis un autre hyperviseur en désactivant le fichier de périphériques LVM avant pour l’opération. Définissez use_devicesfile = 0 dans /etc/lvm/lvm.conf sur le système invité. LVM reviendra à l’analyse de tous les périphériques de bloc disponibles, quel que soit leur numéro de série. Le fichier de périphériques LVM a été conçu principalement pour les hôtes connectés à une infrastructure SAN, où une seule machine peut voir de nombreux périphériques de bloc qui ne lui appartiennent pas ; dans un environnement VergeOS typique, une VM ne voit que les disques virtuels qui lui sont explicitement attribués, donc la protection qu’il offre est rarement nécessaire. Voir le guide Red Hat Limiter la visibilité et l’utilisation des périphériques LVM pour en savoir plus sur le fichier de périphériques.

Prérequis

  • Accès à l’interface utilisateur VergeOS et à la console de la VM

  • Une image ISO d’installation de la famille RHEL 9 disponible dans les médias VergeOS (requis uniquement si la VM ne peut pas atteindre le menu GRUB)

Étapes

1. Démarrer dans un environnement de secours

La VM échouera probablement à démarrer normalement. Utilisez l’une des méthodes suivantes pour obtenir un shell fonctionnel.

Option A — Noyau de secours GRUB (recommandé)

  • Démarrez la VM et ouvrez la console dans VergeOS.

  • Pendant le démarrage, appuyez et maintenez Shift (BIOS) ou Esc (UEFI) pour accéder au menu GRUB.

  • Sélectionnez Options avancées et choisissez l’entrée de noyau de secours .

  • Suivez les invites — si l’on vous demande de monter le système de fichiers racine, sélectionnez Continuer.

Option B — Démarrer à partir de l’ISO d’installation

Si le menu GRUB est inaccessible ou si la VM n’atteint pas ce point :

  • Dans VergeOS, attachez à la VM une ISO d’installation de la famille RHEL 9 en tant que lecteur CD/DVD.

  • Ajustez l’ordre de démarrage de la VM pour démarrer d’abord sur l’ISO, ou utilisez une option de démarrage unique.

  • Dans le menu de l’installateur, accédez à Dépannage → Secourir un système [distro].

  • Lorsque vous êtes invité à monter le système installé, choisissez l’option 1 (monter sous /mnt/sysimage).

  • Sélectionnez Shell pour ouvrir une invite de commande.

2. Vérifier que le disque est visible, le rescanner et vérifier les groupes de volumes

  • Afficher les périphériques de bloc :

    lsblk

    Notez le nom du périphérique (par ex., /dev/sda) et la partition LVM (par ex., /dev/sda3)

  • Forcer LVM à rescanner tous les périphériques de bloc (contourne le fichier de périphériques) :

    pvscan --cache vgchange -ay

  • Si le rescannage n’affiche toujours rien, enregistrez explicitement la partition LVM :

    lvmdevices --adddev /dev/sda3 Remplacez par votre partition LVM réelle obtenue avec lsblk vgchange -ay

  • Vérifier que les groupes de volumes sont maintenant visibles

    lvdisplay

3. Monter la partition racine et lier les systèmes de fichiers

  • mount /dev/<nom_périphérique> /mnt Remplacez <nom_périphérique> par votre partition racine (par ex., sda2, mapper/vg0-root).

  • Vérifiez le montage :

    ls /mnt

    Vous devriez voir des répertoires comme /root, /boot, /home, /etc et /var.

  • Lier les systèmes de fichiers :

    Utilisez la boucle for suivante pour lier les systèmes de fichiers virtuels nécessaires :

    for i in proc sys dev run; do mount --rbind /$i /mnt/$i; done

    OU montez-les individuellement :

    mount --rbind /proc /mnt/proc mount --rbind /sys /mnt/sys mount --rbind /dev /mnt/dev mount --rbind /run /mnt/run

    Pour les systèmes EFI/UEFI, montez également la partition EFI :

    Remplacez /dev/sdX1 par votre partition EFI réelle (vérifiez avec lsblk ou fdisk -l).

4. Chrooter dans le système installé et monter les systèmes de fichiers supplémentaires

  • Changer le répertoire racine

    chroot /mnt

  • Après être entré dans le chroot, montez toutes les partitions supplémentaires définies dans fstab :

    mount -a

5. Régénérer l’initramfs

  • Reconstruire l’initramfs afin qu’il prenne en compte la configuration de périphériques nettoyée :

    dracut -f --regenerate-all

6. Redémarrer et vérifier

  • Quitter l’environnement chroot :

    exit

  • Redémarrer la VM :

    reboot

  • **Vérifier le démarrage :**Confirmez que la VM démarre correctement et que tous les disques apparaissent comme prévu.

Dépannage

Ressources supplémentaires

Besoin d’aide ?

Si vous continuez à rencontrer des problèmes de démarrage après avoir suivi ce guide, contactez le support VergeOS pour obtenir de l’aide.

Mis à jour

Ce contenu vous a-t-il été utile ?