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

Scénario illustratif : Casey gère une machine virtuelle Ubuntu Server hypothétique qui passe en mode d'urgence après un redémarrage, peu après l'ajout d'un montage de volume de données optionnel /etc/fstab. Casey a accès à la console, mais pas à une session SSH. La modification du montage est une piste, et non une cause avérée : le mode d'urgence peut survenir après plusieurs échecs de démarrage. Casey consulte donc les journaux de la machine avant toute modification. Les panneaux de terminal ci-dessous présentent des configurations et des résultats fictifs, et non une véritable réparation ou un test.

Que signifie le mode d'urgence ?

Sur une installation Ubuntu Server utilisant systemd, emergency.targetlance un shell minimal sur la console principale. Ce shell est plus limité que la commande `ls` rescue.target, qui démarre le système de base et les points de montage système avec uniquement les services essentiels. Selon la méthode utilisée pour accéder au mode d'urgence, le système de fichiers racine peut déjà être monté en lecture seule ou en lecture-écriture. Il est recommandé de vérifier son état plutôt que de le présumer. Consultez la documentation systemd relative aux cibles spéciales .

Commencez par identifier l'invite de commande. Un shell d'urgence systemd affiche généralement « Bienvenue en mode d'urgence ! » et peut demander le mot de passe root pour la maintenance. Une invite BusyBox, par exemple, (initramfs)indique que le démarrage n'a pas encore abouti sur le système de fichiers racine installé ; une invite grub>de ce grub rescue>type signale un problème de chargeur de démarrage. Ces deux situations nécessitent des procédures de récupération différentes. Si le compte root est verrouillé ou si le serveur est distant, utilisez la console série/VNC ou l'environnement de secours de votre hébergeur ; le protocole SSH n'est généralement pas disponible à ce stade. N'appuyez pas sur Ctrl+D pour continuer tant que vous n'avez pas compris et résolu l'erreur signalée.

Sauvetage étape par étape

1. Conservez l'accès à la console et notez la panne exacte

Restez dans la console d'urgence. Notez le dernier montage ou service ayant échoué, ainsi que le chemin d'accès au périphérique ou l'UUID affiché au-dessus de l'invite. fstabLa modification récente de Casey mérite d'être vérifiée, mais ne commentez pas chaque ligne défaillante et n'exécutez pas de commande de réparation uniquement à cause du mot « urgence ». Si le système est une machine virtuelle, laissez la console du fournisseur ouverte pendant la réparation et au prochain redémarrage.

2. Consultez le journal de démarrage actuel et les unités défaillantes.

Dans le terminal d'urgence, exécutez :

journalctl -xb -p err --no-pager
systemctl --failed --no-pager

-bLimitez la requête au journal à ce démarrage et -p errfiltrez les erreurs par priorité et supérieure. Recherchez la première erreur pertinente, et non la simple succession de messages « dépendance non satisfaite ». Si un point de montage a échoué, notez son nom (échappé) et son chemin cible ; si un service a échoué, déterminez s'il s'agit de la cause ou seulement d'une conséquence de l'absence de montage. journalctl(1)Le manuel d'Ubuntu documente le démarrage et le filtrage des points de montage.

3. Vérifiez le point de montage racine et l'espace disponible

Avant de modifier des fichiers ou de tenter des réparations, vérifiez comment le système de fichiers racine est monté et si le système a épuisé ses blocs ou inodes :

findmnt -no SOURCE,FSTYPE,OPTIONS /
df -h /
df -i /

Dans la findmntsortie, `--read- roonly` signifie « lecture seule » et rw`--read-write` signifie « lecture-écriture ». Une racine en lecture seule peut être intentionnelle lors d'une procédure de récupération, ou indiquer un problème de système de fichiers. Ne forcez pas immédiatement un remontage en lecture-écriture si les journaux du noyau signalent des erreurs d'E/S ou de système de fichiers. Un système de fichiers plein ou une table d'inodes épuisée peuvent également entraîner la défaillance de services et de montages sans lien avec le système. Le findmnt(8)manuel d'Ubuntu explique comment inspecter les systèmes de fichiers montés.

4. Valider /etc/fstabet vérifier les identifiants de l'appareil

Étant donné que Casey a récemment effectué des modifications /etc/fstab, vérifiez à la fois sa syntaxe et l'existence des périphériques référencés :

findmnt --verify --verbose
lsblk -f
blkid

findmnt --verify --verboseCette fonction vérifie les entrées du fichier fstab afin de détecter d'éventuels problèmes d'analyse et d'utilisation. Comparez chaque entrée UUID=de la ligne suspecte avec l'UUID affiché par ` lsblk -fsudo` ou `sudo` blkid. Vérifiez également le point de montage, le type de système de fichiers et les options. Un UUID copié depuis un autre disque, un périphérique non connecté ou une option invalide peuvent empêcher le montage. N'essayez pas de deviner une partition/dev/sda1 ; les noms de périphériques peuvent changer entre deux redémarrages.

5. Corrigez uniquement le problème de montage confirmé

Si le système de fichiers racine est accessible en écriture et que la vérification fstab identifie une ligne incorrecte, effectuez une sauvegarde avant toute modification :

cp -a /etc/fstab /etc/fstab.before-rescue
nano /etc/fstab

Ne corrigez l'UUID ou tout autre champ qu'après avoir confirmé le périphérique prévu. Si le montage est réellement optionnel et que le serveur doit pouvoir démarrer même en l'absence de ce volume, une ligne fstab compatible avec systemd peut être utilisée, nofailainsi qu'une attente de périphérique finie, par exemple :

UUID=VERIFIED-UUID /srv/archive ext4 defaults,nofail,x-systemd.device-timeout=10s 0 2

Remplacez l'espace réservé par l'UUID réel et indiquez le type de système de fichiers effectif. N'ajoutez pas cette option nofailau système de fichiers racine, au système de démarrage ni à aucun autre système de fichiers nécessaire au bon fonctionnement de la machine ou de ses applications. Avec cette option nofail, le démarrage se poursuit même en cas d'échec du montage ; les services dépendants peuvent donc nécessiter une intervention. Le manuel de l'unité de montage systemd d'Ubuntu documente ces options du fichier fstab.

Après modification, veuillez valider à nouveau avant de tenter le montage :

findmnt --verify --verbose
systemctl daemon-reload
mount /srv/archive

Utilisez le point de montage réel dans la dernière commande. Si l'erreur persiste, consultez le nouveau message d'erreur et vérifiez que le disque est bien connecté et en bon état. Si le système de fichiers racine est en lecture seule, n'effectuez aucune modification sans précaution ; utilisez un environnement de récupération fourni par le fournisseur ou un support d'installation Ubuntu amorçable pour examiner et modifier le système installé en toute sécurité.

6. N’enquêtez sur un service défaillant que lorsque le journal d’incidents pointe vers un

Le mode d'urgence ne signifie pas que chaque défaillance de service a provoqué l'arrêt du démarrage. Si l'erreur en question mentionne un service, examinez ce service et ses journaux au lieu de le masquer ou de le désactiver.

systemctl status example.service --no-pager
journalctl -u example.service -b --no-pager

Remplacez example.servicepar le nom exact de l'unité. Vérifiez si son fichier de configuration, son exécutable, ses identifiants ou le point de montage requis sont manquants. Si la panne est liée au volume de données manquant de Casey, corrigez d'abord ce point de montage, puis réévaluez le service. La désactivation d'un service essentiel peut masquer le problème tout en rendant le serveur inutilisable.

7. Traiter les erreurs du système de fichiers comme une tâche de réparation hors ligne

Si le journal du noyau signale une corruption du système de fichiers ou des erreurs d'E/S de stockage, cessez toute écriture lorsque cela est possible et effectuez une sauvegarde ou un instantané du fournisseur avant toute réparation. Vérifiez le périphérique et le système de fichiers exacts à l'aide lsblk -fde l'outil approprié. Pour un système de fichiers racine, démarrez sur le système de secours du fournisseur ou sur le support de récupération/live Ubuntu, assurez-vous que la partition cible est démontée et utilisez l'outil de vérification correspondant à ce système de fichiers. Pour ext2/3/4, cet outil est e2fsck`ls` ; pour XFS, Btrfs et les autres formats, la procédure est différente.

N'exécutez jamais fsckde commande e2fscksur un système de fichiers monté, y compris une racine en lecture seule montée. Le e2fsck(8)manuel d'Ubuntu avertit que la vérification d'un système de fichiers monté est généralement risquée et que les résultats ne sont pas valides. Si le disque signale des erreurs d'E/S répétées, privilégiez la récupération des données ou la prise en charge par le fournisseur de stockage plutôt que de tenter des réparations à répétition.

8. Revenez au démarrage normal et vérifiez le résultat.

Une fois la cause confirmée corrigée, redémarrez depuis la console :

systemctl reboot

Une fois Ubuntu démarré, vérifiez la cible par défaut configurée, l'état actuel du système, les unités défaillantes et le nouveau système de démarrage :

systemctl get-default
systemctl is-system-running
systemctl --failed --no-pager
journalctl -b -p err --no-pager
findmnt --verify --verbose

Si vous choisissez de poursuivre intentionnellement le démarrage en cours, la systemctl defaultcommande `systemctl start` demande à systemd de démarrer la cible par défaut configurée. Utilisez-la uniquement après la résolution de l'erreur bloquante ; elle ne répare pas un montage invalide ni un système de fichiers endommagé. systemctl get-defaultLa commande `systemctl start` affiche la cible par défaut configurée et systemctl is-system-runningindique si systemd considère que l'état actuel est « en cours d'exécution », « dégradé » ou autre. Une récupération réussie signifie que les systèmes de fichiers attendus sont montés, les services requis sont actifs et que la même situation d'urgence ne se reproduit pas après le redémarrage.

Si l'invite est (initramfs)plutôt

N'appliquez pas aveuglément les étapes de l'interface de démarrage d'urgence systemd dans l'initramfs de BusyBox. L'initramfs tente de localiser et de monter le système de fichiers racine réel avant de céder le contrôle au système installé. Notez l'erreur exacte, vérifiez si le périphérique attendu apparaît dans les /devrépertoires `/etc/system .../dev/disk/by-uuidroot=

Pour la machine virtuelle hypothétique de Casey, le résultat utile est une cause vérifiée et une correction ciblée : restaurer le volume optionnel attendu, corriger son identifiant confirmé ou le configurer comme optionnel uniquement si la charge de travail le permet réellement. Ensuite, vérifiez le prochain démarrage depuis la console avant de fermer la session de récupération.