Rien ne pimente une permanence comme un nœud Proxmox qui ne démarre plus après une mise à jour de routine. Une minute vous appliquez des correctifs pour la « sécurité », la suivante vous fixez un prompt grub, un écran noir, ou une console qui boucle sur des erreurs dracut/initramfs pendant que vos VM cessent discrètement de « payer le loyer ».
Voici un guide de terrain pour ramener ce nœud sans empirer la situation. Nous ferons un rollback de noyaux, réparerons les chargeurs de démarrage, récupérerons les stockages ZFS/LVM et réintégrerons le nœud au cluster sans transformer un problème mono‑nœud en crise de tout un datacenter.
Feuille de route pour un diagnostic rapide
Si vous ne retenez rien d’autre : votre objectif est de localiser la première défaillance réelle dans la chaîne de démarrage, pas le dernier message d’erreur affiché. Les échecs de démarrage affichent souvent des « symptômes » loin de la cause.
Première étape : la machine atteint‑elle un prompt de connexion ?
- Non, bloquée avant le noyau (prompt GRUB / shell EFI) : c’est le domaine du chargeur de démarrage/ESP. Allez à Réparer GRUB et les problèmes d’EFI.
- Non, kernel panic ou impossible de monter la racine : probablement initramfs, pilote de stockage manquant, ou UUID de root erroné. Passez à Initramfs et Stockage.
- Oui, mais les services sont cassés (pvedaemon, pveproxy, cluster) : considérez cela comme un « démarrage réussi, pile Proxmox en échec ». Allez à Tâches pratiques et Récupération de cluster.
Deuxième étape : le stockage est‑il présent et importé ?
- Racine ZFS ou stockage VM ZFS manquant : vérifiez l’import du pool, hostid, cachefile et noms de périphériques. ZFS dit généralement la vérité, directement.
- LVM‑thin manquant : vérifiez l’activation PV/VG, udev settle, et si l’initramfs contient les bons modules pour votre HBA/NVMe.
Troisième étape : le nœud est‑il sûr à réintégrer au cluster ?
- Nœud unique dans un cluster et il est down : ne « corrigez » pas le quorum en supprimant des fichiers au hasard. Confirmez quel nœud est la source de vérité pour l’état du cluster.
- Deux nœuds down : présumez le risque de split‑brain. Faites une pause, choisissez une source de vérité et procédez délibérément.
Et oui, vous pouvez passer deux heures à « déboguer le réseau » alors que le vrai problème est que le système de fichiers racine a été monté en lecture seule après la relecture du journal. Vu, vécu.
Faits et contexte intéressants (pourquoi ça revient)
- Proxmox VE repose sur la plomberie de Debian. Quand vous mettez à jour Proxmox, vous mettez à jour un système Debian plus une pile sélectionnée : noyaux, QEMU, LXC, ZFS et daemons de gestion.
- Avoir plusieurs noyaux installés est une fonctionnalité, pas un encombrement. Le packaging façon Debian conserve typiquement d’anciens noyaux pour pouvoir redémarrer sur un état connu. Supprimer tous les noyaux sauf un, c’est comme vendre votre roue de secours pour gagner du poids.
- initramfs a été conçu pour résoudre les problèmes de « pilotes trop tôt ». Les systèmes modernes ont besoin de modules de stockage et de chiffrement avant que la racine « réelle » n’existe ; initramfs est cet espace utilisateur précoce.
- UEFI a changé les modes de panne. Les anciennes pannes BIOS+MBR étaient souvent « GRUB est mort ». Avec UEFI, vous pouvez avoir un OS en bon état et une partition système EFI (ESP) cassée, une entrée NVRAM manquante, ou une chaîne shim défaillante.
- ZFS est conservateur par défaut, mais implacable sur l’identité. Un hostid différent ou un cachefile obsolète peut empêcher l’auto‑import au démarrage, surtout après un clonage de disques ou un déplacement de pools entre machines.
- Le quorum Corosync est volontairement têtu. Il est conçu pour vous empêcher de faire tourner un cluster en split‑brain même si la journée est productive.
- L’interface web de Proxmox n’est qu’un client. Quand un nœud « semble mort » dans le navigateur, c’est peut‑être juste
pveproxyqui est down alors que les VM tournent en dessous. - Les mises à jour du noyau peuvent casser des modules hors‑arbre. NVIDIA, certains HBA avec pilotes constructeurs, et les modules construits par DKMS peuvent échouer à la compilation, vous laissant sans pilotes nécessaires au démarrage.
Une idée de fiabilité à taper sur votre écran : l’espoir n’est pas une stratégie
— souvent attribuée, de façon paraphrasée, à James Cameron dans les cercles opérationnels, répétée quand les équipes remplacent l’optimisme par des plans de rollback.
Règles de sécurité avant toute intervention
Le travail de récupération est l’endroit où les bons ingénieurs deviennent des pyromanes accidentels. La façon la plus simple de perdre des données est de « réparer » vite sur le mauvais nœud, sur les mauvais disques, avec de mauvaises hypothèses.
Règles que je respecte réellement
- Privilégier les changements réversibles. Démarrer sur un noyau plus ancien est réversible. Réinstaller GRUB est généralement réversible. « Effacer et réinstaller Proxmox » n’est pas un plan de récupération ; c’est une confession.
- Notez ce que vous changez. Des notes horodatées valent mieux que la mémoire héroïque.
- Ne réintégrez pas un nœud au cluster tant qu’il n’est pas stable. L’adhésion au cluster multiplie les erreurs.
- Considérez votre stockage comme innocent tant que l’on n’a pas prouvé le contraire. Les problèmes de démarrage ressemblent souvent à des problèmes de disque. Ne commencez pas à effacer des pools parce que l’initramfs ne voit pas un HBA.
- Obtenez un accès console. IPMI/iKVM/console physique. SSH est génial jusqu’au moment où il ne l’est plus.
Blague #1 : La seule chose plus permanente qu’un contournement temporaire est un contournement temporaire fait sous pression.
Modes de panne après une mise à jour Proxmox
« Échec après mise à jour » signifie habituellement une de ces catégories :
- Rupture du chargeur de démarrage/EFI : menu GRUB manquant, entrée UEFI perdue, ESP non montée, ou initrd introuvable.
- Noyau boot, racine non montée : pilote de stockage manquant, UUID de root incorrect, initramfs cassé, racine chiffrée non déverrouillée.
- Système démarre, pile Proxmox en échec : services pve ne démarrent pas, systèmes de fichiers cluster bloqués, corosync en panne, problèmes de certificats ou permissions.
- Système démarre, réseau cassé : bridges non montés, mode de bond incompatible après mise à jour du pilote, MTU mal aligné, renommage d’interfaces prévisible.
- Système démarre, stockage manquant : pools ZFS non importés, volumes LVM non activés, confusion multipath, arrays dégradés causant des timeouts.
Le truc est de catégoriser rapidement la panne. Ensuite, choisissez la correction la moins invasive qui restaure le service.
Tâches pratiques de récupération avec commandes, sorties et décisions
Ci‑dessous des tâches opérationnelles à exécuter sur un nœud cassé ou depuis un mode rescue/chroot. Chaque tâche inclut ce que la sortie signifie et la décision à prendre ensuite.
Tâche 1 : Identifier quel noyau vous avez booté (ou tenté)
cr0x@server:~$ uname -a
Linux pve01 6.8.12-4-pve #1 SMP PREEMPT_DYNAMIC PMX 6.8.12-4 (2025-02-10T12:00Z) x86_64 GNU/Linux
Sens : Confirme la version du noyau en cours. Si vous exécutez le noyau le plus récent et que ça casse, le rollback est votre première option.
Décision : Si l’échec coïncide avec un saut de noyau, essayez de démarrer sur un noyau plus ancien depuis GRUB et épinglez‑le temporairement.
Tâche 2 : Lister les noyaux installés et les paquets noyau Proxmox
cr0x@server:~$ dpkg -l | egrep 'pve-kernel|linux-image' | awk '{print $1,$2,$3}'
ii pve-kernel-6.5.13-5-pve 6.5.13-5
ii pve-kernel-6.8.12-4-pve 6.8.12-4
ii proxmox-kernel-helper 8.1.1
Sens : Vous avez au moins un noyau plus ancien installé. C’est une bouée de sauvetage.
Décision : Si un noyau plus ancien existe, essayez‑le d’abord. Sinon, il faudra en installer un (peut‑être depuis rescue/chroot).
Tâche 3 : Vérifier si le système est passé en mode emergency et pourquoi
cr0x@server:~$ systemctl --failed
UNIT LOAD ACTIVE SUB DESCRIPTION
pve-cluster.service loaded failed failed The Proxmox VE cluster filesystem
corosync.service loaded failed failed Corosync Cluster Engine
Sens : L’OS est monté, mais les services cluster ont échoué. Cela peut bloquer la gestion Proxmox et même certaines opérations de VM dépendant du FS de cluster.
Décision : Ne redémarrez pas aveuglément. Récupérez les logs de l’unité en échec et décidez d’isoler le nœud (mode local) ou de réparer corosync.
Tâche 4 : Inspecter le journal pour la première vraie défaillance
cr0x@server:~$ journalctl -b -p err --no-pager | head -n 30
Feb 12 09:14:51 pve01 systemd[1]: Failed to start The Proxmox VE cluster filesystem.
Feb 12 09:14:51 pve01 pmxcfs[1203]: [main] unable to open cluster database (Connection refused)
Feb 12 09:14:51 pve01 corosync[1188]: [TOTEM ] Failed to bind to multicast address
Feb 12 09:14:51 pve01 corosync[1188]: [MAIN ] Corosync Cluster Engine exiting with status '2'
Sens : Ce n’est pas « Proxmox est cassé », c’est un problème de binding corosync, souvent lié au réseau (noms d’interfaces, IP modifiée, MTU, pare‑feu).
Décision : Vérifiez les interfaces réseau et la config corosync avant de toucher au stockage ou de réinstaller des paquets.
Tâche 5 : Confirmer que le nommage des interfaces n’a pas changé sous vos pieds
cr0x@server:~$ ip -br link
lo UNKNOWN 00:00:00:00:00:00
enp4s0 UP 3c:ec:ef:12:34:56
enp5s0 DOWN 3c:ec:ef:12:34:57
vmbr0 DOWN 3c:ec:ef:12:34:56
Sens : Le bridge est down. Ça peut être aussi simple que la NIC sous‑jacente qui est down ou la config du bridge qui n’a pas été appliquée.
Décision : Vérifiez /etc/network/interfaces et tentez un redémarrage réseau contrôlé (ou montez le bridge manuellement) avant d’accabler corosync.
Tâche 6 : Valider que Proxmox monte /etc/pve (pmxcfs)
cr0x@server:~$ mount | grep /etc/pve
Sens : Aucune sortie signifie que pmxcfs n’est pas monté ; le système de fichiers de cluster n’est pas opérationnel.
Décision : Si vous avez besoin d’une récupération locale, vous pouvez démarrer Proxmox en état « sans cluster » temporairement (couvert plus loin). Si c’est multi‑nœud, réparez corosync d’abord.
Tâche 7 : Vérifier la visibilité des disques et l’état des pilotes noyau
cr0x@server:~$ lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS
sda 1.8T disk
├─sda1 512M part vfat /boot/efi
├─sda2 1G part ext4 /boot
└─sda3 1.8T part
└─pve-root 96G lvm /
nvme0n1 1.7T disk zfs_member
nvme1n1 1.7T disk zfs_member
Sens : Les disques sont présents ; EFI et partitions de boot sont montées ; membres ZFS visibles. Cela réduit les chances d’un « matériel disparu ».
Décision : Si des périphériques manquent, suspectez le noyau/HBA module/initramfs. Si présents mais pools/volumes manquent, concentrez‑vous sur l’import/activation.
Tâche 8 : Vérifier l’état d’import des pools ZFS (si vous utilisez ZFS)
cr0x@server:~$ zpool import
pool: tank
id: 1234567890123456789
state: ONLINE
action: The pool can be imported using its name or numeric identifier.
config:
tank ONLINE
mirror-0 ONLINE
nvme0n1 ONLINE
nvme1n1 ONLINE
Sens : Le pool existe mais n’est pas importé. Le boot a peut‑être sauté l’auto‑import à cause d’un hostid différent ou du timing.
Décision : Importez en lecture‑écriture seulement si vous êtes sûr que ce nœud est le bon propriétaire. En cas de doute (stockage partagé, disques déplacés), importez en lecture seule d’abord.
Tâche 9 : Importer le pool ZFS prudemment et définir le cachefile pour futurs boots
cr0x@server:~$ zpool import -o cachefile=/etc/zfs/zpool.cache tank
cr0x@server:~$ zpool status tank
pool: tank
state: ONLINE
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
nvme0n1 ONLINE 0 0 0
nvme1n1 ONLINE 0 0 0
errors: No known data errors
Sens : Pool importé et sain. Définir le cachefile aide l’initramfs/séquence de boot à localiser les pools de façon fiable.
Décision : Si l’import échoue à cause d’un hostid, traitez le hostid plutôt que de forcer des imports répétés.
Tâche 10 : Vérifier l’état LVM (si vous utilisez LVM‑thin)
cr0x@server:~$ pvs
PV VG Fmt Attr PSize PFree
/dev/sda3 pve lvm2 a-- <1.82t 0
cr0x@server:~$ vgs
VG #PV #LV #SN Attr VSize VFree
pve 1 3 0 wz--n- <1.82t 0
cr0x@server:~$ lvs -a
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
data pve twi-aotz-- <1.60t 72.11 2.40
root pve -wi-ao---- 96.00g
swap pve -wi-ao---- 8.00g
Sens : PV/VG/LVs existent et sont actifs (ao). Si des VGs sont manquants ou inactifs, l’activation du stockage est votre problème.
Décision : Si inactif, essayez vgchange -ay et inspectez dmesg pour des erreurs de périphérique avant de forcer des réparations.
Tâche 11 : Valider l’espace libre sur /boot et l’ESP (les mises à jour échouent silencieusement si /boot est plein)
cr0x@server:~$ df -h /boot /boot/efi
Filesystem Size Used Avail Use% Mounted on
/dev/sda2 1007M 983M 24M 98% /boot
/dev/sda1 511M 12M 500M 3% /boot/efi
Sens : /boot est presque plein. Cela peut produire des installations d’initramfs/noyaux incomplètes et un comportement de boot étrange.
Décision : Supprimez proprement les anciens noyaux (après avoir un boot connu‑bon) ou étendez /boot. Ne supprimez pas des fichiers au hasard dans /boot comme en 1999.
Tâche 12 : Vérifier les échecs de build DKMS/modules qui cassent des pilotes
cr0x@server:~$ journalctl -b --no-pager | grep -E 'dkms|module|firmware' | tail -n 20
Feb 12 09:10:22 pve01 kernel: i915 0000:00:02.0: firmware: failed to load i915/skl_dmc_ver1_27.bin (-2)
Feb 12 09:10:25 pve01 dkms[842]: Error! Bad return status for module build on kernel: 6.8.12-4-pve (x86_64)
Feb 12 09:10:25 pve01 dkms[842]: Consult /var/lib/dkms/.../build/make.log for more information.
Sens : Un module DKMS a échoué à la compilation. Si ce module est requis pour le stockage ou le réseau, le boot peut réussir mais les périphériques ne fonctionneront pas.
Décision : Faites un rollback du noyau ou corrigez la compilation DKMS. Si c’est non critique (par ex. GPU sur un hôte sans écran), masquez le bruit mais ne négligez pas les erreurs DKMS liées au stockage.
Tâche 13 : Confirmer la santé des services Proxmox (si l’OS boot mais l’UI est morte)
cr0x@server:~$ systemctl status pveproxy pvedaemon pvestatd --no-pager
● pveproxy.service - PVE API Proxy Server
Loaded: loaded (/lib/systemd/system/pveproxy.service; enabled)
Active: active (running) since Wed 2025-02-12 09:18:02 UTC; 2min ago
● pvedaemon.service - PVE API Daemon
Loaded: loaded (/lib/systemd/system/pvedaemon.service; enabled)
Active: active (running) since Wed 2025-02-12 09:18:00 UTC; 2min ago
● pvestatd.service - PVE Status Daemon
Loaded: loaded (/lib/systemd/system/pvestatd.service; enabled)
Active: active (running) since Wed 2025-02-12 09:18:01 UTC; 2min ago
Sens : Les services cœur sont opérationnels. Si l’UI web échoue encore, suspectez le pare‑feu, les certificats, ou du cache client.
Décision : Si les services sont down, vérifiez les dépendances : montage /etc/pve, résolution DNS/hostname, dérive de l’heure, disque plein.
Tâche 14 : Vérifier l’état du cluster et du quorum sans deviner
cr0x@server:~$ pvecm status
Cluster information
-------------------
Name: prod-cluster
Config Version: 43
Transport: knet
Secure auth: on
Quorum information
------------------
Date: Wed Feb 12 09:21:12 2025
Quorum provider: corosync_votequorum
Nodes: 3
Node ID: 0x00000001
Ring ID: 1.2
Quorate: Yes
Sens : Le quorum est présent. Cela change votre marge de manœuvre : vous pouvez réparer ce nœud sans réécrire l’état du cluster.
Décision : Si Quorate: No, évitez les changements qui requièrent des écritures dans le cluster ; envisagez le mode local temporaire ou une stratégie de restauration du quorum.
Rollback du noyau : la solution la moins dramatique
Quand un nœud Proxmox tombe en panne juste après une mise à jour, supposez que le noyau le plus récent est coupable jusqu’à preuve du contraire. Faire un rollback est généralement rapide, sûr et réversible. Cela vous donne aussi du temps pour déboguer correctement.
Démarrer un noyau plus ancien depuis GRUB
Au démarrage, choisissez Options avancées et sélectionnez le pve-kernel précédent. Si vous n’arrivez pas à atteindre GRUB parce que l’écran passe trop vite, maintenez Shift sur les systèmes BIOS ou appuyez sur Esc sur beaucoup de systèmes UEFI pendant le boot.
Épingler le noyau connu‑bon (temporaire)
Une fois démarré sur le noyau fonctionnel, empêchez le système de « vous aider » en revenant au prochain reboot.
cr0x@server:~$ proxmox-boot-tool kernel list
Manually selected kernels:
None.
Automatically selected kernels:
6.8.12-4-pve
6.5.13-5-pve
Pinned kernel:
None.
Sens : Aucun noyau épinglé ; la sélection par défaut peut préférer le plus récent.
Décision : Épinglez le noyau qui fonctionne jusqu’à ce que l’enquête soit terminée.
cr0x@server:~$ proxmox-boot-tool kernel pin 6.5.13-5-pve
Pinned kernel version '6.5.13-5-pve'
Si vous n’êtes pas sur un setup géré par proxmox-boot-tool, vous pouvez aussi contrôler les défauts GRUB, mais l’épinglage via l’outil Proxmox est généralement plus propre quand disponible.
Reconstruire l’initramfs et rafraîchir GRUB après le rollback
Même si l’ancien noyau boot, rafraîchissez les artefacts de boot pour ne pas retomber sur des initramfs partiellement écrits.
cr0x@server:~$ update-initramfs -u -k 6.5.13-5-pve
update-initramfs: Generating /boot/initrd.img-6.5.13-5-pve
Sens : initramfs reconstruit pour le noyau choisi.
Décision : Si cela échoue à cause d’un /boot plein, arrêtez et corrigez la capacité de /boot avant de continuer.
cr0x@server:~$ update-grub
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.8.12-4-pve
Found initrd image: /boot/initrd.img-6.8.12-4-pve
Found linux image: /boot/vmlinuz-6.5.13-5-pve
Found initrd image: /boot/initrd.img-6.5.13-5-pve
done
Sens : GRUB voit les deux noyaux et initrd.
Décision : Redémarrez une fois que vous avez épinglé/sélectionné le noyau de confiance et confirmez qu’il reste sélectionné.
Réparer GRUB et les problèmes d’EFI
Si vous atterrissez dans un prompt GRUB, un shell EFI, ou « aucun périphérique bootable », vous ne déboguez plus Proxmox. Vous déboguez la chaîne de boot. Traitez‑le comme une procédure chirurgicale : vérifiez les disques, vérifiez les partitions, montez correctement, puis réinstallez le chargeur de démarrage.
Décider : BIOS/MBR ou UEFI ?
cr0x@server:~$ [ -d /sys/firmware/efi ] && echo UEFI || echo BIOS
UEFI
Sens : Cet hôte est démarré en mode UEFI (ou devrait l’être).
Décision : Concentrez‑vous sur la partition système EFI à /boot/efi et les entrées NVRAM UEFI.
Vérifier que l’ESP est présent et montable
cr0x@server:~$ lsblk -f | grep -E 'vfat|EFI|/boot/efi'
sda1 vfat FAT32 7A3B-1C2D /boot/efi
Sens : L’ESP existe et est montée. Si elle manque ou n’est pas montable, vous ne pouvez pas réinstaller GRUB de manière fiable.
Décision : Si non montée, montez‑la. Si le montage échoue, lancez des vérifications de système de fichiers depuis le mode rescue.
Valider les entrées de boot UEFI
cr0x@server:~$ efibootmgr -v
BootCurrent: 0002
Timeout: 1 seconds
BootOrder: 0002,0001
Boot0001* UEFI OS HD(1,GPT,...)File(\EFI\BOOT\BOOTX64.EFI)
Boot0002* proxmox HD(1,GPT,...)File(\EFI\proxmox\grubx64.efi)
Sens : L’entrée de boot existe et pointe vers un binaire GRUB Proxmox EFI. Si elle pointe vers nulle part, vous tomberez dans un shell EFI.
Décision : Si elle manque, réinstallez GRUB sur l’ESP et recréez l’entrée de boot.
Réinstaller GRUB sur UEFI
cr0x@server:~$ grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=proxmox
Installing for x86_64-efi platform.
Installation finished. No error reported.
Sens : Les binaires GRUB EFI sont placés sur l’ESP.
Décision : Suivez par update-grub et vérifiez l’entrée avec efibootmgr.
cr0x@server:~$ update-grub
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.5.13-5-pve
Found initrd image: /boot/initrd.img-6.5.13-5-pve
done
Si vous avez besoin du mode rescue + chroot (fréquent)
Quand le nœud ne peut pas démarrer du tout, démarrez depuis un ISO rescue, montez votre système root, et chroot. Les étapes exactes dépendent si la racine est LVM ou ZFS. Voici un flux représentatif pour racine LVM.
cr0x@server:~$ vgscan
Found volume group "pve" using metadata type lvm2
cr0x@server:~$ vgchange -ay
3 logical volume(s) in volume group "pve" now active
cr0x@server:~$ mount /dev/pve/root /mnt
cr0x@server:~$ mount /dev/sda2 /mnt/boot
cr0x@server:~$ mount /dev/sda1 /mnt/boot/efi
cr0x@server:~$ for i in /dev /dev/pts /proc /sys /run; do mount --bind $i /mnt$i; done
cr0x@server:~$ chroot /mnt /bin/bash
Sens : Vous opérez maintenant à l’intérieur de l’OS installé, là où les outils GRUB et initramfs s’attendent à fonctionner.
Décision : Réinstallez noyau/initramfs/GRUB depuis le chroot ; ensuite quittez, démontez proprement, et redémarrez.
Initramfs, modules manquants et pilotes de stockage
Le classique « brique après mise à jour » : le noyau démarre, puis ne trouve pas le système de fichiers root. Vous voyez des messages du type « waiting for root device », « unable to mount root fs », ou vous tombez dans un shell initramfs.
Cela vient souvent de :
- initramfs n’a pas été généré correctement (espace plein, mise à jour interrompue).
- Les modules requis pour votre contrôleur de stockage n’ont pas été inclus.
- L’UUID de root a changé (clonage, remplacement de disque) mais la config de boot ne l’a pas.
- Racine ZFS : le pool ne s’est pas importé à cause d’un hostid ou cachefile.
Vérifier ce que le noyau pense être votre device root
cr0x@server:~$ cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-6.8.12-4-pve root=/dev/mapper/pve-root ro quiet
Sens : Root pointe sur un device mapper LVM. Si ce mapper n’apparaît jamais, vous échouerez à monter la racine.
Décision : Vérifiez l’activation LVM dans l’initramfs (ou reconstruisez l’initramfs avec les composants LVM) et confirmez que le PV sous‑jacent est visible tôt dans le boot.
Voir si le pilote de stockage est réellement chargé
cr0x@server:~$ lsmod | egrep 'nvme|ahci|megaraid|mpt3sas|vfio' | head
nvme 61440 2
ahci 45056 0
Sens : Le système en cours d’exécution a les modules NVMe et AHCI. Dans les scénarios d’échec, ils peuvent être absents de l’initramfs, pas du système complet.
Décision : Si vous suspectez des modules manquants dans l’initramfs, reconstruisez‑le et assurez‑vous d’inclure les modules requis.
Reconstruire initramfs pour tous les noyaux installés
cr0x@server:~$ update-initramfs -u -k all
update-initramfs: Generating /boot/initrd.img-6.5.13-5-pve
update-initramfs: Generating /boot/initrd.img-6.8.12-4-pve
Sens : Les deux initrd sont régénérés. Cela corrige beaucoup d’échecs de boot dus à des noyaux partiellement installés.
Décision : Si ça renvoie une erreur « No space left on device », corrigez /boot avant toute autre action.
S’assurer que /etc/initramfs-tools/modules contient les pilotes requis exotiques
La plupart des systèmes n’ont pas besoin de ça. Certains en ont besoin. Surtout si vous démarrez à partir d’HBA exotiques, iSCSI, ou avez des problèmes d’ordre strict. Exemple de snippet à ajouter :
cr0x@server:~$ sed -n '1,120p' /etc/initramfs-tools/modules
# List of modules that you want to include in your initramfs.
# They will be loaded at boot time in the order below.
nvme
ahci
Sens : Ces modules seront forcés dans l’initramfs.
Décision : N’ajoutez que des modules que vous comprenez. Remplir l’initramfs de tout fait des boots lents et de nouveaux modes de panne.
Récupération du stockage : ZFS et LVM‑thin
Le stockage est l’endroit où le « simple » devient « incident ». Si vous vous trompez ici vous pouvez créer une vraie corruption. Si vous réussissez, vous aurez l’air d’un magicien. La différence tient surtout à la discipline.
ZFS : pools qui ne s’importent pas après mise à jour
Raisons courantes :
- Hostid différent après réinstallation, clonage, ou modification accidentelle de
/etc/hostid. - Cachefile manquant/obsolète ; l’initramfs ne trouve pas les pools de façon fiable.
- Changements de nommage des périphériques (ex. ordre SATA) alors que vous utilisez des chemins /dev/sdX bruts au lieu de by‑id.
- Le pool est occupé ou importé ailleurs (dans les scénarios de disque partagé, c’est votre sirène d’alarme).
Vérifier hostid et attentes ZFS
cr0x@server:~$ hostid
1a2b3c4d
cr0x@server:~$ ls -l /etc/hostid
-rw-r--r-- 1 root root 4 Feb 12 09:00 /etc/hostid
Sens : hostid existe. S’il a changé récemment, ZFS peut refuser l’auto‑import ou se comporter différemment.
Décision : Si les pools provenaient d’un autre hôte, définissez le hostid de façon intentionnelle et documentez‑le. Ne « bricolez » pas avec des imports forcés.
Vérifier la santé du pool une fois importé
cr0x@server:~$ zpool status -x
all pools are healthy
Sens : Pas de problèmes ZFS connus.
Décision : Passez à la récupération des services Proxmox. Si le pool est dégradé, traitez le resilver avant de relancer des charges I/O intensives.
LVM‑thin : VM manquantes, stockage « inactive », ou erreurs de thin pool
LVM‑thin casse généralement à cause d’un ordre d’activation ou de timeouts des périphériques sous‑jacents. Plus rarement, les métadonnées thin se remplissent.
Activer les volume groups et vérifier l’usage des métadonnées thin
cr0x@server:~$ vgchange -ay
3 logical volume(s) in volume group "pve" now active
cr0x@server:~$ lvs -o lv_name,vg_name,attr,lv_size,data_percent,metadata_percent
LV VG Attr LSize Data% Meta%
data pve twi-aotz-- <1.60t 72.11 2.40
root pve -wi-ao---- 96.00g
swap pve -wi-ao---- 8.00g
Sens : Les métadonnées du thin pool ne sont utilisées qu’à 2.40%. C’est correct.
Décision : Si les métadonnées approchent 100%, arrêtez. Étendre/réparer les métadonnées thin est délicat ; ne redémarrez pas des dizaines de VM et n’empirez pas la situation.
Vérifier les erreurs système de fichiers si la racine est passée en lecture seule
cr0x@server:~$ mount | grep ' / '
/dev/mapper/pve-root on / type ext4 (ro,relatime,errors=remount-ro)
Sens : La racine est montée en lecture seule. Cela casse la gestion des paquets, le FS de cluster, les logs, tout.
Décision : Redémarrez en rescue et lancez fsck. Ne faites pas « remount rw » en espérant ; vous risquez d’aggraver les métadonnées.
Récupération de cluster : quorum, corosync et réintégration
La récupération de cluster est l’endroit où les ingénieurs bien intentionnés provoquent de mauvaises semaines. Corosync est pointilleux par conception. Respectez‑le.
Décider si vous êtes face à :
- Un nœud cassé isolé tandis que le reste du cluster est sain.
- Perte de quorum à cause de multiples nœuds down ou partition réseau.
- Risque de split‑brain (deux partitions pensent être primaires).
Vérifier corosync et l’état du cluster
cr0x@server:~$ systemctl status corosync --no-pager
● corosync.service - Corosync Cluster Engine
Loaded: loaded (/lib/systemd/system/corosync.service; enabled)
Active: failed (Result: exit-code) since Wed 2025-02-12 09:14:51 UTC; 8min ago
Process: 1188 ExecStart=/usr/sbin/corosync -f $COROSYNCOPTIONS (code=exited, status=2)
Sens : corosync n’est pas lancé. La raison est dans les logs ; ne devinez pas.
Décision : Récupérez les logs détaillés et vérifiez que l’interface réseau utilisée par corosync est up et a l’adresse attendue.
cr0x@server:~$ journalctl -u corosync --no-pager | tail -n 40
Feb 12 09:14:51 pve01 corosync[1188]: [KNET ] host: 1 link: 0 is down
Feb 12 09:14:51 pve01 corosync[1188]: [KNET ] failed to bind to interface 'vmbr0'
Feb 12 09:14:51 pve01 corosync[1188]: [MAIN ] Corosync Cluster Engine exiting with status '2'
Sens : Corosync veut vmbr0 mais il est down ou manquant. Réparez la config réseau avant de toucher à la config du cluster.
Décision : Ramenez le bridge/interface, puis retentez corosync.
Mode local temporaire (à utiliser avec parcimonie)
Parfois il faut rendre un nœud opérationnel (par ex. pour évacuer des VM via l’accès au stockage) même si corosync ne peut pas se former. Proxmox permet de fonctionner sans communications de cluster, mais vous devez connaître les compromis.
Une approche courante est d’arrêter les services de cluster et de travailler localement. Cela permet d’accéder au stockage local et aux VM, mais la configuration gérée par le cluster ne se comportera pas normalement.
cr0x@server:~$ systemctl stop pve-cluster corosync
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: inactive (dead)
Sens : Le FS de cluster est arrêté ; vous n’écrivez plus l’état du cluster.
Décision : Utilisez cela pour stabiliser le nœud et vérifier l’état des stockages/VM. Ne restez pas longtemps ainsi dans un vrai cluster sauf si vous aimez les réunions.
Blague #2 : Le split‑brain, c’est quand les deux moitiés de votre cluster deviennent très confiantes et très erronées.
Stratégie de réintégration
Une fois le nœud démarré proprement, le réseau stable et le stockage correct, réactivez corosync et pmxcfs et confirmez le quorum. Ne « corrigez » pas des décalages de versions de configuration en copiant des fichiers au hasard ; alignez le nœud sur la source de vérité du cluster.
Récupération réseau : bridges, bonds, et « pourquoi vmbr0 est down ? »
Les problèmes réseau après mise à jour proviennent souvent de changements de pilote, renommage d’interfaces, ou d’une configuration bridge/bond qui dépend d’un ordre qui a changé.
Inspecter la configuration réseau
cr0x@server:~$ sed -n '1,200p' /etc/network/interfaces
auto lo
iface lo inet loopback
auto enp4s0
iface enp4s0 inet manual
auto vmbr0
iface vmbr0 inet static
address 10.10.10.11/24
gateway 10.10.10.1
bridge-ports enp4s0
bridge-stp off
bridge-fd 0
Sens : vmbr0 dépend de enp4s0. Si enp4s0 a été renommée (p.ex. enp3s0), vmbr0 ne montera pas.
Décision : Comparez avec ip -br link et corrigez les noms d’interfaces. Ensuite montez le réseau soigneusement.
Monter le bridge manuellement pour confirmer que c’est la config et pas le matériel
cr0x@server:~$ ip link set enp4s0 up
cr0x@server:~$ ifup vmbr0
Internet Systems Consortium DHCP Client 4.4.3-P1
ifup: interface vmbr0 already configured
Sens : Soit il est déjà configuré soit ifupdown2 pense qu’il l’est. S’il reste DOWN, inspectez ip addr et les logs.
Décision : Si le bridge refuse, cherchez un gestionnaire réseau en conflit, ou une erreur de syntaxe dans la config.
Confirmer que l’interface de binding corosync existe et a l’IP attendue
cr0x@server:~$ ip -br addr show vmbr0
vmbr0 UP 10.10.10.11/24
Sens : corosync peut désormais binder. C’est souvent toute la réparation nécessaire pour « cluster down après mise à jour ».
Décision : Redémarrez corosync puis pve-cluster, dans cet ordre, et confirmez avec pvecm status.
Listes de contrôle / plan pas à pas
Plan A : Le nœud ne démarre plus après mise à jour (le plus courant)
- Obtenez l’accès console (IPMI/iKVM). Capturez la première erreur affichée à l’écran.
- Essayez les options avancées GRUB : démarrez le noyau Proxmox précédent.
- Si le boot fonctionne, épinglez le noyau fonctionnel et reconstruisez l’initramfs pour tous les noyaux.
- Vérifiez l’espace libre sur /boot ; si presque plein, supprimez proprement les anciens noyaux seulement après avoir confirmé un boot stable.
- Vérifiez le stockage : pools ZFS importés, LVM actif, système de fichiers root monté en lecture‑écriture.
- Confirmez les services Proxmox : pveproxy/pvedaemon/pvestatd, puis services de cluster le cas échéant.
- Redémarrez une fois pour valider que la correction persiste.
Plan B : GRUB/UEFI en échec (vous n’arrivez même pas au noyau)
- Démarrez un ISO rescue dans le même mode (UEFI vs BIOS) que le système utilise.
- Montez root, /boot, et /boot/efi ; bind‑montez /dev,/proc,/sys,/run ; chroot.
- Réinstallez GRUB sur l’ESP (UEFI) ou sur le disque (BIOS) et lancez update-grub.
- Reconstruisez l’initramfs pour le noyau connu‑bon.
- Vérifiez les entrées efibootmgr ; redémarrez et testez.
Plan C : L’OS démarre, la pile Proxmox est cassée (UI web down, cluster fâché)
- Vérifiez d’abord disque plein, racine en lecture seule, et dérive d’heure.
- Vérifiez les unités en échec avec
systemctl --failed. - Confirmez l’état de montage de
/etc/pve; les problèmes du FS de cluster casseront la gestion. - Pour les pannes corosync, validez l’interface réseau et le MTU, puis redémarrez corosync et pve-cluster.
- Si nécessaire, opérez temporairement en mode local pour récupérer des VM ou du stockage, puis rejoignez correctement le cluster.
Plan D : Stockage manquant après mise à jour
- Confirmez que le noyau voit les disques (
lsblk,dmesg). - Pour ZFS : lancez
zpool import, importez prudemment, définissez le cachefile, vérifiez le hostid. - Pour LVM : lancez
vgscan,vgchange -ay, inspectez l’usage du thin pool. - Ne forcez pas les imports/réparations tant que vous ne savez pas si les disques ont été déplacés ou partagés.
Erreurs courantes (symptômes → cause → correction)
1) Symptôme : « Démarre dans le shell initramfs, impossible de trouver le device root »
Cause : initramfs manque de pilotes de stockage ou composants LVM ; ou l’update a laissé un initrd incomplet à cause d’un /boot plein.
Correction : Démarrez sur un noyau plus ancien ; en rescue/chroot reconstruisez l’initramfs (update-initramfs -u -k all), libérez de l’espace sur /boot, assurez‑vous d’inclure les modules requis.
2) Symptôme : « Prompt GRUB » ou « pas de périphérique bootable » après mise à jour
Cause : montage ESP cassé, entrée EFI manquante, installation grub incomplète, ou ESP corrompue.
Correction : Montez l’ESP, réinstallez GRUB pour UEFI, lancez update-grub, vérifiez les entrées efibootmgr.
3) Symptôme : « Le nœud boot mais l’UI Proxmox est inaccessible »
Cause : pveproxy ou pvedaemon ne tourne pas ; /etc/pve non monté ; racine en lecture seule ; disque plein.
Correction : Vérifiez systemctl status pour les services pve, vérifiez mount | grep /etc/pve, corrigez l’état du FS, libérez de l’espace disque.
4) Symptôme : « Le cluster montre un nœud hors ligne ; erreurs pmxcfs »
Cause : corosync ne peut pas binder car le nom d’interface a changé ou le bridge est down.
Correction : Corrigez /etc/network/interfaces pour correspondre aux noms NIC actuels, relevez vmbr0, redémarrez corosync puis pve-cluster.
5) Symptôme : « Le pool ZFS ne s’importe pas au boot, alors que les disques sont présents »
Cause : hostid différent ou cachefile zpool obsolète/manquant ; changements de chemin de device.
Correction : Importez avec l’option cachefile, confirmez la stabilité du hostid, préférez les noms by‑id, reconstruisez l’initramfs si la racine est ZFS.
6) Symptôme : « La mise à jour a réussi, mais après reboot le réseau est étrange »
Cause : changement de pilote NIC, renommage prévisible d’interface, ou mode de bond incompatible après mise à jour du module.
Correction : Confirmez ip -br link et ajustez la config bridge/bond ; vérifiez dmesg pour erreurs pilote ; rollback noyau si nécessaire.
7) Symptôme : « Tout a l’air OK, mais on ne peut pas installer/rollback des paquets »
Cause : racine montée en lecture seule ou /var plein ; dpkg laissé des paquets en demi‑configuration après upgrade interrompu.
Correction : Résolvez l’état du FS, puis lancez dpkg --configure -a et apt -f install depuis un boot stable.
8) Symptôme : « Disques VM manquants dans la vue de stockage »
Cause : backend de stockage non actif (pool ZFS non importé, VG non activé), ou pmxcfs non monté, donc la config de stockage n’est pas chargée.
Correction : Restaurez d’abord le stockage (import/activation), puis assurez‑vous que le FS de cluster est monté et que les services pve sont sains.
Trois mini‑histoires du monde corporate (douleur, apprentissage et une victoire ennuyeuse)
Mini‑histoire 1 : L’incident causé par une mauvaise supposition
Une entreprise moyenne avait un cluster Proxmox trois‑nœuds avec Ceph pour les disques VM et quelques pools ZFS locaux pour les sauvegardes. Un week‑end de mise à jour est arrivé. Un nœud n’est pas revenu. L’ingénieur on‑call a vu « ZFS pool not imported » et a supposé que c’était sans risque de forcer l’import parce que « c’est local de toute façon ».
La mauvaise supposition : le pool « local » n’était pas purement local. Quelques mois plus tôt, l’équipe hardware avait déplacé des disques entre nœuds pendant un remplacement de châssis. Personne n’avait mis à jour la documentation d’inventaire. Le pool avait été importé sur un autre nœud lors du déplacement, et l’histoire hostid+cachefile était un sac de nœuds. Forcer l’import sur le nœud cassé l’a rendu disponible aux yeux du système, mais ce n’était pas la copie faisant autorité de tout.
Ils n’ont pas immédiatement corrompu le pool, mais ils ont fait quelque chose presque aussi cher : ils ont restauré des backups à partir de snapshots erronés. Plusieurs VM sont revenues avec des données obsolètes qui semblaient cohérentes au premier abord. L’incident n’était plus « nœud down », c’est devenu « validité des données douteuse », ce qui génère des réunions.
La correction a été surtout procédurale. Ils ont documenté physiquement où chaque pool vivait, ont préféré les chemins by‑id, et ont fait du « force import » une action d’urgence requérant un second avis. Techniquement, la récupération correcte aurait été : importer en lecture seule, confirmer les timestamps des datasets, puis décider. Socialement : ne supposez pas que quelque chose est « local » à moins de pouvoir le pointer dans la baie.
Mini‑histoire 2 : L’optimisation qui s’est retournée contre eux
Une autre organisation avait une initiative de performance : réduire le temps de boot et les fenêtres de patch sur les hôtes de virtualisation. Quelqu’un a décidé de « nettoyer les vieux noyaux » agressivement pour récupérer de l’espace sur /boot et réduire la maintenance. Ils ont automatisé pour ne garder que le noyau le plus récent.
Ça a bien marché… jusqu’à ce que ça ne marche plus. Un nouveau noyau est arrivé avec une régression affectant leur combinaison firmware RAID spécifique. L’hôte a redémarré sur le nouveau noyau et n’a plus vu son disque root. Sans noyau de repli installé, « booter sur le précédent » n’était plus une option. Ils ont dû faire le tour du rescue ISO pendant une fenêtre de maintenance dépassée.
La récupération a pris plus de temps que nécessaire, en partie parce que le processus de on‑call était conçu pour rollback : booter l’ancien noyau, récupérer les logs, décider. Ce chemin avait été supprimé par souci de propreté.
La correction éventuelle était peu glamour : garder au moins deux noyaux connus‑bons, alerter sur l’usage de /boot, et ajouter un check pré‑reboot qui vérifie que la génération d’initramfs a réussi. L’optimisation n’était pas mauvaise ; elle était incomplète. La fiabilité déteste les décisions « tous les œufs dans un seul panier », surtout quand le panier est un noyau.
Mini‑histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise
Une équipe de services financiers avait un cluster Proxmox supportant du CI interne et quelques services sensibles à la latence. Leur pratique de patching était terne : un nœud à la fois, évacuer les VM, mettre à jour, redémarrer, valider, puis continuer. Ils avaient aussi l’habitude stricte : tester et maintenir iKVM accessible, et snapshotter la configuration de boot (liste de noyaux, defaults grub, /etc/network/interfaces) avant la maintenance.
Pendant une mise à jour, un nœud a redémarré et est revenu avec le réseau mal configuré dû à un renommage d’interface. Corosync a échoué. Le nœud était « down » du point de vue du cluster. Mais l’équipe avait déjà évacué les charges. Il n’y a donc pas eu d’impact client, juste une blessure d’ego d’ingénieur.
Ils ont utilisé l’accès console pour comparer les noms d’interfaces, corrigé les ports du bridge, redémarré corosync et réintégré sans heurt. Le postmortem a été presque ennuyeux : « nom d’interface changé ; on a validé avant/après ; pas d’impact ». L’ennui est l’objectif. Le drame n’est pas un KPI.
Cette même discipline ennuyeuse a rendu la réparation sûre : pas d’import forcé, pas de reboots aléatoires, pas de modifications hâtives du quorum. Juste des étapes contrôlées et des vérifications à chaque phase. La réponse d’incident la plus impressionnante est celle que personne en dehors de l’équipe ne remarque.
FAQ
1) Dois‑je rollback le noyau ou réinstaller Proxmox ?
Faites le rollback du noyau d’abord. Réinstaller Proxmox est le dernier recours et souvent inutile. Un ancien noyau fonctionnel plus les artefacts de boot réparés résolvent une large fraction des cas « échec après mise à jour ».
2) Puis‑je supprimer sans risque le paquet noyau cassé ?
Oui, mais seulement après avoir confirmé un démarrage stable avec un autre noyau et avoir suffisamment d’espace sur /boot. Utilisez les outils de paquets, pas une suppression manuelle dans /boot. Gardez au moins un noyau de secours installé.
3) Mon nœud boot, mais l’UI Proxmox est inaccessible. Mes VM sont‑elles mortes ?
Pas nécessairement. Vérifiez systemctl status pveproxy et inspectez les processus VM via qm list (si disponible) ou ps. L’UI est un service ; elle peut tomber alors que QEMU tourne.
4) Le pool ZFS ne s’importe pas automatiquement après reboot. Quelle est la cause la plus courante ?
Hostid / cachefile et changements de nom de périphérique. Importez explicitement le pool, définissez le cachefile, et assurez‑vous que le hostid est stable et intentionnel.
5) Est‑il sûr de forcer l’import d’un pool ZFS ?
Parfois. Mais c’est aussi une excellente façon de transformer l’incertitude en conséquences. S’il y a la moindre chance que le pool soit importé ailleurs ou ait été déplacé, importez‑le en lecture seule d’abord et vérifiez.
6) Comment savoir si /boot plein a causé ma panne ?
Vérifiez df -h /boot. Si c’est au‑dessus d’environ 90% et que vous avez installé des noyaux récemment, vous avez probablement des initramfs incomplets ou des scripts postinst qui ont échoué. Reconstruisez l’initramfs après avoir libéré de l’espace.
7) Quel est l’ordre sûr pour remettre les services de cluster ?
Le réseau d’abord (l’interface sur laquelle corosync bind doit être up), ensuite démarrez corosync, puis pve-cluster, confirmez que /etc/pve est monté, puis vérifiez les services pve.
8) Puis‑je faire fonctionner un nœud Proxmox « autonome » si le cluster est cassé ?
Temporairement, oui, en stoppant les services de cluster. Mais vous vous mettez hors des garanties et de la configuration gérée par le cluster. Utilisez‑le pour récupérer des données ou stabiliser le nœud, puis rejoignez correctement le cluster.
9) Pourquoi une mise à jour du noyau a‑t‑elle cassé le réseau ?
Régressions de pilotes, interactions firmware, ou renommage d’interfaces. Le noyau est le contrat matériel. Quand ce contrat change, votre configuration bridge/bond peut échouer de manière surprenante.
10) Si je répare le boot, comment prévenir la prochaine fois ?
Mettez à jour un nœud à la fois, gardez des noyaux de repli, surveillez l’espace /boot, validez la génération d’initramfs, et testez l’accès console avant d’en avoir besoin.
Conclusion : prochaines étapes à faire réellement
Pour récupérer un nœud Proxmox après une mauvaise mise à jour, priorisez la réversibilité : démarrez un noyau plus ancien, épinglez‑le, reconstruisez l’initramfs, puis réparez GRUB/EFI si nécessaire. Validez l’import/activation du stockage avant de toucher à l’adhésion au cluster. Ramenez le réseau avant corosync. Et ne « forcez » rien tant que vous n’avez pas prouvé que vous opérez sur les bons disques au bon endroit.
Prochaines étapes qui rapportent :
- Conservez au moins deux noyaux fonctionnels installés et assurez‑vous que /boot a de la marge.
- Testez l’accès iKVM/IPMI chaque trimestre, pas en pleine crise.
- Documentez la propriété des stockages (quel pool vit où) et privilégiez les chemins de périphériques by‑id.
- Adoptez un workflow de mise à jour nœud‑par‑nœud avec évacuation des VM et une checklist de validation réelle.
Si vous faites ces quatre choses, le prochain événement « échec après mise à jour » devient un rollback de 20 minutes, pas un week‑end prolongé accompagné d’un vocabulaire de plus en plus créatif.