Lorsque Proxmox refuse de démarrer et bascule directement en emergency mode, la situation peut sembler critique. Pourtant, dans la majorité des cas, la panne n’est pas liée au système lui-même, mais à un simple disque de stockage qui ne parvient plus à se monter au démarrage. Un volume de données corrompu, un UUID modifié, une coupure de courant ou même un câble SATA instable peuvent suffire à bloquer entièrement l’hôte et à rendre toutes les machines virtuelles inaccessibles.
Dans ce guide, je vous montre une méthode fiable et reproductible pour diagnostiquer et réparer ce type de blocage sans mettre en danger les VMs. L’objectif n’est pas seulement de “débloquer” Proxmox, mais de comprendre précisément ce qui se produit, d’identifier le disque défaillant, de vérifier l’exactitude du fichier fstab, puis de réparer la filesystem de manière sûre lorsque cela s’avère nécessaire. Suivre cette démarche permet non seulement de restaurer l’accès au serveur, mais aussi d’éviter des manipulations risquées comme le reformatage ou la recréation de volumes, qui entraîneraient une perte totale de données.
En quelques étapes maîtrisées, il est possible de remettre le système en marche, de valider l’intégrité du disque et de prévenir de futurs incidents. Il s’agit d’une procédure essentielle pour toute personne administrant Proxmox avec plusieurs disques de stockage, que ce soit sur un serveur de production ou dans un homelab avancé.
Symptômes
Lors du démarrage, Proxmox affiche :
Failed to start systemd-fsck[…]
Ce message indique que le système n’a pas réussi à vérifier ou monter l’un des systèmes de fichiers déclarés dans fstab. Cela se produit généralement lorsqu’une partition présente des erreurs ou que son identifiant (UUID) ne correspond plus à celui attendu.
Dépendances échouées : mnt-data.mount, local-fs.target
Ces dépendances signifient que le point de montage /mnt/data n’a pas pu être initialisé correctement. Comme Proxmox considère ce disque comme essentiel, toute la séquence de démarrage est interrompue.
Proxmox entre alors en emergency mode
Le système bascule en mode de récupération pour éviter des écritures potentiellement dangereuses sur une partition incohérente. Ce comportement est normal : il protège les données et demande une intervention manuelle afin d’éviter la corruption du stockage ou des VMs.
Connexion en mode emergency
Proxmox démarre en emergency mode et affiche un terminal minimal.
Connectez-vous directement depuis cet écran en utilisant le compte root, puis entrez le mot de passe associé.
Ce mode fournit un accès restreint au système, suffisant pour diagnostiquer les erreurs de montage et corriger la configuration.
Identifier le disque en panne
Dans cette étape, on détermine précisément quel disque pose problème au démarrage.
Exécuter :
lsblk -f blkid
Repérer le disque portant LABEL=data (souvent /dev/sdb1).
Vérifier également /etc/fstab
Une grande partie des erreurs en emergency mode viennent d’un UUID incorrect dans fstab.
Afficher le fichier :
cat /etc/fstab
Comparer l’UUID de la ligne correspondant à /mnt/data avec la sortie de :
blkid
Si l’UUID ne correspond pas, corriger la ligne, sauvegarder, puis redémarrer.
Ne pas faire
Si vous ne souhaitez pas perdre vos données, évitez absolument les actions suivantes :
- Ne pas formater.
- Ne pas utiliser mkfs.
- Ne pas supprimer de volumes ou partitions.
- Ne pas forcer un montage en écriture.
Ces actions détruiraient les VM.
Réparer la filesystem ext4
Si le disque est en ext4 :
fsck -f -y /dev/sdb1
Laisser l’outil réparer automatiquement les métadonnées.
L’option -y accepte automatiquement toutes les corrections proposées. Sur un disque avec beaucoup d’erreurs, il est préférable de lancer d’abord fsck -f /dev/sdb1 sans -y pour voir ce qui sera modifié.
Aucun fichier VM n’est supprimé.
Redémarrer
reboot
Proxmox devrait démarrer normalement et monter /mnt/data.
Note : cette procédure couvre uniquement les filesystems ext4. Si votre stockage utilise ZFS, la commande zpool status et zpool scrub sont les outils appropriés — ce sera l’objet d’un prochain tutoriel.
Vérification après démarrage
mount | grep data dmesg | grep sdb
S’assurer que le disque est monté correctement et sans erreurs.
Et voilà : le système Proxmox est de nouveau opérationnel. Une fois en emergency mode, il suffit d’identifier le disque responsable du blocage, de corriger son entrée dans fstab si nécessaire et de laisser fsck réparer la partition ext4. Dans la plupart des cas, cette seule intervention suffit à rétablir un état cohérent et à permettre au serveur de redémarrer normalement. La vérification du montage après le redémarrage confirme que la filesystem fonctionne de nouveau sans erreur et que les machines virtuelles sont accessibles.
Cette expérience rappelle toutefois à quel point un incident anodin — une coupure d’alimentation, une baisse de tension ou même un simple faux contact sur un câble SATA ou un adaptateur USB — peut suffire à laisser une partition dans un état incohérent et bloquer complètement le démarrage de Proxmox. Pour réduire ce risque, il est conseillé d’utiliser un onduleur lorsque des VMs critiques ou plusieurs disques sont impliqués, et de surveiller régulièrement l’état du disque via SMART afin de détecter tôt les secteurs défectueux ou une dégradation progressive. Un contrôle ponctuel du câblage peut également éviter des erreurs intermittentes difficiles à diagnostiquer.
En combinant ces bonnes pratiques avec la procédure décrite plus haut, on obtient un environnement Proxmox plus résilient, capable de redémarrer proprement même après un incident matériel, et nettement moins susceptible de subir un blocage similaire à l’avenir.
Bonne chance!