Ce document vous aide à identifier les raisons pour lesquelles votre instance Linux Compute Engine ne démarre pas et à résoudre les problèmes courants.
Une instance de calcul qui ne parvient pas à démarrer présente généralement un ou plusieurs des symptômes suivants :
- L'instance de calcul est à l'état
RUNNING, mais vous ne pouvez pas vous y connecter à l'aide de SSH. - La sortie de la console série s'arrête en cours de séquence de démarrage ou se termine par une invite d'urgence ou de récupération.
- La sortie de la console série contient
FAILED,error:,Kernel panicouemergency mode.
Pour résoudre un problème de démarrage, commencez par identifier la cause, puis corrigez-la depuis l'instance de calcul si vous pouvez toujours vous y connecter, ou hors connexion en associant le disque de démarrage à une autre instance de calcul.
Si l'instance de calcul termine le démarrage, mais que vous ne parvenez pas à vous y connecter, consultez Résoudre les erreurs liées à SSH.
Avant de commencer
- Assurez-vous que l'instance de calcul écrit la sortie de la console série. La sortie du port série est disponible pendant l'exécution de l'instance de calcul. Pour la conserver après l'arrêt de l'instance de calcul, activez la journalisation du port série sur Cloud Logging. Pour en savoir plus, consultez Afficher les données en sortie du port série.
-
Si ce n'est pas déjà fait, configurez l'authentification.
L'authentification permet de valider votre identité pour accéder aux services et aux API Google Cloud . Pour exécuter du code ou des exemples depuis un environnement de développement local, vous pouvez vous authentifier auprès de Compute Engine en sélectionnant l'une des options suivantes :
-
Installez la Google Cloud CLI, puis connectez-vous à la gcloud CLI avec votre identité fédérée. Après vous être connecté, initialisez la Google Cloud CLI en exécutant la commande suivante :
gcloud init - Définissez une région et une zone par défaut.
-
Détecter automatiquement la cause
Avant de lire manuellement la sortie de la console série, utilisez l'un des outils suivants. Chacun d'eux lit la sortie du démarrage le plus récent de l'instance de calcul, signale la cause la plus probable et renvoie à la section correspondante de ce document.
Console
Dans la console Google Cloud , accédez à la page Instances de VM.
Sur la ligne de l'instance de calcul, cliquez sur SSH.
Si la connexion échoue, cliquez sur Dépanner dans la boîte de dialogue de connexion. L'outil de dépannage exécute des vérifications de connectivité, y compris une vérification du démarrage qui analyse la sortie de la console série.
gcloud
Pour vérifier une instance de calcul à laquelle vous ne pouvez pas vous connecter à l'aide de SSH, exécutez l'outil de dépannage SSH de la gcloud CLI, qui effectue des vérifications de connectivité et de démarrage :
gcloud compute ssh INSTANCE_NAME --zone=ZONE --troubleshoot
Pour vérifier directement la séquence de démarrage, exécutez la commande de diagnostic de démarrage :
Pour utiliser cette commande, assurez-vous d'avoir installé le composant de commandes alpha.
gcloud alpha compute diagnose boot INSTANCE_NAME --zone=ZONE
Remplacez les éléments suivants :
INSTANCE_NAME: nom de l'instance de calcul.ZONE: zone dans laquelle se trouve l'instance de calcul.
Si un problème de démarrage est détecté, la sortie en indique la cause et fournit un lien vers la solution. Si aucun problème n'est détecté, passez aux étapes manuelles.
Lire la sortie de la console série
Si les outils ne détectent aucun problème ou si vous souhaitez confirmer la cause, lisez vous-même la sortie de la console série :
Console
Dans la console Google Cloud , accédez à la page Instances de VM.
Sélectionnez l'instance de calcul pour laquelle vous souhaitez afficher la sortie du port série.
Dans la section Journaux, cliquez sur Port série 1 (console).
gcloud
gcloud compute instances get-serial-port-output INSTANCE_NAME --zone=ZONE
Remplacez les éléments suivants :
INSTANCE_NAME: nom de l'instance de calcul.ZONE: zone dans laquelle se trouve l'instance de calcul.
Accédez au dernier démarrage. Les lignes utiles se trouvent généralement juste avant la première ligne [FAILED], la ligne Kernel panic ou l'invite d'urgence. Comparez ce que vous trouvez avec les signatures des sections suivantes.
Problèmes de démarrage courants
Les sections suivantes listent les échecs de démarrage courants sur les instances de calcul Linux, les signatures de sortie de leur console série et la manière de les résoudre. La plupart des solutions nécessitent que vous associiez le disque de démarrage à une VM de dépannage, comme décrit dans Corriger le disque hors connexion.
Impossible de monter l'entrée de fichier /etc/fstab
Symptôme : la sortie de la console série contient des lignes semblables à celles-ci, suivies de You are in emergency mode :
UUID=1234abcd-... does not exist
Timed out waiting for device /dev/sdb1
mount: special device /dev/sdb1 does not exist
[DEPEND] Dependency failed for /mnt/data.mount
Cause : Une entrée dans /etc/fstab fait référence à un appareil ou à un UUID qui n'est pas associé à l'instance de calcul, ou le système de fichiers ne peut pas être monté. Le service systemd arrête le démarrage et passe en mode d'urgence.
Solution : sur la VM de secours, corrigez l'entrée dans /etc/fstab sur le disque installé ou supprimez-la. Pour connaître la procédure, consultez Résoudre les problèmes de démarrage des VM Linux en raison d'erreurs fstab.
Pour l'option de montage qui empêche un périphérique manquant de bloquer le démarrage, consultez Monter le disque.
GRUB ne peut pas charger sa configuration ni le kernel
Symptôme : Le démarrage s'arrête à une invite GRUB et la sortie de la console série contient des lignes semblables à celles-ci :
error: file '/boot/grub/grub.cfg' not found
error: file '/vmlinuz-6.1.0-18-amd64' not found
error: no such partition
error: no such device
error: unknown filesystem
error: you need to load the kernel first
grub rescue>
Minimal BASH-like line editing is supported
Cause : Le bootloader GRUB ne trouve pas son fichier de configuration, ses modules, ou le kernel et le disque RAM initial auxquels la configuration fait référence. Ce problème se produit après l'échec d'une mise à niveau de package, une modification de la mise en page des partitions, une partition /boot reformatée ou corrompue, ou un disque cloné dont les UUID du système de fichiers ont changé.
Résolution : Sur la VM de secours, installez le disque de démarrage et saisissez un environnement chroot, comme décrit dans Récupérer une VM, puis régénérez le fichier de configuration GRUB, comme décrit dans Configurer le bootloader.
Si le chargeur d'amorçage ne peut pas être réparé, restaurez le disque à partir d'un instantané.
Le disque RAM initial ne peut pas installer le système de fichiers racine
Symptôme : la sortie de la console série contient des lignes semblables à celles-ci :
dracut-initqueue[452]: Warning: dracut-initqueue timeout - starting timeout scripts
dracut: FATAL: ...
Failed to mount /sysroot
ALERT! UUID=1234abcd-... does not exist. Dropping to a shell!
Gave up waiting for root file system device
VFS: Unable to mount root fs on unknown-block(0,0)
Cause : Le disque RAM initial (initramfs) a démarré, mais il n'a pas pu trouver ni installer le système de fichiers racine. Les causes courantes sont un paramètre de noyau root= ou un UUID qui ne correspond plus au disque, une image initramfs pour laquelle le pilote du disque est manquant ou une image initramfs corrompue. Sur les séries de machines qui utilisent l'interface de disque NVMe, une configuration de démarrage qui nomme le disque par un chemin d'accès d'appareil tel que /dev/sda ne correspond plus. Utilisez l'UUID à la place.
Résolution : Vérifiez que le système de fichiers racine recherché par le disque RAM initial existe sur le disque installé, puis recréez le disque RAM initial pour votre système d'exploitation. Pour connaître la procédure, consultez Résoudre les problèmes de démarrage des VM Linux en raison d'une panique du noyau et Réparer le disque hors connexion.
Corruption du système de fichiers
Symptôme : la sortie de la console série contient des lignes semblables à celles-ci :
Bad magic number in super-block
EXT4-fs error (device sda1): ...
XFS (sda1): Metadata corruption detected
XFS (sda1): log mount/recovery failed
BTRFS error (device sda1): ...
UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
Cause : Le système de fichiers sur le disque de démarrage est endommagé, généralement après un arrêt incorrect, un disque plein ou une erreur d'E/S.
Résolution : créez un instantané du disque. Ensuite, sur la VM de secours, vérifiez et réparez le système de fichiers sur le disque désinstallé, comme décrit dans Identifier la raison pour laquelle le disque de démarrage ne fonctionne pas. Si la vérification ne permet pas de réparer le système de fichiers, restaurez le disque à partir d'un instantané.
Panique du noyau
Symptôme : la sortie de la console série contient Kernel panic - not
syncing: suivi de la raison, par exemple Attempted to kill init!, Fatal exception, hung_task: blocked tasks, Out of memory, Fatal
Machine check ou NMI: Not continuing. Une image de noyau corrompue s'arrête plus tôt avec -- System halted.
Cause : le noyau a rencontré une erreur irrécupérable. La raison après le deux-points identifie la catégorie : un init planté, une vérification de la machine matérielle, une panique d'épuisement de la mémoire ou une image du noyau corrompue.
Résolution : Réinitialisez l'instance de calcul. Si la panique se reproduit, consultez Résoudre les problèmes de démarrage des VM Linux en raison d'une panique du noyau.
Échec du chargement de la règle SELinux
Symptôme : la sortie de la console série contient l'un des éléments suivants et le démarrage s'arrête :
Failed to load SELinux policy
Unable to load SELinux policy
Vous pouvez également voir Warning -- SELinux targeted policy relabel is
required, ce qui n'est pas une erreur : l'instance de calcul relabelise le système de fichiers, puis redémarre d'elle-même.
Cause : Le magasin de règles SELinux sur le disque est manquant ou corrompu, ou les libellés de fichiers sont incohérents après une restauration ou une modification hors connexion.
Solution : Sur la VM de secours, marquez le disque monté pour un re-étiquetage SELinux complet au prochain démarrage, ou réinstallez les packages de règles SELinux pour votre système d'exploitation si le magasin de règles est endommagé. Sur les images d'OS basées sur RHEL, vous pouvez laisser l'instance de calcul démarrer pendant que vous réparez la règle en définissant SELinux sur le mode permissif, comme décrit dans Passer SELinux en mode permissif.
Le système ne peut pas démarrer le processus init
Symptôme : la sortie de la console série contient des lignes semblables à celles-ci :
Failed to switch root
Target filesystem doesn't have requested /sbin/init
No working init found
run-init: /sbin/init: No such file or directory
/sbin/init: error while loading shared libraries: ...
Cause : Le système de fichiers racine est installé, mais le programme init, tel que systemd, est manquant, n'est pas exécutable ou dépend d'une bibliothèque partagée manquante. Ce problème survient généralement après une mise à niveau interrompue du package ou une restauration incomplète.
Résolution : Sur la VM de secours, entrez dans un environnement chroot comme décrit dans Récupérer une VM, vérifiez que le programme init existe et que ses bibliothèques sont intactes. Si ce n'est pas le cas, réinstallez le package système init à l'aide du gestionnaire de packages de votre distribution.
Mode Urgence et compte racine verrouillé
Symptôme : La sortie de la console série se termine par l'un des éléments suivants :
You are in emergency mode. After logging in, type "journalctl -xb" to view system logs
Give root password for maintenance (or press Control-D to continue):
Cannot open access to console, the root account is locked.
Cause : Une unité a échoué au démarrage et systemd s'est arrêtée à la cible d'urgence. Sur les images d'OS fournies par Google, le compte racine n'a pas de mot de passe. Par conséquent, le shell d'urgence ne peut pas être utilisé à partir de la console série.
Résolution : les lignes qui précèdent l'invite d'urgence nomment l'unité défaillante. L'échec est généralement dû à l'un des problèmes suivants :
- Impossible de monter l'entrée de fichier
/etc/fstab - Le disque RAM initial ne peut pas installer le système de fichiers racine
- Corruption du système de fichiers
Corrigez la cause hors connexion comme décrit dans Corriger le disque hors connexion. N'essayez pas d'utiliser l'interface système d'urgence.
Le micrologiciel ne trouve pas de disque amorçable
Symptôme : la sortie de la console série contient l'un des éléments suivants avant tout message du noyau :
No bootable device.
BdsDxe: failed to load Boot0001
Invalid partition table!
Verification failed: (0x1A) Security Violation
Cause : Le disque de démarrage n'est pas associé en tant que périphérique de démarrage, sa table de partition ou son enregistrement de démarrage est endommagé, ou, sur une instance de VM protégée avec démarrage sécurisé, le chargeur de démarrage ou le noyau n'est pas correctement signé.
Résolution : Vérifiez que le disque est associé en tant que disque de démarrage de l'instance de calcul. Pour en savoir plus, consultez Dissocier et réassocier des disques. Si la table de partitionnement ou l'enregistrement de démarrage sont endommagés, réparez le bootloader comme décrit dans GRUB ne peut pas charger sa configuration ou le kernel. Une violation du démarrage sécurisé ne peut pas être corrigée en modifiant le disque : restaurez un noyau et un chargeur de démarrage signés, ou désactivez le démarrage sécurisé sur l'instance de calcul, comme décrit dans Modifier les options de VM protégée sur une instance de VM.
Corriger le disque hors connexion
La plupart des problèmes de démarrage ne peuvent pas être résolus à partir de l'instance de calcul, car celle-ci n'atteint jamais l'invite de connexion. À la place, associez le disque de démarrage à une VM de secours temporaire, installez-le, apportez la modification, puis déplacez le disque. Pour connaître la procédure, consultez Sauver une VM inaccessible.
Les solutions décrites dans ce document supposent que le disque de démarrage d'origine est associé à une VM de secours et monté sur celle-ci. Avant de modifier le disque, créez un instantané pour pouvoir le restaurer en cas d'échec de la réparation. Pour connaître la procédure, consultez Créer des instantanés de disque d'archive et standards.
Restaurer l'instance de calcul si le disque ne peut pas être réparé
Si aucune de ces solutions ne fonctionne ou si le système de fichiers ne peut pas être réparé, restaurez le disque de démarrage à partir d'un instantané, ou créez une instance de calcul à partir d'un instantané ou d'une image d'OS personnalisée, puis transférez-y vos données.