Résolution des échecs d'initialisation après la modification de forme sur les instances OCI Linux
Introduction
Ce tutoriel vous explique comment résoudre les échecs d'initialisation sur les images Oracle Cloud Infrastructure (OCI) personnalisées, qui peuvent survenir après un changement de forme ou même un simple redémarrage en raison de modifications apportées aux mappings d'appareil sous-jacents.
Avant de plonger dans la solution, comprenons d'abord ce qu'est une image personnalisée.
Une image personnalisée dans OCI est un cliché du volume d'initialisation d'une instance qui capture la configuration du système d'exploitation, le logiciel installé et les paramètres d'environnement. Les images personnalisées sont couramment utilisées pour répliquer des environnements préconfigurés dans plusieurs instances ou régions, ce qui garantit la cohérence à grande échelle.
Toutefois, ces images peuvent présenter des risques, en particulier si elles sont étroitement liées au matériel d'origine de l'instance. S'il n'est pas conçu pour la portabilité, des problèmes peuvent survenir lors du changement de forme (par exemple, le passage d'une instance VM.Standard3 à une instance VM.Standard4), car les modifications matérielles sous-jacentes peuvent affecter la façon dont les périphériques sont mis en correspondance.
Ce blog décrit un scénario d'échec d'initialisation réel rencontré par un client à l'aide d'une image Rocky Linux d'Oracle Cloud Marketplace. Bien que cet exemple soit spécifique à Rocky Linux, la cause première et la résolution s'appliquent largement à toute image personnalisée basée sur Linux qui utilise des noms de périphériques statiques dans sa configuration.
Objectifs
Ce guide aide les utilisateurs OCI à identifier et à résoudre les échecs d'initialisation sur les images Linux personnalisées causés par les modifications de forme ou les réinitialisations, en corrigeant les configurations de montage et en améliorant la portabilité des images.
Prérequis
- Accès à une location OCI avec le compte d'administrateur initial
- Accès à Cloud Shell
- Connaissance de base de la ligne de commande UNIX
- Accès à la console série pour l'instance
Tâche 1 : comprendre le problème
- Découvrez comment les changements de forme OCI affectent la dénomination du matériel et des appareils sous-jacents.
- Reconnaissez que les noms de périphériques statiques dans
/etc/fstab(par exemple,/dev/sdX) peuvent devenir non valides après un changement de forme ou même après un redémarrage.- Lorsque la forme change, le système d'exploitation peut attribuer de nouveaux noms aux volumes de blocs attachés. Par exemple, un disque qui était
/dev/sdbpeut maintenant apparaître comme/dev/sdc. - Si
/etc/fstabs'appuie sur ces noms statiques, le montage des volumes peut échouer à l'initialisation. - Pour éviter cette situation, utilisez des identificateurs persistants tels que les chemins
UUIDou/dev/disk/by-uuid/du volume dans/etc/fstab.
- Lorsque la forme change, le système d'exploitation peut attribuer de nouveaux noms aux volumes de blocs attachés. Par exemple, un disque qui était
Tâche 2 : Identifier les symptômes et les erreurs
-
Recherchez les erreurs suivantes dans la console série ou les journaux système (
journalctl -xb) :Welcome to emergency mode! After logging in, type “journalctl -xb”...Failed to mount /mnt/data: No such deviceDuplicate mount point /mnt/data detectedCannot mount /dev/sdX: No such file or directorysystemd[1]: Failed to mount /mnt/data.systemd[1]: Dependency failed for Local File Systems.systemd[1]: Job local-fs.target/start failed with result ‘dependency’.
Tâche 3 : initialisation en mode secours/urgence
- Accédez à la console série de l'instance.
- Démarrez en mode de secours ou d'urgence pour effectuer des diagnostics et des actions correctives.
Tâche 4 : identifier les noms de périphérique corrects
- Exécutez les commandes
blkidoulsblkpour répertorier les unités de blocs en cours et leurs UUID.
Tâche 5 : montage manuel du volume d'initialisation
-
Montez le volume d'initialisation à l'aide du nom de périphérique correct :
mount /dev/sdXn /mntchroot /mnt
Tâche 6 : modifier /etc/fstab
-
Ouvrez
/etc/fstabà l'aide d'un éditeur (par exemple,vi /etc/fstab).- Remplacez toutes les entrées
/dev/sdXpar les valeurs d'UUID persistant correspondantes trouvées dansblkid. - Supprimez les entrées de montage en double. Remarque : il s'agit d'un correctif ponctuel une fois que les identificateurs persistants sont utilisés, les modifications de forme futures ne doivent pas entraîner ce problème.
- Remplacez toutes les entrées
Tâche 7 : quitter et réinitialiser
- Quittez l'environnement chroot :
exit. - Démontez des volumes si nécessaire.
- Redémarrez l'instance.
Conseils de prévention pour éviter les échecs d'initialisation après les modifications de forme OCI
- Utiliser des identificateurs persistants : indiquez toujours les disques dans
/etc/fstabà l'aide deUUID=ouLABEL=au lieu de noms de périphériques tels que/dev/sdX. Cela garantit la cohérence des points de montage malgré les modifications matérielles. - Effectuer des audits blkid : exécutez
blkidavant et après une modification de forme pour vérifier que les mappages de périphérique à UUID restent corrects. - Sauvegarde avant modifications : sauvegardez toujours l'instance ou le volume d'initialisation avant toute modification de forme afin d'activer la récupération en cas de problème.
- Tester les modifications de forme en dehors de la production : en particulier lorsque vous utilisez une place de marché ou des images personnalisées qui peuvent comporter des montages codés en dur, testez d'abord les modifications de forme dans un environnement hors production.
Conclusion
Bien que ce problème ait été observé sur Rocky Linux, il peut potentiellement affecter toute image personnalisée basée sur Linux si les meilleures pratiques en matière de montage sur disque ne sont pas respectées. La bonne nouvelle est qu'il s'agit d'une correction unique. Une fois que /etc/fstab est mis à jour pour utiliser des identificateurs persistants tels que des UUID ou des LABEL, les modifications de forme OCI futures ou même les réinitialisations ne doivent pas entraîner d'échec d'initialisation. La validation proactive de votre configuration garantit des transitions fluides et fiables entre les formes.
Liens connexes
Accusés de réception
- Auteurs : Payal Sharma (architecte principal du cloud résident), Rajendra Singh Raghuwanshi (ingénieur technique principal Linux)
Ressources de formation supplémentaires
Explorez d'autres ateliers sur le site docs.oracle.com/learn ou accédez à d'autres contenus d'apprentissage gratuits sur le canal Oracle Learning YouTube. En outre, visitez le site education.oracle.com/learning-explorer pour devenir un explorateur Oracle Learning.
Pour obtenir de la documentation sur le produit, consultez Oracle Help Center.
Resolve Boot Failures After Shape Change on OCI Linux Instances
G42945-01