Démarrage d'Ubuntu Server en mode d'urgence : Guide de dépannage étape par étape

Votre serveur Ubuntu redémarre après une mise à jour ou une coupure de courant, puis s'arrête sur le message « Passer en mode d'urgence ». L'accès SSH est indisponible, les services sont hors service et la console demande une intervention de maintenance. Cela signifie généralement que systemd n'a pas pu effectuer une étape de démarrage nécessaire, souvent à cause d'un échec de vérification du système de fichiers ou de l'impossibilité de trouver un point de montage requis. Considérez ce message comme un indice : identifiez l'unité défaillante avant de modifier des fichiers ou d'exécuter une commande de réparation.

Ce guide s'applique aux installations Ubuntu Server classiques utilisant systemd. Les commandes et les menus de démarrage peuvent différer sur Ubuntu Core, les systèmes chiffrés, les images cloud et les serveurs gérés par un fournisseur. La documentation Ubuntu actuelle décrit emergency.target comme un shell minimal qui ne lance pas les services habituels et ne monte pas les systèmes de fichiers classiques ; selon la méthode d'accès, le système de fichiers racine peut être en lecture seule ou en lecture-écriture. C'est pourquoi les premières étapes consistent à effectuer une inspection et une sauvegarde.

1. Analysez la panne avant toute modification.

Connectez-vous à la console locale ou à celle du fournisseur si vous y êtes invité. Sur une machine physique, connectez un clavier et un écran ; sur un serveur virtuel, utilisez la console série ou de récupération du fournisseur. Photographiez ou copiez l'erreur complète, en particulier le nom d'une unité ou systemd-fsck@dev-disk-by-uuid-....serviced'un point de montage se terminant par .mount. Un UUID manquant, une vérification du système de fichiers ayant échoué et un service défaillant nécessitent des solutions différentes.

Depuis l'interface de secours, examinez les unités défaillantes et le journal de démarrage actuel :

systemctl --failed
journalctl -xb

Recherchez la première erreur significative, et non pas seulement la dernière ligne « dépendance non satisfaite ». Si le journal identifie un point de montage, notez son point de montage et son UUID. S'il identifie un service sans lien avec le stockage, n'effectuez aucune modification /etc/fstabau hasard ; examinez l'unité concernée systemctl status unit-nameet ses messages de journalisation récents.

2. Vérifiez si le système de fichiers racine autorise les modifications.

Avant de modifier un fichier de configuration, vérifiez comment le système de fichiers racine est monté :

findmnt /

Si les options s'affichent ro, le système de fichiers racine est en lecture seule. Si le système de fichiers est par ailleurs sain et que vous devez effectuer une petite réparation de configuration, remontez-le en lecture-écriture :

mount -o remount,rw /

Relancez la commande findmnt /pour confirmer la modification. En cas d'échec du remontage, arrêtez-vous et notez l'erreur. Un système de fichiers racine en lecture seule peut constituer une mesure de protection en cas de problème ; forcer les écritures ou tenter un montage à répétition peut compliquer la récupération. Utilisez un environnement de secours ou contactez l'assistance de votre fournisseur si le volume racine semble endommagé.

3. Inspectez les disques et comparez-les avec le fichier /etc/fstab.

Une cause fréquente est une /etc/fstabentrée obsolète : un disque a été retiré, un UUID a été modifié ou un chemin de montage a été mal saisi. Voici la liste des systèmes de fichiers détectés et leurs identifiants :

lsblk -f
blkid

Lisez ensuite la configuration de la table de montage :

cat /etc/fstab

Faites correspondre chaque UUID configuré avec la sortie de `ls` lsblk -fou `ls` blkid, et vérifiez que le point de montage et le type de système de fichiers sont corrects. Ne remplacez pas un nom de périphérique, tel que `/var/lib`, /dev/sdb1en vous basant uniquement sur sa lettre actuelle ; l’ordre des périphériques peut changer. Les UUID sont souvent plus stables, mais ils doivent tout de même correspondre au système de fichiers réel.

Le /etc/fstabfichier est traduit en unités de montage systemd au démarrage. Ses champs et options ont des significations spécifiques ; consultez le manuel officiel fstab d’Ubuntu si une entrée vous est inconnue.

4. Contourner temporairement un support manquant optionnel

Si l'entrée défaillante pointe vers un disque de données non essentiel intentionnellement absent, sauvegardez-la /etc/fstab, puis commentez uniquement cette ligne en ajoutant `#` #au début. Cela vous permettra de vérifier si le montage manquant bloque le démarrage. Ne commentez pas le système de fichiers racine, `/etc/root` /boot, ni une entrée de volume chiffré, sauf si vous comprenez l'organisation du stockage du système.

cp -a /etc/fstab /etc/fstab.before-emergency-fix
nano /etc/fstab

Si le disque doit être optionnel en fonctionnement normal, envisagez l' nofailoption de montage après avoir vérifié le comportement attendu. N'utilisez cette option que pour un montage véritablement optionnel : l'ajouter à un volume système requis peut masquer une véritable panne de stockage. Les systèmes de fichiers réseau peuvent nécessiter des options systemd spécifiques et des dépendances réseau supplémentaires ; ne copiez pas d'options provenant d'une configuration différente.

Après modification, demandez à systemd de recharger les unités générées et testez le fichier :

systemctl daemon-reload
mount -a

Lisez attentivement toutes les sorties. Un résultat sans erreur ne garantit pas que toutes les applications peuvent utiliser les données montées, mais une erreur d'UUID, de syntaxe ou de montage signalée vous indique les problèmes restant à résoudre. Le manuel de systemd-fstab-generator explique comment systemd convertit les entrées fstab en unités de montage.

5. Corriger un UUID, un chemin ou une option de montage incorrects

Si le disque est présent mais que son UUID diffère, vérifiez que vous avez bien identifié le système de fichiers correct avant de mettre à jour le UUID=...champ correspondant. Assurez-vous que le répertoire de montage existe, que le type de système de fichiers est correct et que les options sont valides pour ce système de fichiers. Corrigez une entrée à la fois, puis relancez la systemctl daemon-reloadcommande mount -a.

Pour un disque de données amovible ou secondaire optionnel, la configuration d'une stratégie de montage optionnel appropriée peut empêcher l'absence d'un périphérique de bloquer le démarrage. Pour un volume critique, réparez le périphérique, le câble, le mappage de chiffrement ou l'identifiant au lieu de masquer la panne. Si l'unité défaillante est un périphérique LUKS ou LVM, examinez le mappage et l'état du volume ; ne remplacez pas son UUID par une partition portant un nom similaire.

6. Effectuez une vérification du système de fichiers uniquement lorsque la cible est démontée.

Si la console signale des erreurs de système de fichiers, identifiez le type de système de fichiers et le périphérique avant de le réparer. N'exécutez pas d'utilitaire de réparation sur un système de fichiers monté, en particulier sur le système de fichiers racine actif. Le manuel de fsck d'Ubuntu décrit la commande d'encapsulation ; les options de vérification et de réparation appropriées dépendent du système de fichiers.

Pour une partition de données ext2, ext3 ou ext4, vérifiez d'abord qu'elle n'est pas montée findmnt. Si elle l'est, démontez-la avant de procéder à la vérification. Voici une procédure de vérification typique pour une partition ext4 dans un environnement de secours approprié :

sudo e2fsck -f /dev/DEVICE

Ne remplacez /dev/DEVICEla partition qu'après l'avoir correctement identifiée lsblk -f. Lisez attentivement les questions et le statut de l'outil de vérification ; n'acceptez pas systématiquement l'option « oui » sans comprendre le risque de perte de données. Si le système de fichiers racine ne peut pas être démonté depuis l'invite de commandes d'urgence, démarrez sur une machine virtuelle ou dans un environnement de récupération et vérifiez-le hors ligne. Btrfs, XFS et les autres systèmes de fichiers utilisent des outils et des procédures de réparation différents. En particulier, une fsckcommande générique ne garantit pas la réparation de tous les types de systèmes de fichiers.

7. N’utilisez GRUB ou une récupération externe que lorsque le shell est indisponible.

Si le serveur n'atteint jamais un shell de secours, ouvrez le menu GRUB et essayez la procédure de récupération de la distribution lorsqu'elle est disponible. Sur une installation Ubuntu standard, ce menu est généralement accessible en maintenant la touche Maj enfoncée sur les systèmes BIOS classiques ou en appuyant sur Échap sur les systèmes UEFI. Cependant, les machines virtuelles hébergées peuvent utiliser une procédure différente. Pour un démarrage d'urgence ponctuel via systemd, un administrateur peut modifier l'entrée GRUB sélectionnée et l'ajouter systemd.unit=emergency.targetà la ligne de commande du noyau Linux. Cette modification ne s'applique qu'à ce démarrage ; supprimez-la avant le prochain démarrage normal. Consultez la documentation officielle du menu GRUB de GNU .

Si le volume de démarrage ne peut pas être monté, utilisez un environnement Ubuntu Live ou le système de récupération de votre fournisseur cloud pour l'examiner. Déverrouillez le stockage chiffré et activez LVM uniquement si cela correspond à votre installation. Le montage du système de fichiers racine d'un serveur depuis la récupération comporte des risques supplémentaires ; évitez d'y écrire tant que le disque et le système de fichiers n'ont pas été identifiés. Ubuntu Core utilise son propre processus de récupération et ne peut être réparé en suivant aveuglément les étapes GRUB classiques pour ordinateur de bureau ou serveur.

8. Redémarrez et vérifiez la réparation.

Une fois la cause signalée corrigée et les tests de montage réussis, redémarrez :

reboot

Après le démarrage, vérifiez que l'hôte atteint sa cible multi-utilisateurs habituelle, que les systèmes de fichiers attendus sont montés et que les services importants sont actifs :

systemctl is-system-running
systemctl --failed
findmnt --target /

Vérifiez les points de montage de données attendus avec `git add` findmnt /path/to/mountet confirmez les services critiques avec `git add` systemctl status service-name. Si le mode d'urgence redémarre, examinez à nouveau la première erreur de démarrage plutôt que de répéter la même réparation. Un redémarrage réussi signifie que le serveur effectue un démarrage normal et que son espace de stockage et ses services requis sont disponibles ; l'affichage de l'invite de connexion ne suffit pas.

Pour connaître le comportement actuel de systemd, consultez le manuel des unités spéciales d'Ubuntu . Les versions des paquets et les menus de récupération peuvent varier selon la version d'Ubuntu et la plateforme d'hébergement ; par conséquent, référez-vous à la documentation de la version installée lorsqu'une commande ou une unité diffère.