Proxmox ne démarre plus après une mise à jour du noyau : revenir via GRUB correctement

Playbook de diagnostic rapide

Quand un nœud Proxmox ne démarre pas après une mise à jour du noyau, votre mission est d’obtenir du signal rapidement et d’éviter les “corrections” qui détruisent des preuves (ou cassent votre pool ZFS, ou votre charge-boot, ou votre moral). Voici un ordre de triage qui tient sous pression.

Première étape : identifiez le type de panne (secondes, pas minutes)

• Pas de menu GRUB / démarrage direct vers le firmware : probablement des problèmes d’entrée EFI/ESP, ou l’ordre de démarrage a changé.
• GRUB apparaît, sélection du noyau disponible : bien. Revenez d’abord au noyau précédent.
• Le noyau se charge puis panic / bloque : habituellement initramfs manquant de modules, mismatch DKMS, ou stockage racine introuvable.
• Démarre sur shell d’urgence : échec du montage du système de fichiers root, import ZFS échoué, ou paramètres de noyau erronés.
• Écran noir après GRUB : souvent transfert GPU/console ou problème de framebuffer ; le système peut quand même démarrer — vérifiez l’activité disque ou un ping depuis une autre machine.

Deuxième étape : choisissez le chemin de récupération le moins invasif

1. Utiliser GRUB pour lancer un noyau plus ancien (rapide, réversible, préserve l’installation).
2. Éditer GRUB pour ajouter un paramètre temporaire (par exemple debug ou nomodeset) si nécessaire.
3. Démarrer sur un média de secours seulement si GRUB ne peut rien démarrer ou si l’ESP a disparu.

Troisième étape : décidez ce que vous devez préserver

Avant de “nettoyer les vieux noyaux” ou de réinstaller quoi que ce soit, décidez ce qui compte :

• Avez-vous besoin de garder le noyau cassé installé pour un futur débogage ? En général oui — au moins tant que le nœud n’est pas stable.
• Êtes-vous sur ZFS root ? Dans ce cas, traitez initramfs et module ZFS comme un système couplé.
• Utilisez-vous des modules DKMS du vendeur (pilotes HBA, pilotes NIC hors arborescence) ? Attendez-vous à des soucis de rebuild.

Règle opérationnelle : votre premier objectif de démarrage est console stable + stockage stable + réseau stable. L’interface Proxmox vient après.

Qu’est-ce qui a vraiment cassé quand Proxmox ne démarre pas

Une mise à jour du noyau ne se contente pas de remplacer vmlinuz. Elle met à jour une famille d’éléments étroitement liés : image du noyau, initramfs, modules sous /lib/modules, pilotes compilés via DKMS, entrées du bootloader, et parfois microcode et éléments EFI. N’importe lequel de ces éléments peut gâcher votre matinée.

Modes de défaillance typiques après une mise à jour du noyau

• Nouveau noyau démarre mais ne trouve pas le système racine : pilote de stockage manquant ou module ZFS absent de l’initramfs ; mauvais root= ; génération d’initramfs cassée.
• Kernel panic pendant l’amorçage précoce : souvent mismatch de module/ABI, initramfs corrompu, ou un build DKMS qui a échoué silencieusement.
• Le menu GRUB existe mais seul le nouveau noyau est affiché : anciens noyaux supprimés, ou /boot pas mis à jour, ou config GRUB non régénérée.
• UEFI démarre sur le firmware / “No bootable device” : ESP non monté lors de la mise à jour, ou entrée de démarrage EFI perdue.
• Boucle de démarrage : watchdog qui reboot, panic puis redémarrage automatique, ou systemd qui échoue avec kernel: panic et redémarrage immédiat.
• Le système démarre mais les services Proxmox échouent : pas une panne de démarrage, mais instabilité post-mise à jour (corosync, pveproxy, montages de stockage).

Voici une vérité un peu agaçante : le rollback via GRUB corrige les symptômes, pas les causes. Mais il vous donne un environnement propre pour réparer la cause sans faire de chirurgie dans un shell initramfs.

Faits intéressants et contexte historique (parce que ça aide à décider)

1. GRUB 2 est devenu le standard sous Debian en grande partie parce qu’il gère mieux les scénarios de boot complexes (LVM, RAID, noyaux multiples) que l’ancien GRUB.
2. Proxmox repose sur Debian, ce qui signifie que la plupart des “problèmes de démarrage Proxmox” sont des problèmes classiques de kernel + initramfs + bootloader Debian avec un badge PVE.
3. Initramfs n’est pas du théâtre optionnel : c’est un petit système de fichiers chargé en RAM pour monter le stockage et la racine. S’il manque les bons pilotes, le noyau ne peut pas atteindre votre root.
4. DKMS existe pour reconstruire les pilotes entre noyaux. Quand il échoue, vous pouvez obtenir un noyau qui démarre sans NIC, ou pire, sans pilote de contrôleur de stockage.
5. ZFS on Linux est hors noyau, donc sensible aux changements d’ABI du noyau. Nouveau noyau + module ZFS manquant = “root pool not found”.
6. L’UEFI a rendu le démarrage plus flexible et plus fragile : l’ESP, les entrées NVRAM et les implémentations fournisseurs ajoutent des surfaces de défaillance.
7. Linux conserve plusieurs noyaux installés par conception pour permettre de revenir en arrière. Les personnes sabotent cette sécurité en purgeant agressivement les “noyaux inutilisés”.
8. Le packaging des noyaux Proxmox (pve-kernel) est optimisé pour la virtualisation et contient des patchs/fonctionnalités ; mélanger des noyaux de dépôts aléatoires est risqué.

Un confort sec : cette panne est suffisamment courante pour que les étapes de récupération soient majoritairement ennuyeuses. Et l’ennui, en production, c’est bien.

Blague #1 : Une mise à jour du noyau, c’est comme “juste un petit changement” dans un pare-feu d’entreprise — personne n’y croit, mais on fait semblant quand même.

Retour arrière via GRUB (BIOS et UEFI) sans aggraver

Vous voulez l’ancien noyau parce qu’il correspond probablement à l’initramfs fonctionnel et aux modules installés. Le bon rollback : sélectionnez un noyau plus ancien, démarrez, confirmez la stabilité, puis faites-en le défaut temporairement pendant que vous réparez le noyau cassé.

Étape 1 : atteindre le menu GRUB de façon fiable

Sur beaucoup de systèmes, le menu GRUB est caché sauf en cas de problème. Quand les choses vont déjà mal, il faut souvent être rapide.

• BIOS : appuyez et maintenez Shift pendant le boot.
• UEFI : tapez Esc (ou parfois Shift) pendant le boot.
• IPMI/iKVM à distance : envoyez la touche tôt ; certaines consoles bufferisent mal.

Étape 2 : choisir un noyau plus ancien de façon sûre

Dans GRUB :

1. Sélectionnez Advanced options for Debian GNU/Linux (sur Proxmox cela peut toujours indiquer Debian).
2. Sélectionnez la version du noyau précédente (généralement celle en dessous de la plus récente).
3. Privilégiez l’entrée normale, pas le “recovery mode”, sauf si le boot normal échoue.

Quel noyau choisir ? En pratique : le noyau le plus récent qui fonctionnait auparavant. Si vous êtes passé de 6.5 à 6.8 et que 6.8 échoue, choisissez 6.5. Ne reculez pas de plusieurs versions majeures sauf nécessité ; les noyaux plus anciens peuvent ne pas correspondre aux attentes des userspace plus récent, et vous êtes là pour stabiliser, pas voyager dans le temps.

Étape 3 : quand la sélection du noyau ne suffit pas

Si l’écran devient noir ou si vous suspectez un problème graphique console, essayez un paramètre temporaire. Dans GRUB, mettez en surbrillance l’entrée du noyau, appuyez sur e, trouvez la ligne commençant par linux, ajoutez des paramètres, puis démarrez avec Ctrl+x ou F10.

Paramètres temporaires utiles :

• nomodeset (problèmes de transfert de pilote vidéo ; courant sur GPUs bizarres)
• systemd.unit=multi-user.target (sauter les targets graphiques ; pas souvent pertinent sur des serveurs Proxmox, mais utile parfois)
• debug ou loglevel=7 (plus de verbosité des logs kernel)
• panic=30 (retarder le reboot sur panic ; vous laisse le temps de lire l’erreur)

Ne “réparez” pas GRUB depuis l’éditeur GRUB au-delà des paramètres temporaires. Si vous pouvez booter un ancien noyau, effectuez les réparations réelles depuis un système en fonctionnement.

Étape 4 : rendre l’ancien noyau par défaut (épingle temporaire)

Une fois démarré avec succès, vous pouvez épingler le noyau de démarrage par défaut en configurant l’entrée par défaut de GRUB. Cela empêche les reboots accidentels vers le noyau cassé pendant que vous travaillez. Faites-le depuis l’OS, pas depuis le firmware.

Après le démarrage : confirmer, stabiliser et prévenir une répétition

Démarrer n’est pas “résolu”. Démarrer signifie “on respire à nouveau”. Maintenant vous devez comprendre pourquoi le nouveau noyau a échoué et décider si vous allez le réparer, le mettre en attente, ou le supprimer.

Voici le modèle mental qui vous évite de gesticuler :

• Si le nouveau noyau panique tôt : inspectez le contenu d’initramfs, les modules manquants, la disponibilité de ZFS, les problèmes de microcode.
• Si il démarre mais sans réseau : rebuild DKMS, paquets firmware, interfaces renommées, ou régression de pilote.
• Si il démarre mais ne peut pas importer ZFS : mismatch de module ZFS, initramfs sans ZFS, ou flags de pool incompatibles.
• Si GRUB/UEFI est en cause : montage de l’ESP, grub-install (BIOS) ou recréation d’entrée EFI (UEFI), et vérifications de cohérence.

De plus : si c’est un environnement Proxmox en cluster, traitez le nœud comme “hors service” jusqu’à stabilité. Un nœud à moitié opérationnel peut causer plus de dégâts qu’un nœud éteint, surtout s’il commence à faire fluctuer la membership corosync ou les montages de stockage.

Blague #2 : Rien ne renforce la cohésion d’équipe comme tout le monde regardant silencieusement un serveur démarrer — ensemble — comme si c’était une pièce de théâtre en direct.

Une citation pour rester honnête

« L’espoir n’est pas une stratégie. » — General Gordon R. Sullivan

En termes SRE : rendez le rollback déterministe, puis rendez la voie avant ennuyeuse.

Pièges ZFS root et stockage lors de rollbacks de noyau

Si votre hôte Proxmox boote depuis ZFS, les mises à jour du noyau peuvent échouer de manière très spécifique : le noyau démarre, initramfs se charge, puis il ne peut pas importer le rpool parce que le module ZFS n’est pas disponible (ou ne correspond pas au noyau). Cela produit des erreurs comme “cannot import ‘rpool’: no such pool available” ou “ZFS: module not found”, suivies d’un shell d’urgence.

Pourquoi ZFS complique les choses

• ZFS n’est pas intégré à l’arbre du noyau Linux ; c’est un module séparé. Il doit donc être compilé pour chaque noyau.
• Sur ZFS root, l’initramfs doit inclure les éléments ZFS pour pouvoir importer le pool tôt dans le boot.
• Les paquets Proxmox gèrent normalement cela, mais des upgrades partiels, des builds DKMS cassés, ou une ESP non montée peuvent créer des scénarios “noyau mis à jour, initramfs pas vraiment mis à jour”.

Approche sûre

Démarrez le dernier noyau connu bon. Confirmez l’import du pool et le montage des datasets. Ensuite réparez le noyau cassé en reconstruisant l’initramfs et en vous assurant que les modules ZFS existent pour lui. Ce n’est qu’après que vous laisserez le système booter dans le noyau plus récent.

Si vous êtes sur ZFS root et que vous purgez agressivement les vieux noyaux, vous pouvez vous piéger : le seul noyau restant est celui qui a besoin de modules ZFS jamais construits. C’est comme transformer un rollback de 10 minutes en après-midi “boot depuis ISO et chroot”.

Tâches pratiques (commandes, sens des sorties, décisions)

Ci-dessous des tâches réelles à lancer après être parvenu à démarrer (généralement via un noyau plus ancien). Chacune inclut : commande, ce que signifie la sortie, et la décision à prendre.

Tâche 1 : confirmer quel noyau est réellement lancé

cr0x@server:~$ uname -r
6.5.13-5-pve

Sens : Vous exécutez actuellement 6.5.13-5-pve.

Décision : Si c’est le noyau connu bon, gardez-le comme base pendant que vous réparez le nouveau. Si c’est le nouveau noyau, votre rollback a échoué.

Tâche 2 : lister les noyaux Proxmox installés

cr0x@server:~$ dpkg -l 'pve-kernel-*' | awk '/^ii/ {print $2, $3}'
pve-kernel-6.5.13-5-pve 6.5.13-5
pve-kernel-6.8.12-3-pve 6.8.12-3

Sens : Les noyaux ancien et nouveau sont installés.

Décision : Si seul le noyau cassé est installé, arrêtez-vous et envisagez d’installer un noyau connu bon avant toute autre action (éventuellement via chroot/rescue si vous ne pouvez pas booter).

Tâche 3 : inspecter les derniers logs de boot pour comprendre pourquoi le nouveau noyau a échoué

cr0x@server:~$ journalctl -b -1 -p err --no-pager | tail -n 30
Dec 26 10:02:11 server kernel: zfs: module verification failed: signature and/or required key missing
Dec 26 10:02:11 server kernel: ZFS: Failed to load module
Dec 26 10:02:12 server systemd[1]: Failed to mount /.
Dec 26 10:02:12 server systemd[1]: Dependency failed for Initrd Root File System.

Sens : Le boot précédent (-1) a eu un échec de chargement du module ZFS, donc le montage root a échoué.

Décision : Cela pointe vers Secure Boot/signature de module, échec de build DKMS, ou initramfs sans ZFS. Vous allez dépanner cela précisément, pas réinstaller GRUB au hasard.

Tâche 4 : vérifier si Secure Boot est actif

cr0x@server:~$ mokutil --sb-state
SecureBoot enabled

Sens : UEFI Secure Boot est activé.

Décision : Si des modules hors-arbre (ZFS, pilotes vendor) ne sont pas correctement signés, ils peuvent ne pas se charger. Soit inscrire des clés/signatures, soit désactiver Secure Boot (décision de politique). Ne “désactivez pas juste” si votre organisation en dépend.

Tâche 5 : vérifier que des images initramfs existent pour chaque noyau

cr0x@server:~$ ls -lh /boot | egrep 'vmlinuz|initrd.img' | tail -n 10
-rw-r--r-- 1 root root  78M Dec 25 21:14 initrd.img-6.5.13-5-pve
-rw-r--r-- 1 root root  82M Dec 25 21:16 initrd.img-6.8.12-3-pve
-rw-r--r-- 1 root root 8.6M Dec 25 21:14 vmlinuz-6.5.13-5-pve
-rw-r--r-- 1 root root 9.1M Dec 25 21:16 vmlinuz-6.8.12-3-pve

Sens : Les deux noyaux ont initramfs et vmlinuz présents.

Décision : La présence ne garantit pas la correction, mais l’absence est un signal immédiat : régénérez initramfs et assurez-vous que /boot est bien monté.

Tâche 6 : confirmer que /boot et EFI System Partition sont montés (systèmes UEFI)

cr0x@server:~$ findmnt -no TARGET,SOURCE,FSTYPE /boot /boot/efi
/boot /dev/sda2 ext4
/boot/efi /dev/sda1 vfat

Sens : /boot et /boot/efi sont montés.

Décision : Si /boot/efi n’est pas monté pendant les mises à jour du noyau, les binaires GRUB EFI et les entrées NVRAM peuvent se désynchroniser. Corrigez les montages avant de relancer update-grub ou de réinstaller des pièces du bootloader.

Tâche 7 : régénérer initramfs pour le noyau cassé

cr0x@server:~$ sudo update-initramfs -u -k 6.8.12-3-pve
update-initramfs: Generating /boot/initrd.img-6.8.12-3-pve
Running hook script 'zz-proxmox-boot'..

Sens : Initramfs régénéré pour ce noyau précis.

Décision : Si ceci échoue avec des modules manquants ou des erreurs de hook, arrêtez-vous et corrigez ces erreurs avant de rebooter. Une génération “réussie” d’initramfs est nécessaire mais pas suffisante ; validez ensuite la présence des modules.

Tâche 8 : vérifier la disponibilité du module ZFS pour le noyau cible

cr0x@server:~$ ls /lib/modules/6.8.12-3-pve/updates/dkms/ 2>/dev/null | head
zfs.ko
zcommon.ko
znvpair.ko
zunicode.ko
zavl.ko

Sens : Les modules ZFS construits via DKMS existent pour le nouveau noyau.

Décision : Si ce répertoire est manquant ou vide, ZFS ne s’est pas construit pour le nouveau noyau. Consultez l’état DKMS et les logs de build.

Tâche 9 : inspecter l’état DKMS et reconstruire si nécessaire

cr0x@server:~$ dkms status
zfs/2.2.4, 6.5.13-5-pve, x86_64: installed
zfs/2.2.4, 6.8.12-3-pve, x86_64: built

Sens : Pour le nouveau noyau, ZFS est seulement “built” et pas “installed” (ou peut être manquant).

Décision : Installez-le pour ce noyau (ou rebuild). Un module “built” peut ne pas être placé dans l’arborescence correcte.

cr0x@server:~$ sudo dkms install zfs/2.2.4 -k 6.8.12-3-pve
Installing to /lib/modules/6.8.12-3-pve/updates/dkms/
depmod...

Sens : DKMS a installé le module ZFS dans l’arborescence du nouveau noyau et a lancé depmod.

Décision : Régénérez initramfs ensuite afin que l’initramfs contienne les éléments nécessaires.

Tâche 10 : reconstruire les entrées du menu GRUB

cr0x@server:~$ sudo update-grub
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.8.12-3-pve
Found initrd image: /boot/initrd.img-6.8.12-3-pve
Found linux image: /boot/vmlinuz-6.5.13-5-pve
Found initrd image: /boot/initrd.img-6.5.13-5-pve
done

Sens : La config GRUB contient maintenant les deux noyaux.

Décision : Si le noyau cassé n’a pas été trouvé, soit il n’est pas installé, soit /boot était incorrect. Ne rebootez pas vers l’inconnu.

Tâche 11 : définir l’entrée noyau par défaut (épingle temporaire)

Commencez par lister les entrées du menu avec leurs indices :

cr0x@server:~$ grep -n "menuentry '" /boot/grub/grub.cfg | head -n 8
105:menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-11111111-2222-3333-4444-555555555555' {
153:menuentry 'Advanced options for Debian GNU/Linux' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-advanced-11111111-2222-3333-4444-555555555555' {
161:menuentry 'Debian GNU/Linux, with Linux 6.8.12-3-pve' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-6.8.12-3-pve-advanced-11111111-2222-3333-4444-555555555555' {
199:menuentry 'Debian GNU/Linux, with Linux 6.5.13-5-pve' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-6.5.13-5-pve-advanced-11111111-2222-3333-4444-555555555555' {

Sens : Vous pouvez référencer une menuentry par son titre exact ou par son ID enregistré. Les titres peuvent changer ; les IDs sont plus stables.

Décision : Utilisez le mécanisme “saved” de GRUB pour des boots prévisibles, puis réglez l’entrée saved sur le noyau connu bon.

cr0x@server:~$ sudo sed -i 's/^GRUB_DEFAULT=.*/GRUB_DEFAULT=saved/' /etc/default/grub
cr0x@server:~$ sudo grub-set-default "Debian GNU/Linux, with Linux 6.5.13-5-pve"
cr0x@server:~$ sudo update-grub
Generating grub configuration file ...
done

Sens : GRUB démarrera par défaut sur le noyau 6.5 jusqu’à ce que vous changiez cela.

Décision : Gardez l’épingle jusqu’à ce que le nouveau noyau soit vérifié dans une fenêtre de reboot contrôlée.

Tâche 12 : vérifier les services démarrés et la santé du cluster (si applicable)

cr0x@server:~$ systemctl --failed --no-pager
UNIT                     LOAD   ACTIVE SUB    DESCRIPTION
0 loaded units listed.

Sens : Aucune unit systemd échouée.

Décision : Si vous voyez des units échouées liées au stockage, réseau, ou services pve, corrigez-les avant de remettre ce nœud en production.

cr0x@server:~$ pvecm status 2>/dev/null | egrep 'Quorate|Nodes|Name'
Name:             prod-cluster
Nodes:            3
Quorate:          Yes

Sens : Le cluster est quorate et reconnaît les nœuds.

Décision : Si le nœud est isolé ou cause de l’instabilité de membership, maintenez-le hors service et investiguez le réseau, la config corosync, et la synchronisation temporelle avant de continuer.

Tâche 13 : confirmer la santé du pool ZFS (ZFS root ou pools de données)

cr0x@server:~$ zpool status
  pool: rpool
 state: ONLINE
  scan: scrub repaired 0B in 00:09:12 with 0 errors on Sun Dec 22 02:10:12 2025
config:

        NAME        STATE     READ WRITE CKSUM
        rpool       ONLINE       0     0     0
          mirror-0  ONLINE       0     0     0
            sda3    ONLINE       0     0     0
            sdb3    ONLINE       0     0     0

errors: No known data errors

Sens : Le stockage est sain.

Décision : Si les pools sont dégradés ou non importés, ne blâmez pas aveuglément la mise à jour du noyau. Vous avez peut‑être découvert un vrai problème disque/contrôleur qui s’est seulement manifesté au reboot.

Tâche 14 : vérifier les entrées de boot EFI si le firmware vous renvoie au setup

cr0x@server:~$ sudo efibootmgr -v | head -n 20
BootCurrent: 0003
Timeout: 1 seconds
BootOrder: 0003,0001,0002
Boot0001* UEFI: Built-in EFI Shell
Boot0002* UEFI PXE IPv4
Boot0003* debian	HD(1,GPT,aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee,0x800,0x32000)/File(\EFI\debian\grubx64.efi)

Sens : Il y a une entrée Debian/GRUB EFI valide pointant vers \EFI\debian\grubx64.efi.

Décision : Si l’entrée Debian manque ou pointe vers un mauvais disque, vous la recréerez (prudemment) après avoir vérifié le contenu de l’ESP.

Tâche 15 : valider le contenu de l’ESP (UEFI)

cr0x@server:~$ sudo ls -R /boot/efi/EFI | head -n 40
/boot/efi/EFI:
BOOT
debian
proxmox

/boot/efi/EFI/debian:
grub.cfg
grubx64.efi
shimx64.efi

Sens : Les fichiers EFI existent. La présence de shimx64.efi indique souvent le support Secure Boot.

Décision : Si ce répertoire est vide ou manquant, votre ESP n’a pas été montée pendant les mises à jour ou a été écrasée. Il faudra réinstaller les binaires GRUB EFI et potentiellement recréer les entrées NVRAM.

Tâche 16 : vérifier l’espace libre sur /boot (silencieusement mortel)

cr0x@server:~$ df -h /boot
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2       512M  489M   23M  96% /boot

Sens : /boot est presque plein.

Décision : Un /boot plein peut conduire à des écritures d’initramfs incomplètes ou à des images manquantes. Vous devrez peut‑être supprimer d’anciens noyaux — mais seulement après avoir vérifié que vous avez au moins un fallback connu bon installé et bootable.

Trois mini-récits d’entreprise venus du terrain

1) L’incident causé par une fausse hypothèse

Le nœud était un hyperviseur Proxmox tout à fait normal. ZFS root, quelques miroirs NVMe, et une petite poignée de VMs critiques que les gens juraient être “non critiques” jusqu’à ce qu’elles tombent. L’équipe avait une habitude : appliquer les mises à jour en fin d’après‑midi, redémarrer, partir chez soi. Ça marchait d’habitude. “D’habitude” n’est pas une stratégie.

Un cycle de mise à jour, le nœud n’est pas revenu. L’IPMI affichait un kernel panic tôt dans le boot. Quelqu’un a supposé “GRUB doit être corrompu” parce que c’est l’histoire qu’on retient depuis 2012. Ils ont booté sur un média de secours, réinstallé GRUB, et rebooté. Même panic. Puis réinstallé GRUB encore, parce que se répéter est une technique de debug reconnue dans certains secteurs.

Le vrai problème était plus simple : l’initramfs du nouveau noyau ne contenait pas le pilote de stockage pour la HBA qui exposait le boot pool. Le module existait sur disque, mais il n’a jamais été inclus dans l’initramfs à cause d’une erreur de hook durant la mise à jour — déclenchée par un /boot presque plein. L’ancien noyau démarrait bien. Le nouveau ne trouvait pas la racine. GRUB était innocent.

Une fois revenues via GRUB au noyau précédent, la correction a pris 15 minutes : libérer de l’espace sur /boot, régénérer initramfs, valider la présence du module, puis reboot dans le nouveau noyau. La leçon n’était pas “ne pas mettre à jour”. La leçon était “ne supposez pas que le bootloader est la cause parce que vous voyez le bootloader”.

2) L’optimisation qui s’est retournée contre eux

Un autre environnement avait une forte culture “garder propre”. Ils lançaient un cron qui purgeait les vieux noyaux pour garder /boot propre et récupérer de l’espace. Quelqu’un avait vu un avertissement sur l’utilisation de /boot et a décidé que la solution permanente était de supprimer les noyaux “inutilisés”. Ça tournait partout. C’était “standard”. Personne ne se souvenait qui l’avait écrit.

Puis une mise à jour du noyau est arrivée qui a introduit une régression du pilote pour la NIC principale. Le système démarrait, mais sans réseau. Cela aurait été ennuyeux mais récupérable via la console — sauf que le processus d’intervention à distance du DC nécessitait un accès réseau au plan de gestion pour l’escalade. Leur accès hors bande existait, mais était lié au même segment réseau et pile de politiques. Amusant.

Le rollback aurait été trivial si un noyau plus ancien avait été disponible dans GRUB. Il n’y en avait pas. L’“optimisation” avait réduit la marge de sécurité à zéro. Ils ont dû booter sur un média de secours, monter les systèmes de fichiers, installer un noyau ancien depuis des miroirs locaux, reconstruire initramfs, puis reboot. Ça a marché, mais cela a brûlé des heures et de l’attention entre plusieurs équipes, parce que la procédure n’avait jamais été pratiquée.

Le postmortem n’a pas été tendre avec le cron. Ils ont gardé /boot sous contrôle ensuite, mais avec une règle : garder au moins deux noyaux connus bons installés, toujours, et alerter quand /boot se remplit plutôt que de purger silencieusement votre parachute.

3) La pratique ennuyeuse mais correcte qui a sauvé la mise

Même classe de panne : après une mise à jour du noyau, l’hôte a démarré sur un shell d’initramfs d’urgence avec “cannot mount root”. La différence était la discipline de l’équipe. Ils n’ont pas tapoté des commandes au hasard. Ils ont suivi un petit runbook et traité la console comme une preuve.

Premièrement, ils ont photographié l’écran et capturé l’erreur exacte. Puis ils ont rebooté et utilisé GRUB pour sélectionner le noyau précédent. Il a démarré normalement. Ils ont immédiatement épinglé l’ancien noyau comme défaut GRUB pour éviter un reboot accidentel vers le noyau cassé, et ont mis le nœud en mode maintenance pour que les workloads n’y atterrissent pas.

Puis ils ont fait la partie peu sexy : vérifier que /boot et /boot/efi étaient montés, vérifier l’espace libre, contrôler l’état DKMS, reconstruire initramfs pour le nouveau noyau, et confirmer l’existence des modules ZFS pour ce noyau. Ce n’est qu’après qu’ils ont testé un reboot dans le nouveau noyau pendant une fenêtre contrôlée.

Rien d’héroïque. Pas de hacks ingénieux. Juste une séquence soignée et une préférence pour les actions réversibles. C’est à ça que ressemble l’ingénierie de fiabilité quand elle fonctionne.

Erreurs courantes (symptômes → cause → correction)

1) Symptomatique : GRUB apparaît, mais booter le nouveau noyau renvoie au shell d’urgence

Cause racine : initramfs sans pilotes de stockage ou module ZFS ; DKMS n’a pas installé les modules pour le nouveau noyau ; /boot plein a produit des images partielles.

Correction : bootez sur un noyau ancien ; assurez-vous que /boot a de l’espace ; lancez dkms status ; installez les modules manquants pour le nouveau noyau ; régénérez initramfs pour ce noyau ; lancez update-grub ; testez.

2) Symptomatique : “ZFS: module not found” ou le pool ne peut pas importer au boot

Cause racine : modules ZFS non construits/installés pour le nouveau noyau, ou bloqués par la politique de signature Secure Boot.

Correction : bootez sur le noyau ancien ; rebuild/install ZFS via DKMS pour le noyau cible ; régénérez initramfs ; si Secure Boot est activé, assurez la signature/enrôlement des clés ou ajustez la politique.

3) Symptomatique : après la mise à jour, le firmware affiche “no bootable device”

Cause racine : entrée NVRAM EFI perdue ; ESP corrompue ; ESP non montée pendant la mise à jour et fichiers de boot absents de l’emplacement attendu par le firmware.

Correction : confirmez le montage de l’ESP ; inspectez /boot/efi/EFI ; recréez l’entrée de boot avec efibootmgr si nécessaire ; réinstallez les binaires GRUB EFI depuis le système en fonctionnement ou via chroot.

4) Symptomatique : le système démarre mais n’a pas de réseau

Cause racine : régression du pilote NIC ; paquet firmware manquant ; pilote DKMS échoué ; nom d’interface prévisible changé à cause d’un ordre PCI/firmware différent.

Correction : bootez sur le noyau ancien ; comparez les sorties ip link entre noyaux ; vérifiez journalctl -k pour les erreurs de chargement de pilote ; réinstallez les paquets firmware ; rebuild DKMS ; ajustez /etc/network/interfaces si les noms d’interface ont changé.

5) Symptomatique : le menu GRUB n’a qu’une seule entrée (le noyau cassé)

Cause racine : anciens noyaux purgés ; update-grub non exécuté ; /boot non monté ; images noyau manquantes.

Correction : depuis un rescue ou chroot, installez au moins un noyau connu bon ; assurez-vous que /boot est monté ; lancez update-grub. Arrêtez de purger les noyaux sans politique qui préserve la possibilité de rollback.

6) Symptomatique : écran noir après GRUB, mais ventilateurs tournent et disques clignotent

Cause racine : transfert de framebuffer/console graphique ; serial console mal configurée ; le boot continue mais vous ne pouvez pas le voir.

Correction : essayez nomodeset ; vérifiez les réglages IPMI Serial-over-LAN ; définissez des paramètres de console noyau de façon persistante si vous dépendez d’un port série. Confirmez via la connectivité réseau depuis une autre machine.

Listes de contrôle / plan étape par étape

Checklist A : récupérer le nœud maintenant (risque minimal)

1. Accédez au système via console/IPMI. Ne devinez pas à distance.
2. Forcez le menu GRUB (Shift pour BIOS, Esc pour UEFI).
3. Sélectionnez Advanced options, bootez le dernier noyau connu bon.
4. Confirmez la version du noyau avec uname -r.
5. Confirmez la santé du stockage (ZFS : zpool status ; non-ZFS : vérifiez les montages).
6. Confirmez que le réseau est suffisant pour l’accès de gestion.
7. Épinglez le noyau connu bon comme défaut avec le mécanisme saved de GRUB.

Checklist B : réparer le noyau cassé (pour pouvoir mettre à jour en sécurité)

1. Vérifiez que /boot et /boot/efi sont montés et ont de l’espace.
2. Inspectez les derniers logs de boot échoué (journalctl -b -1 -p err).
3. Si ZFS/DKMS impliqués : vérifiez dkms status et les fichiers de modules sous /lib/modules/<new-kernel>.
4. Reconstruisez l’initramfs pour le noyau cible : update-initramfs -u -k <version>.
5. Lancez update-grub et assurez-vous qu’il trouve le kernel + initrd.
6. Si problèmes UEFI : validez les entrées EFI via efibootmgr -v et le contenu de l’ESP.
7. Planifiez un reboot contrôlé vers le nouveau noyau. Restez sur la console. Capturez la sortie si ça échoue.

Checklist C : durcir contre la prochaine fois

1. Gardez au moins deux noyaux bootables installés. Traitez cela comme une politique, pas une préférence.
2. Surveillez l’utilisation de /boot et alertez avant d’atteindre 90%.
3. Pour ZFS root : assurez-vous que les modules ZFS sont construits pour les nouveaux noyaux avant le reboot (vérifications DKMS dans votre processus de changement).
4. Décidez d’une politique Secure Boot : soit supportez correctement la signature des modules, soit désactivez-le intentionnellement. Le mi‑chemin est où vivent les pannes.
5. Testez les mises à jour du noyau sur un nœud similaire d’abord (le matériel compte pour les pilotes).

FAQ

1) Revenir via GRUB est‑il “la bonne méthode” ou juste un bricolage ?

C’est la bonne méthode. Elle utilise le mécanisme conçu pour ça : plusieurs noyaux installés avec un menu de boot. Le bricolage, c’est supprimer tous les anciens noyaux.

2) Pourquoi la mise à jour Proxmox a‑t‑elle cassé le démarrage alors que la même mise à jour a marché sur un autre nœud ?

Différences matérielles. Différents HBA, NIC, GPU, versions de firmware, états Secure Boot, et dispositions ESP. Les noyaux sont polis jusqu’à ce qu’ils rencontrent votre périphérique PCI spécifique.

3) Dois‑je supprimer le paquet du noyau cassé ?

Pas immédiatement. D’abord stabilisez sur l’ancien noyau, collectez les logs, et essayez de réparer le nouveau noyau (initramfs + DKMS + ESP). Supprimez‑le seulement si vous êtes certain qu’il est irréparablement incompatible avec votre matériel ou si vous avez besoin d’espace sur /boot.

4) Combien de noyaux dois‑je garder installés ?

Au moins deux noyaux bootables (le courant stable et le précédent stable). Sur des hôtes critiques, trois n’est pas déraisonnable — surtout si vous êtes serré sur les fenêtres de changement.

5) Mon menu GRUB ne s’affiche pas. Comment le forcer définitivement ?

Depuis un système en fonctionnement, vous pouvez ajuster les paramètres GRUB (par exemple réduire le timeout ou afficher le menu). Mais opérationnellement, je préfère garder le menu principalement caché et compter sur l’accès console quand nécessaire. Si vous avez besoin qu’il soit toujours visible pour du remote hands, réglez un timeout non nul et évitez le boot “quiet” tant que vous n’êtes pas stable.

6) Je suis sur ZFS root. Ai‑je besoin d’étapes spéciales ?

Oui : vérifiez que les modules ZFS existent pour le noyau cible et que l’initramfs les inclut. Si ZFS ne peut pas se charger au boot, votre pool root ne s’importera pas et vous tomberez dans un shell initramfs.

7) Secure Boot peut‑il bloquer ZFS ou d’autres modules après une mise à jour du noyau ?

Oui. Secure Boot peut empêcher le chargement de modules noyau non signés. Si vos logs mentionnent des échecs de vérification de signature, traitez‑le comme un conflit de politique, pas un bug aléatoire de boot.

8) Le système démarre avec l’ancien noyau, mais les services Proxmox ont l’air bizarres. Et maintenant ?

Vérifiez les units échouées et l’état du cluster. Un reboot peut mettre en évidence des problèmes non liés : pools ZFS dégradés, dérive temporelle, flapping réseau corosync. Corrigez la santé de la plateforme d’abord, puis repartez vers la mise à jour.

9) Si /boot est plein, puis‑je just supprimer manuellement d’anciens fichiers initrd ?

Ne le faites pas. Supprimez les paquets noyau via le gestionnaire de paquets afin que les hooks mettent à jour GRUB et initramfs correctement. La suppression manuelle crée des menus de boot pointant vers des fichiers manquants — une manière excitante de provoquer une deuxième panne.

10) Quand dois‑je utiliser un média de secours ?

Quand GRUB ne peut booter aucun noyau, quand l’ESP est manquante/corrompue, ou quand vous avez purgé tous les noyaux fonctionnels. Le média de secours est acceptable ; c’est juste plus lent et plus facile de faire des erreurs si vous ne l’avez pas pratiqué.

Conclusion : prochaines étapes qui réduisent vraiment le risque

Si votre hôte Proxmox ne démarre plus après une mise à jour du noyau, la voie propre est : utilisez GRUB pour booter le noyau précédent, épinglez‑le par défaut, puis réparez le nouveau noyau en corrigeant initramfs, les modules DKMS (notamment ZFS), et la cohérence EFI/ESP. Rebootez dans le nouveau noyau uniquement quand vous pouvez surveiller la console et que vous avez éliminé des mines évidentes comme un /boot plein.

Faites ceci ensuite, dans l’ordre :

1. Gardez le noyau connu bon par défaut jusqu’à ce que l’upgrade soit prouvé.
2. Capturez les dernières erreurs de boot échoué (journalctl -b -1) et utilisez‑les comme feuille de route.
3. Rendez /boot banal : assez d’espace, montages corrects, et règle pour garder des noyaux de rollback.
4. Pour ZFS root : vérifiez que les modules ZFS sont installés pour chaque nouveau noyau avant de rebooter.
5. Rédigez un petit runbook interne à partir de cet incident. La prochaine fois doit prendre des minutes, pas des heures.

Les systèmes de production n’exigent pas la perfection. Ils exigent une récupération répétable. Le rollback via GRUB est votre récupération répétable — utilisez‑le avec intention.