Debian 13 : /etc/pve semble vide après le redémarrage — pourquoi les montages échouent et comment récupérer

Ce qu’est réellement /etc/pve (et pourquoi il « disparaît »)

Sur Proxmox VE, /etc/pve n’est pas « un répertoire avec des fichiers ». C’est un point de montage pour le système de fichiers de cluster Proxmox, pmxcfs.
C’est un système de fichiers en espace utilisateur (FUSE) qui présente la configuration du cluster comme un arbre cohérent, soutenu par une base de données interne et synchronisé via la messagerie du cluster.

Lorsque pmxcfs n’est pas monté, votre système a quand même un répertoire physique à /etc/pve — puisque Linux a besoin d’un endroit où monter les choses.
Ce répertoire est typiquement vide ou contient seulement ce qui reste du tout début du démarrage. Vous ne voyez donc pas des « configs perdues ». Vous voyez « non monté ».

Le piège est que les échecs de montage et les configs « vides » apparaissent souvent en même temps que des problèmes de stockage :
pools ZFS non importés, volumes LVM non activés, sessions iSCSI non établies, NFS non monté, Ceph non prêt, ou systemd démarrant des services dans le mauvais ordre.
Une course au démarrage plus tard, votre pile de gestion fonctionne comme si la moitié du plancher avait disparu.

Une citation que les équipes opérations apprennent à la dure : « L’espoir n’est pas une stratégie. » — Gene Kranz.
Ce n’est pas spécifique au stockage, mais c’est douloureusement pertinent quand quelqu’un dit « Peut-être que ça ira mieux après un autre redémarrage ».

Blague n°1 : Si votre plan de récupération est « redémarrer jusqu’à ce que ça marche », félicitations — vous venez d’inventer une machine à sous avec des probabilités pires.

Tactique de diagnostic rapide

C’est le chemin le plus court entre « /etc/pve est vide » et « je sais exactement ce qui est cassé ». Faites-le dans l’ordre. Ne faites pas de freestyle.

1) Confirmer si /etc/pve est monté (pas « vide »)

• Si ce n’est pas un montage FUSE, vous regardez le répertoire sous-jacent.
• Si c’est monté, votre problème est probablement le quorum, corosync, ou des permissions/concours de verrouillage — pas un montage.

2) Vérifier le statut et les logs de pmxcfs

• Si pmxcfs est arrêté, corrigez cela en premier. Tout le reste est du bruit.
• Si pmxcfs est actif, vérifiez s’il signale une corruption de base de données, des fichiers de lock, ou l’état du cluster.

3) Vérifier corosync + quorum (sur les clusters)

• Pas de quorum signifie souvent une interface UI étrange, une configuration partielle et des opérations de cluster bloquées.
• Les installations mono-nœud peuvent tout de même souffrir si elles ont été un jour en cluster ou mal configurées.

4) Vérifier la disponibilité du stockage et l’ordre systemd

• Si ZFS ne s’est pas importé ou LVM n’a pas activé, les montages/services dépendants échoueront.
• Rétablissez la disponibilité du stockage, puis redémarrez proprement les services dépendants.

5) Décider : récupérer sur place vs restaurer depuis des sauvegardes

• Si la base pmxcfs est endommagée, vous pourriez devoir reconstruire l’état du nœud à partir d’autres nœuds ou de sauvegardes.
• Si c’est simplement « non monté », corrigez le service et passez à autre chose.

Les véritables modes de panne (et à quoi ils ressemblent)

Mode de panne A : pmxcfs jamais monté

C’est le cas classique « /etc/pve est vide ». Le répertoire existe mais le montage FUSE n’a pas eu lieu.
Les causes incluent le service pmxcfs qui ne démarre pas, qui plante immédiatement, ou qui est bloqué en attente d’autre chose.

Ce que vous verrez :

• mount n’affiche pas pmxcfs.
• systemctl status pve-cluster indique failed.
• journalctl affiche des erreurs de démarrage (souvent des problèmes de lock/DB).

Mode de panne B : corosync est arrêté ou le quorum est perdu

Dans un cluster, pmxcfs dépend des communications du cluster. Si corosync ne peut pas établir l’appartenance ou si le quorum est perdu,
pmxcfs peut passer en lecture seule, fonctionner partiellement, ou bloquer certaines opérations. Parfois /etc/pve monte quand même,
mais les écritures échouent et les outils de gestion se comportent comme s’ils marchaient dans du varech.

Mode de panne C : le stockage n’est pas revenu, et les services ont démarré quand même

Debian 13 apporte des comportements systemd plus récents et des changements de synchronisation, plus tout ce que votre matériel/firmware décide de faire cette semaine.
Un simple problème d’ordre de démarrage peut rendre le stockage « tardif » :

• Pools ZFS non auto-importés parce que le nommage des périphériques a changé ou un pool a été importé ailleurs en dernier.
• VG LVM non activé parce que les périphériques multipath apparaissent après la tentative d’activation.
• Montages NFS bloqués par un network-online qui ne signifie pas réellement « réseau utilisable ».
• Les connexions iSCSI non effectuées suffisamment tôt.

Le résultat est un chaos secondaire : stockages absents dans l’UI, VM qui ne démarrent pas, sauvegardes échouant, et des administrateurs diagnostiquant mal « Proxmox a mangé ma config ».
La configuration est toujours là ; ce sont les choses référencées qui sont absentes.

Mode de panne D : corruption de la base ou de l’état pmxcfs

Moins fréquent, mais réel. Coupure de courant soudaine, disque plein, RAM défectueuse, ou réglages agressifs du système de fichiers peuvent endommager les fichiers d’état.
Vous verrez des erreurs explicites sur la base pmxcfs, une incapacité à charger l’état, ou des crashs répétés.

Mode de panne E : vous êtes sur le mauvais nœud ou la mauvaise racine

J’ai vu des gens « réparer » un /etc/pve vide alors qu’ils étaient chrootés dans un environnement de secours, ou démarrés sur le mauvais volume root.
Le système de fichiers est sain ; l’opérateur n’est tout simplement pas sur le système qu’il croit.

Blague n°2 : Rien n’humilie autant un sysadmin que de réaliser qu’il a réparé le mauvais serveur pendant 20 minutes.

Tâches pratiques : commandes, signification et décisions

Ce sont des tâches réelles que vous pouvez exécuter sur une machine de production à 3 h du matin. Chaque élément inclut :
la commande, ce que la sortie signifie, et la décision à prendre.
Exécutez-les en root ou avec sudo si nécessaire.

Task 1: Verify /etc/pve is a mount (and what type)

cr0x@server:~$ findmnt -no TARGET,SOURCE,FSTYPE,OPTIONS /etc/pve
/etc/pve pmxcfs fuse rw,nosuid,nodev,relatime,user_id=0,group_id=0

Signification : Si vous voyez pmxcfs fuse, c’est monté et vivant. Si vous ne voyez rien ou qu’il indique ext4/xfs,
vous êtes sur le répertoire sous-jacent et pmxcfs n’est pas monté.

Décision : Si non monté, arrêtez de chercher des « fichiers manquants » et commencez à réparer pve-cluster/pmxcfs.

Task 2: Check whether pmxcfs is running and whether it crashed

cr0x@server:~$ systemctl status pve-cluster --no-pager
● pve-cluster.service - The Proxmox VE cluster filesystem
     Loaded: loaded (/lib/systemd/system/pve-cluster.service; enabled)
     Active: failed (Result: exit-code) since Sun 2025-12-28 02:41:18 UTC; 2min 9s ago
    Process: 813 ExecStart=/usr/bin/pmxcfs (code=exited, status=255/EXCEPTION)

Signification : Il n’est pas en cours ; il s’est terminé avec une erreur.

Décision : Récupérez les logs ensuite. Ne redémarrez pas au hasard — comprenez la cause (DB, lock, permissions, quorum).

Task 3: Read the pve-cluster logs for a direct reason

cr0x@server:~$ journalctl -u pve-cluster -b --no-pager -n 80
Dec 28 02:41:18 server pmxcfs[813]: [main] notice: starting pmxcfs
Dec 28 02:41:18 server pmxcfs[813]: [main] error: unable to open database '/var/lib/pve-cluster/config.db': Input/output error
Dec 28 02:41:18 server systemd[1]: pve-cluster.service: Main process exited, code=exited, status=255/EXCEPTION
Dec 28 02:41:18 server systemd[1]: pve-cluster.service: Failed with result 'exit-code'.

Signification : Ce n’est pas un problème de montage ; c’est un problème d’état/IO. Cet « Input/output error » peut venir du disque, du système de fichiers ou du stockage sous-jacent.

Décision : Vérifiez immédiatement la santé des disques et les erreurs système de fichiers ; évitez les redémarrages répétés qui pourraient aggraver la corruption.

Task 4: Confirm you’re on the expected root filesystem (not rescue, not the wrong LV)

cr0x@server:~$ findmnt -no TARGET,SOURCE,FSTYPE /
/ /dev/mapper/pve-root ext4

Signification : Vous êtes sur pve-root. Si vous voyez quelque chose comme /dev/sda1 de façon inattendue, ou un overlay live/rescue,
vous n’êtes pas là où vous pensez être.

Décision : Si mauvaise racine, arrêtez et démarrez le volume correct ; ne « réparez » pas les configs dans le mauvais environnement.

Task 5: Check corosync status and membership (clustered nodes)

cr0x@server:~$ systemctl status corosync --no-pager
● corosync.service - Corosync Cluster Engine
     Loaded: loaded (/lib/systemd/system/corosync.service; enabled)
     Active: active (running) since Sun 2025-12-28 02:39:02 UTC; 4min 25s ago

Signification : Corosync est actif. Cela ne garantit pas le quorum, mais c’est un début.

Décision : Si corosync est mort, corrigez le réseau/interfaces/firewall et la config corosync avant d’accuser pmxcfs.

Task 6: Check quorum explicitly

cr0x@server:~$ pvecm status
Cluster information
-------------------
Name:             prod-cluster
Config Version:   14
Transport:        knet
Secure auth:      on

Quorum information
------------------
Date:             Sun Dec 28 02:43:12 2025
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          0x00000001
Ring ID:          1.23
Quorate:          No

Signification : Pas de quorum. Dans cet état, de nombreuses opérations de cluster sont bloquées pour éviter le split-brain.

Décision : Rétablissez le quorum en remettant en ligne suffisamment de nœuds ou en corrigeant la connectivité. Évitez de « forcer » le quorum sauf si vous acceptez le risque.

Task 7: See whether pmxcfs is mounted read-only (a subtle gotcha)

cr0x@server:~$ findmnt -no TARGET,FSTYPE,OPTIONS /etc/pve
/etc/pve fuse rw,nosuid,nodev,relatime

Signification : Cela montre rw, donc au moins les flags de montage ne forcent pas le read-only.
Si vous voyez ro ou que les écritures échouent, vous avez probablement des problèmes de quorum ou d’IO sous-jacent.

Décision : Si lecture seule à cause du quorum, rétablissez le quorum. Si lecture seule due à des erreurs IO, réparez le stockage/système de fichiers.

Task 8: Confirm storage services didn’t fail during boot (systemd-wide triage)

cr0x@server:~$ systemctl --failed --no-pager
  UNIT                         LOAD   ACTIVE SUB    DESCRIPTION
● zfs-import-cache.service     loaded failed failed  Import ZFS pools by cache file
● pve-storage.service          loaded failed failed  Proxmox VE storage daemon

Signification : Vous avez des échecs concrets : import ZFS et pve-storage.

Décision : Corrigez l’import ZFS en premier ; puis redémarrez pve-storage et revérifiez les stockages.

Task 9: Check whether ZFS pools imported

cr0x@server:~$ zpool status
no pools available

Signification : Aucun pool importé. Cela cassera tout stockage défini sur ces pools.

Décision : Tentez un import sûr. Si des disques manquent, arrêtez et investiguez les chemins matériels/périphériques.

Task 10: Attempt ZFS pool import safely (read-only first if suspicious)

cr0x@server:~$ zpool import
   pool: rpool
     id: 1234567890123456789
  state: ONLINE
 action: The pool can be imported using its name or numeric identifier.
 config:

        rpool  ONLINE
          sda3 ONLINE

Signification : Le pool est importable.

Décision : Si c’est le pool de démarrage, importez normalement ; si vous suspectez des dommages, importez en lecture seule pour inspecter.

cr0x@server:~$ zpool import -f rpool
cr0x@server:~$ zpool status rpool
  pool: rpool
 state: ONLINE
config:

        NAME  STATE     READ WRITE CKSUM
        rpool ONLINE       0     0     0
          sda3 ONLINE       0     0     0

Signification : Le pool est de retour. Maintenant, les services dépendants ont une chance.

Décision : Redémarrez les services qui ont échoué à cause du ZFS manquant (typiquement pve-storage, parfois pvedaemon/pveproxy si dépendances).

Task 11: LVM cases — check if the VG is active

cr0x@server:~$ vgs
  VG  #PV #LV #SN Attr   VSize   VFree
  pve   1   3   0 wz--n- 930.00g 120.00g

Signification : Le VG existe. Si les attributs montrent qu’il est inactif ou manquant, l’activation au démarrage a échoué.

Décision : Si manquant, vérifiez la découverte des périphériques (multipath/RAID). Si présent mais inactif, activez-le.

Task 12: Activate LVM volumes (only if you know it’s safe)

cr0x@server:~$ vgchange -ay pve
  1 logical volume(s) in volume group "pve" now active

Signification : Les LV sont actifs ; les montages et services dépendants peuvent continuer.

Décision : Si l’activation échoue, n’utilisez pas la force. Investiguer les PV manquants, multipath, et dmesg.

Task 13: Networked storage cases — confirm network-online is real

cr0x@server:~$ systemctl status systemd-networkd-wait-online --no-pager
● systemd-networkd-wait-online.service - Wait for Network to be Configured
     Loaded: loaded (/lib/systemd/system/systemd-networkd-wait-online.service; enabled)
     Active: active (exited) since Sun 2025-12-28 02:38:40 UTC; 6min ago

Signification : Il dit « online », mais cela signifie seulement que les interfaces sont configurées, pas que votre gateway/DNS/VLAN de stockage est accessible.

Décision : Testez explicitement la reachabilité de l’endpoint de stockage.

Task 14: Verify NFS mounts and mount failures

cr0x@server:~$ findmnt -t nfs,nfs4
TARGET          SOURCE                 FSTYPE OPTIONS
/mnt/pve/backup nas01:/export/backup   nfs4   rw,relatime,vers=4.2,proto=tcp

Signification : Si le montage est absent, votre stockage n’est pas disponible. Si présent, cherchez ailleurs.

Décision : Si absent, consultez journalctl -b pour les erreurs de montage ; corrigez DNS, routage, firewall ou authentification.

Task 15: iSCSI cases — confirm sessions exist

cr0x@server:~$ iscsiadm -m session
tcp: [1] 10.10.20.50:3260,1 iqn.2003-01.org.linux-iscsi.nas01:storage.lun1 (non-flash)

Signification : La session existe. Si ceci est vide, les LUNs n’apparaîtront pas et LVM/ZFS-sur-iSCSI échoueront.

Décision : Si manquant, reloggez-vous et assurez-vous que l’ordre des services est correct (iscsid avant activation LVM).

Task 16: Check for obvious disk or filesystem errors behind pmxcfs DB issues

cr0x@server:~$ dmesg -T | tail -n 20
[Sun Dec 28 02:41:10 2025] blk_update_request: I/O error, dev sda, sector 194567890 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[Sun Dec 28 02:41:10 2025] EXT4-fs error (device dm-0): ext4_find_entry:1535: inode #262401: comm pmxcfs: reading directory lblock 0

Signification : Ce n’est pas « Proxmox qui fait n’importe quoi ». Le noyau vous dit que le stockage échoue.

Décision : Traitez cela comme un incident : arrêtez les écritures risquées, validez la couche disque/RAID/ZFS, et planifiez la réparation.

Task 17: Confirm /etc/pve content from the management layer

cr0x@server:~$ pvesh get /cluster/resources --type vm | head
vmid  status  name       node    type
100   running web-01     node1    qemu
101   stopped db-01      node1    qemu

Signification : Si pvesh peut lire les ressources du cluster, pmxcfs est probablement fonctionnel.

Décision : Si ceci échoue, concentrez-vous sur pmxcfs/corosync. Si ça fonctionne mais que les stockages sont absents, concentrez-vous sur la pile de stockage.

Task 18: Force a clean remount attempt (only after understanding why it failed)

cr0x@server:~$ systemctl restart pve-cluster
cr0x@server:~$ findmnt -no TARGET,SOURCE,FSTYPE /etc/pve
/etc/pve pmxcfs fuse

Signification : pmxcfs est monté à nouveau.

Décision : Revérifiez le quorum et le stockage. Ensuite, vérifiez que les configs attendues sont présentes avant de redémarrer des VM.

Task 19: Validate that node configs exist (not just the mount)

cr0x@server:~$ ls -la /etc/pve/nodes
total 0
drwxr-xr-x 1 root www-data  0 Dec 28 02:47 .
drwxr-xr-x 1 root www-data  0 Dec 28 02:47 ..
drwxr-xr-x 1 root www-data  0 Dec 28 02:47 node1

Signification : Le système de fichiers du cluster présente les nœuds. S’il est vide ou s’il manque votre nœud, c’est un problème d’appartenance/état du cluster.

Décision : Si le nœud manque, vérifiez l’appartenance corosync et la cohérence du hostname ; ne commencez pas à modifier les configs à l’aveugle.

Task 20: Identify boot ordering problems for mounts/services

cr0x@server:~$ systemd-analyze critical-chain pve-storage.service
pve-storage.service +3.201s
└─network-online.target +2.998s
  └─systemd-networkd-wait-online.service +2.950s
    └─systemd-networkd.service +1.102s
      └─systemd-udevd.service +0.421s

Signification : pve-storage attendait « network-online », qui peut ou non inclure la disponibilité de votre chemin de stockage.

Décision : Si vous dépendez d’iSCSI/NFS, assurez-vous que ces unités ont des dépendances explicites et des timeouts adaptés à la réalité.

Trois mini-récits du monde de l’entreprise (parce que ça arrive encore)

Mini-récit 1 : L’incident causé par une mauvaise hypothèse

Une entreprise de taille moyenne a migré deux nœuds hyperviseurs vers du nouveau matériel et a réutilisé les anciennes IP de management. La fenêtre de changement était serrée.
Quelqu’un a redémarré un nœud pour « vérifier les réglages du BIOS » et est revenu devant un /etc/pve vide. La panique s’est répandue rapidement car l’UI montrait des configs de VM manquantes.

La mauvaise hypothèse était simple : « Si /etc/pve est vide, la configuration est perdue sur le disque. »
Ils ont commencé à restaurer des sauvegardes aléatoires dans /etc et à éditer /etc/fstab pour « réparer les montages », ce qui n’avait rien à voir avec pmxcfs.
Sur un hôte Proxmox, c’est comme réparer un grille-pain en repeignant la cuisine.

Le vrai problème était corosync. Pendant la migration matérielle, l’équipe avait changé les noms d’interface (nommage prévisible),
mais laissé corosync.conf référencer l’ancienne NIC. Corosync n’a jamais formé l’appartenance, le quorum a été perdu, et pmxcfs n’est pas monté correctement.
Le répertoire « vide » n’était qu’un point de montage non monté.

La récupération a été propre une fois qu’ils ont arrêté de deviner : corriger le nommage des interfaces, redémarrer corosync, confirmer le quorum, redémarrer pve-cluster.
Tout est « réapparu » instantanément. Le seul dommage durable fut un lot de modifications manuelles à annuler.

La leçon : traitez /etc/pve comme un endpoint de service. S’il est vide, c’est une défaillance de service jusqu’à preuve du contraire.

Mini-récit 2 : L’optimisation qui s’est retournée contre eux

Une autre organisation avait pour habitude de grappiller des secondes au temps de démarrage partout où possible. Ça a commencé innocemment — désactiver des services inutiles,
réduire des timeouts, supprimer des « attentes superflues ». Ils ont réduit le timeout wait-online et parallélisé davantage le boot.
Leurs graphiques étaient plus jolis. Leur confiance a grandi pour remplir l’espace disponible.

Après un événement d’alimentation non planifié, plusieurs nœuds ont redémarré simultanément. Certains sont revenus propres ; d’autres montraient des stockages manquants,
et quelques-uns avaient le fameux aspect /etc/pve vide pendant le dépannage initial. La cause sous-jacente n’était pas mystique.

Les sessions iSCSI n’étaient pas encore établies lorsque l’activation LVM a eu lieu. LVM n’a vu aucun PV, donc il n’a pas activé le VG.
Des services dépendant de ces volumes ont démarré quand même et ont mis en cache un état « manquant ». Plus tard, quand iSCSI s’est finalement connecté,
personne n’a relancé proprement l’activation. Le système était « up », mais dans une demi-réalité.

La réparation a nécessité d’annuler l’« optimisation » : imposer un ordre entre le login iscsid et l’activation des volumes, et arrêter de prétendre
que network-ready signifie storage-ready. Ils ont aussi ajouté des retries ciblés pour le stockage, plutôt que des redémarrages aléatoires de toute la pile.

La leçon : la parallélisation au démarrage est excellente jusqu’à ce qu’elle interfère avec du stockage distribué qui se fiche de vos graphiques.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Un environnement réglementé (pensez : de la paperasse qui mord) faisait tourner un cluster Proxmox avec un contrôle des changements strict.
Ils faisaient deux choses peu glamour systématiquement : (1) sauvegardes nocturnes des configs de /etc/pve et des configs hôtes critiques,
et (2) exercices trimestriels de reprise après sinistre où quelqu’un d’autre que l’opérateur habituel restaurait un nœud.

Un nœud a redémarré après une mise à jour du noyau et n’a pas monté pmxcfs à cause d’une erreur disque sous-jacente qui a corrompu le fichier de base pmxcfs.
Ce n’était pas une situation de « redémarrer le service ». L’état local du nœud était peu fiable.

Leur réponse a été ennuyeuse et rapide. Ils ont mis le nœud en maintenance, confirmé que le cluster restait quorate sans celui-ci,
remplacé le disque défaillant, réinstallé l’OS du nœud, l’ont réintégré au cluster, et restauré seulement la configuration locale minimale requise.
Les définitions de VM étaient toujours en sécurité dans le cluster ; les définitions de stockage ont été revérifiées plutôt que réimportées aveuglément.

Le résultat final : une panne de nœud, aucune perte de données VM, pas d’archéologie de config à 3 h du matin.
La partie la plus « excitante » a été de regarder quelqu’un suivre un runbook ligne par ligne et finir plus tôt.

La leçon : les sauvegardes de routine + la pratique de restauration battent la « mémoire tribale » à chaque fois.

Erreurs courantes : symptôme → cause racine → fix

1) Symptom: /etc/pve is empty after reboot

Cause racine : pmxcfs non monté (pve-cluster a échoué) ou vous êtes dans le répertoire sous-jacent.

Fix : findmnt /etc/pve et systemctl status pve-cluster. Corrigez la cause dans les logs, puis redémarrez pve-cluster.

2) Symptom: /etc/pve is present but writes fail (permission denied / read-only)

Cause racine : Cluster non quorate ; pmxcfs peut refuser les écritures pour éviter le split-brain.

Fix : Rétablir le quorum (remettre les nœuds en ligne, corriger le réseau corosync). Ne « forcez » pas le quorum sans comprendre le rayon d’impact.

3) Symptom: UI shows missing storages, VMs won’t start, but /etc/pve is fine

Cause racine : Stockage non prêt : ZFS non importé, LVM non actif, NFS/iSCSI non monté/connecté.

Fix : Diagnostiquer d’abord la couche stockage (zpool status, vgs, findmnt, iscsiadm).
Puis redémarrer pve-storage et valider les définitions de stockage.

4) Symptom: pve-cluster fails with DB errors

Cause racine : Erreurs IO disque, corruption du système de fichiers, ou corruption de la base pmxcfs.

Fix : Arrêtez de thrasher le service. Vérifiez dmesg pour erreurs IO et réparez le système de fichiers/matériel sous-jacent.
Récupérez l’état pmxcfs depuis un nœud sain ou des sauvegardes si nécessaire.

5) Symptom: Everything works until you reboot; then it breaks again

Cause racine : Ordre de démarrage/conditions de course dans systemd ; dépendances manquantes pour le stockage réseau ou périphériques lents.

Fix : Utilisez systemd-analyze critical-chain. Ajoutez des dépendances unitaires et des timeouts appropriés.
Évitez les hacks du type « sleep 30 » sauf si vous aimez vivre dans le passé.

6) Symptom: Empty /etc/pve when booted into rescue ISO

Cause racine : Vous n’êtes pas démarré dans le système installé. pmxcfs n’est pas en cours. Bien sûr que c’est vide.

Fix : Montez le vrai root et chrootez uniquement si nécessaire ; sinon démarrez normalement et dépannez là.

7) Symptom: Node name changed; cluster looks “new”

Cause racine : Incohérence du hostname avec la config du cluster ; les chemins pmxcfs sont basés sur le nom du nœud.

Fix : Restaurez le hostname correct et la résolution hosts ; assurez-vous que corosync et Proxmox voient le nom de nœud attendu.

Listes de contrôle / plan pas à pas

Checklist A: “/etc/pve is empty” recovery steps (safe and fast)

1. Confirmer le montage : findmnt /etc/pve.
   Si pas pmxcfs, considérez-le comme une défaillance de service.
2. Vérifier pve-cluster : systemctl status pve-cluster et journalctl -u pve-cluster -b.
   Les logs indiquent généralement ce qui ne va pas. Croyez-les.
3. Vérifier le cluster : systemctl status corosync et pvecm status.
   Si pas quorate, rétablissez le quorum avant d’essayer d’écrire des configs.
4. Vérifier le stockage : systemctl --failed, puis valider ZFS/LVM/NFS/iSCSI selon le cas.
   Corrigez la disponibilité du stockage (imports, activations, montages).
5. Redémarrer dans le bon ordre :
   d’abord les services de stockage (zfs-import, iscsid, remote-fs), puis pve-storage, ensuite pve-cluster si nécessaire.
6. Valider : ls /etc/pve, pvesh get /cluster/resources, et confirmer que les stockages apparaissent.
7. Ce n’est qu’après : démarrer les VM ou réactiver les ressources HA.

Checklist B: When to stop and declare a hardware/storage incident

1. dmesg montre des erreurs I/O, des réinitialisations, ou des erreurs système de fichiers.
2. SMART/RAID signale des arrays dégradés ou des erreurs média (outils vendor recommandés).
3. Des erreurs DB pmxcfs coïncident avec des erreurs disque noyau.
4. Le problème revient après « correction » des services sans aucun changement de config.

Si l’un de ces points est vrai, votre priorité est l’intégrité des données et la stabilité, pas « avoir des voyants verts dans l’UI ».

Checklist C: Preventing the reboot surprise (the boring controls that work)

1. Ajoutez des dépendances systemd explicites pour votre pile de stockage (iSCSI avant LVM, reachabilité réseau avant NFS).
2. Évitez les chemins de périphériques fragiles ; préférez des identifiants stables (WWN, by-id). Si vous utilisez multipath, rendez-le déterministe.
3. Assurez-vous que le cluster a un nombre impair de votants ou un dispositif de quorum adapté.
4. Gardez des sauvegardes de /etc/pve et testez les restaurations selon un calendrier, pas pendant un incident.
5. Drills de redémarrage : redémarrez un nœud pendant les heures ouvrables occasionnellement. Si cela vous effraie, c’est justement le but.

Faits intéressants et contexte historique

• pmxcfs est un système de fichiers FUSE. C’est pourquoi /etc/pve peut « disparaître » sans rien supprimer — c’est un point de montage pour un processus en espace utilisateur.
• La prévention du split-brain guide la conception. Les stacks de cluster bloquent souvent les écritures sans quorum car l’alternative est de corrompre silencieusement l’état à travers les nœuds.
• Corosync est un pilier du HA Linux depuis des années. Il sert de couche de messagerie de cluster dans plusieurs écosystèmes HA, pas seulement Proxmox.
• systemd a changé la façon de penser l’ordre de démarrage. Le passage des scripts séquentiels à l’activation parallèle des unités a rendu les conditions de course plus fréquentes — et plus subtiles.
• network-online n’est pas la même chose que network-reachable. systemd peut déclarer la victoire alors que votre VLAN de stockage est encore en négociation, que le routage manque ou que le DNS est erroné.
• Les imports ZFS sont conservateurs par conception. ZFS refusera d’auto-importer des pools dans certaines circonstances pour éviter d’importer le même pool sur plusieurs systèmes à la fois.
• Les points de montage ne sont que des répertoires jusqu’à leur montage. Linux vous montre volontiers un point de montage vide ; il ne vous prévient pas « ceci est normalement un autre système de fichiers ».
• La localisation de la config du cluster est un compromis. Centraliser la config améliore la cohérence mais augmente l’exigence de quorum et de santé du cluster ; voilà pourquoi les comportements de repli locaux peuvent être limités.
• La disponibilité du stockage au démarrage est un problème multi-couches. Firmware, initialisation HBA, multipath, udev, réseau, authentification et import du système de fichiers doivent tous s’aligner.

FAQ

1) Is my Proxmox configuration actually deleted if /etc/pve is empty?

Habituellement non. La situation la plus courante est que pmxcfs ne s’est pas monté, donc vous voyez le répertoire sous-jacent vide.
Confirmez avec findmnt /etc/pve.

2) Why does this show up after a reboot and not during normal runtime?

Les redémarrages redistribuent le timing : découverte des périphériques, disponibilité réseau, appartenance au cluster, et ordre des services.
Les courses au démarrage sont polis pendant le runtime et impolis au boot.

3) Can I just recreate /etc/pve and copy files back?

Ne le faites pas. /etc/pve est un point de montage pour pmxcfs. Copier des fichiers dans le répertoire sous-jacent ne résoudra pas le vrai problème,
et peut compliquer le dépannage futur.

4) What if pmxcfs is mounted but the GUI still looks wrong?

Dans ce cas, concentrez-vous sur le quorum et la santé de corosync, ou sur la disponibilité du stockage. Un pmxcfs monté signifie que l’endpoint du système de fichiers existe ;
cela ne garantit pas que les opérations de cluster sont permises ou que les stockages sont disponibles.

5) Is it safe to restart pve-cluster and corosync on a production node?

Ça peut l’être, mais seulement après avoir compris l’état actuel du cluster. Redémarrer corosync sur le mauvais nœud au mauvais moment peut aggraver une panne.
Si le cluster est quorate sans ce nœud, isolez-le et corrigez-le sans déstabiliser le reste.

6) My cluster is “not quorate.” Can I force it?

Vous pouvez, et vous pourriez le regretter. Forcer le quorum peut permettre des écritures qui provoquent un split-brain lorsque l’autre partition revient.
Ne le faites que si vous avez confirmé que l’autre côté est réellement parti et que vous acceptez le travail de réconciliation ensuite.

7) Why do storage failures make /etc/pve look empty?

Ils ne le font pas directement — pmxcfs est séparé. Mais les pannes de stockage coïncident souvent avec des courses de démarrage et des échecs de services,
et produisent des symptômes similaires : disques VM manquants, stockages absents, services échoués, et une sensation générale que la réalité est optionnelle.

8) What’s the single most useful first command?

findmnt /etc/pve. Il vous dit si vous traitez un problème de montage/service ou si vous poursuivez des fantômes dans un répertoire vide.

9) How do I prevent this from recurring on Debian 13?

Rendre l’ordre de démarrage explicite pour les dépendances de stockage, garantir un nommage de périphérique stable, valider les interfaces corosync après les upgrades,
et tester les redémarrages comme si vous en aviez besoin.

10) If pmxcfs DB is corrupted, do I need to reinstall?

Pas toujours, mais parfois réinstaller et rejoindre le cluster est la voie la plus propre — surtout si vous avez aussi des erreurs disque.
Traitez la corruption accompagnée d’erreurs IO comme un problème matériel/stockage en priorité.

Conclusion : prochaines étapes qui empêchent vraiment les récidives

Quand /etc/pve semble vide après un redémarrage sur Debian 13, supposez d’abord un problème de montage/service, pas une perte de données.
Confirmez si pmxcfs est monté. Lisez les logs. Vérifiez le quorum. Ensuite, vérifiez la disponibilité du stockage et l’ordre systemd.
Cette séquence fait gagner des heures parce qu’elle réduit rapidement le domaine de la panne.

Prochaines étapes pratiques :

1. Exécutez la tactique de diagnostic rapide et notez ce qui a échoué (pmxcfs, corosync/quorum, ZFS/LVM, montages distants).
2. Si le problème est un ordre de démarrage, corrigez-le avec des dépendances systemd appropriées — pas des hacks « sleep ».
3. Si vous voyez des erreurs IO, considérez-le comme un incident de stockage et arrêtez de « redémarrer jusqu’à ce que ça marche ».
4. Planifiez un drill de redémarrage et un drill de restauration de configuration. Le jour où vous vous entraînez est le jour où vous restez calme.