Veeam Software Appliance 13.1 : kernel panic au démarrage sur les hôtes AMD EPYC, pas de correctif prévu (KB4960)

Le 4 novembre 2026, Veeam a publié la base de connaissances KB4960 : la Veeam Software Appliance, c'est-à-dire Veeam Backup & Replication livré sous forme de machine virtuelle Linux préconfigurée, peut refuser de démarrer sur un hôte équipé de certains processeurs AMD EPYC. Le noyau s'arrête en kernel panic dès les premières secondes du boot, la VM reste figée, et un simple redémarrage de l'invité ne la ramène pas : il faut l'éteindre et la rallumer depuis l'hyperviseur. Veeam situe le bug dans le noyau Linux lui-même, indique qu'aucun correctif n'est disponible pour la version de noyau embarquée dans l'appliance, et ne donne pas de calendrier. Seules les versions 13.1 et ultérieures sont touchées. Si votre serveur de sauvegarde tourne dans une VM sur un serveur dédié AMD EPYC, voici le symptôme exact à repérer, pourquoi il se produit, et les trois contournements que Veeam met sur la table.

Sources : KB4960, Veeam Software Appliance Fails to Boot with Kernel Panic on AMD EPYC Hosts (Veeam, 4 novembre 2026), notes de version de Veeam Backup & Replication 13.1, Configuring Updates et How Updates Work (Veeam Help Center), code source du noyau Linux amont (crypto/jitterentropy-kcapi.c et crypto/jitterentropy.c) et de la lignée RHEL 9 (CentOS Stream 9), documentation sysctl du noyau, KB4966 (Veeam, 6 novembre 2026), bug Ubuntu n° 2069715 (Launchpad, 2024), BleepingComputer (6 novembre 2026).

Le symptôme exact à repérer

Le scénario décrit par Veeam est toujours le même : l'appliance redémarre, le plus souvent après l'installation d'une mise à jour qui apporte un nouveau noyau, et ne revient pas. Sur la console de la machine virtuelle, le démarrage s'interrompt très tôt, pendant l'initialisation du noyau, sur une ligne de ce type :

Kernel panic - not syncing: jitterentropy: Initialization failed with host not compliant with requirements: 9

Trois détails comptent pour le diagnostic. D'abord, le défaut est intermittent : la même VM, sur le même hôte, peut démarrer dix fois sans problème puis échouer au onzième reboot. Ensuite, le message n'est pas toujours visible dans la console graphique : selon l'hyperviseur, il peut n'apparaître que sur la console série de la VM ou dans le journal d'événements de l'hyperviseur. Une VM qui semble simplement « bloquée sur un écran noir » après un reboot mérite donc qu'on aille lire la sortie série avant de conclure à autre chose. Enfin, une fois que l'appliance a réussi à démarrer, Veeam indique qu'aucune autre erreur n'est attendue : les sauvegardes, les restaurations et la réplication fonctionnent normalement. Le problème se joue uniquement dans les premières secondes du boot.

Pourquoi le noyau s'arrête : jitterentropy, mode FIPS et code 9

Le mot jitterentropy désigne un générateur d'aléa du noyau Linux. Pour alimenter ses fonctions cryptographiques, le noyau a besoin d'entropie, et l'une de ses sources est la gigue temporelle du processeur : le temps exact que met le CPU à exécuter une même série d'instructions varie légèrement d'une fois sur l'autre, à cause des caches, des pipelines et des interruptions, et ces variations microscopiques sont imprévisibles. Au chargement du module, le noyau mesure cette gigue pendant 1 024 itérations, précédées de 100 tours de chauffe, et fait passer les mesures par des tests de santé hérités des normes cryptographiques : un test de répétition (RCT, repetition count test) qui détecte une valeur qui se répète trop, et un test de proportion adaptative (APT, adaptive proportion test) qui détecte une valeur trop fréquente sur une fenêtre donnée. Si le processeur est jugé trop régulier, trop prévisible, l'initialisation échoue.

Ce qui se passe ensuite dépend d'un seul paramètre : le mode FIPS. Dans le fichier crypto/jitterentropy-kcapi.c du noyau, la fonction d'initialisation du module teste fips_enabled. Si le noyau démarre en mode FIPS, l'échec se termine par un appel à panic() avec exactement le message cité plus haut ; sinon, le noyau écrit la même phrase en simple information dans son journal et le démarrage continue. La logique est celle des certifications FIPS 140-3 : un système qui ne peut pas prouver la qualité de sa source d'aléa ne doit pas tourner du tout. Cette règle se vérifie aussi bien dans la branche amont du noyau (Linux 7.3.3) que dans la lignée RHEL 9 (série 5.14), dont dérive la Rocky Linux sur laquelle Veeam a bâti son appliance. La KB4966, publiée deux jours plus tard pour une autre faille, nomme d'ailleurs le noyau que l'Updater distribue à l'appliance 13.1 : un 5.14.0-570.60.1 estampillé el9_6, compilé par CIQ. Veeam documente l'appliance comme conforme à la plupart des exigences DISA STIG pour RHEL 9, avec quatre exceptions listées, et interdit d'y installer le moindre logiciel tiers ; la KB4960 précise que son noyau exécute le test jitterentropy en mode FIPS. C'est précisément ce mode qui transforme un test raté en machine inutilisable.

Le code 9 à la fin du message n'est pas anodin. Dans crypto/jitterentropy.c, les codes d'erreur sont numérotés : 1 pour une horloge absente, 2 pour une horloge trop grossière, 3 pour une horloge non monotone, 8 pour trop de mesures « bloquées », 9 pour JENT_EHEALTH, échec du test de santé à l'initialisation. Dans la lignée RHEL 9 du noyau, celle de l'appliance, ce code 9 est renvoyé dès que l'un des deux tests, RCT ou APT, échoue pendant la boucle de mesure ; le noyau amont actuel est plus précis et réserve le code 10 à l'échec du RCT, le 9 désignant alors l'APT. Dans les deux cas, sur les EPYC concernés, les mesures de temps ne sont ni absentes ni cassées : elles sont jugées pas assez variées sur l'échantillon mesuré. Un commentaire du code rappelle que la norme SP 800-90B impose au moins 1 024 cycles de test initiaux, et comme un test statistique sur un millier de mesures ne donne jamais deux fois le même résultat, l'échec est intermittent. Un autre commentaire note que « seuls les vieux systèmes » devraient présenter une gigue problématique ; les EPYC de la série 7002 datent de 2019.

Ce test et ces processeurs se sont d'ailleurs déjà rencontrés. En juin 2024, le bug Ubuntu n° 2069715 décrivait un kernel panic au démarrage du noyau FIPS d'Ubuntu 20.04 sur un AMD EPYC 7262, les processeurs Intel n'étant pas touchés. L'analyse, reprise dans le correctif amont intitulé « crypto: jitter - consider 32 LSB for APT », était précise : le test de proportion adaptative ne comparait que les 4 bits de poids faible de chaque mesure de temps, or sur ces EPYC les valeurs du compteur de cycles (RDTSC) ont leurs bits de poids faible à zéro, le plus grand diviseur commun des mesures valant systématiquement 32. Vu à travers ce filtre de 4 bits, le processeur semblait renvoyer indéfiniment la même valeur. Le correctif élargit la comparaison à 32 bits, et le noyau Ubuntu corrigé a démarré sans incident sur la même machine. Veeam ne dit pas si le mécanisme est le même sur le noyau de son appliance, ni si ce correctif y figure : la KB se limite à constater l'échec et à renvoyer vers le noyau.

Dernier maillon de la chaîne : pourquoi la VM reste-t-elle figée au lieu de redémarrer ? Parce qu'un noyau Linux en panic ne fait, par défaut, plus rien du tout. Le paramètre kernel.panic vaut 0 sur la plupart des distributions, ce qui, selon la documentation du noyau, signifie « boucler indéfiniment ». Un redémarrage demandé depuis l'hyperviseur par la voie normale passe par un signal ACPI que le noyau mort ne traitera jamais. C'est pour cela que Veeam insiste : un redémarrage de l'invité ne récupère pas la machine, seul un power off suivi d'un power on, c'est-à-dire la destruction et la recréation du processus de la VM, relance un vrai boot.

Qui est concerné : serveur dédié EPYC, hyperviseur et version

Trois conditions doivent être réunies. La version : Veeam Software Appliance 13.1 ou plus récente, la branche 13.1 étant disponible depuis le 29 juillet 2026 selon ses notes de version. Le format : l'appliance Linux, pas l'installation classique de Veeam Backup & Replication sur Windows Server, qui n'exécute évidemment pas ce noyau. Le processeur de l'hôte : Veeam cite « certains processeurs AMD EPYC » et en nomme trois, tous de la deuxième génération EPYC, la série 7002 (architecture Zen 2, souvent appelée Rome, lancée en août 2019).

La formulation de la KB laisse la liste ouverte : ces trois modèles sont ceux sur lesquels le problème a été reproduit, pas une liste exhaustive. Un administrateur qui héberge l'appliance sur un EPYC d'une autre référence, ou d'une génération ultérieure, n'a aucune garantie dans un sens ou dans l'autre. En revanche, aucun processeur Intel n'est mentionné. Les notes de version de la 13.1 contenaient déjà un avertissement voisin, formulé pour la Veeam Infrastructure Appliance, l'image Linux que Veeam fournit pour ses composants d'infrastructure : des machines virtuelles pouvant « ne pas démarrer sur des hôtes AMD », avec un kernel panic « lié à la génération d'entropie conforme FIPS ». La KB4960 confirme et précise ce qui n'était jusque-là qu'une ligne dans une liste de problèmes connus.

Pour savoir où vous en êtes, deux commandes suffisent. Sur l'hôte Proxmox VE ou sur toute autre machine Linux, la première affiche le modèle exact du processeur physique ; la seconde, lancée dans n'importe quelle VM Linux, indique si son noyau tourne en mode FIPS (1) ou non (0), ce qui explique pourquoi vos autres machines virtuelles survivent au même test :

# Modèle du processeur physique de l'hôte
lscpu | grep -i 'model name'

# Dans une VM Linux : 1 = mode FIPS actif, 0 = test de santé sans conséquence
cat /proc/sys/crypto/fips_enabled

L'hyperviseur, lui, n'a pas d'importance : le test de santé s'exécute dans le noyau de l'invité, et il mesure le comportement du processeur physique que l'hyperviseur lui expose. VMware vSphere, Microsoft Hyper-V ou Proxmox VE sur KVM sont logés à la même enseigne, et la KB ne fait aucune distinction. Elle ne dit rien non plus d'une installation directement sur un serveur physique EPYC, que Veeam prévoit par ailleurs sur du matériel certifié ; le mécanisme en cause ne dépend pas de la virtualisation, mais en l'absence de confirmation de l'éditeur, ce cas reste une zone grise.

Concrètement, pour un administrateur qui a installé Proxmox VE ou un autre hyperviseur sur un serveur dédié AMD EPYC chez n'importe quel hébergeur, ou qui a apporté sa propre machine EPYC en housing en datacenter, et qui y fait tourner sa Veeam Software Appliance 13.1 : chaque redémarrage de l'appliance devient un pari, et le pari se perd en général au pire moment, pendant une mise à jour automatique nocturne. Les serveurs dédiés ElypseCloud sont, eux, équipés de processeurs Intel Xeon (bi-processeur E5-2620 v4, ou Xeon Gold 6230 sur la gamme supérieure), qui ne font pas partie du périmètre décrit par la KB.

Les contournements officiels, et leurs pièges

Veeam ne propose pas de correctif, pas de paramètre de noyau à modifier, pas de hotfix. L'appliance n'est pas conçue pour qu'on y installe des logiciels tiers ni qu'on retouche son noyau, et désactiver le mode FIPS n'est pas une option documentée. Restent trois réponses, par ordre de préférence de l'éditeur.

1. Redéployer l'appliance sur un hôte avec un autre processeur

C'est la solution recommandée. Elle consiste à installer une nouvelle Veeam Software Appliance depuis l'ISO sur un hôte dont le processeur n'est pas concerné, puis à y migrer la configuration. Dans une infrastructure avec plusieurs hôtes de virtualisation, dont au moins un Intel ou un EPYC d'une autre génération, c'est une opération de migration de VM classique. Sur un serveur dédié unique, cela revient à changer de serveur, ce qui est rarement anodin : d'où l'intérêt des deux options suivantes pour tenir en attendant.

2. Désactiver les mises à jour automatiques de l'appliance

Le danger numéro un est la mise à jour installée sans surveillance, parce qu'elle redémarre l'appliance toute seule. La documentation Veeam est claire : « les mises à jour et l'installation de hotfix redémarrent automatiquement les services », et le serveur lui-même est redémarré « si nécessaire », ce qui est le cas de tout nouveau noyau. Pour reprendre la main, connectez-vous à la console Veeam Host Management de l'appliance, ouvrez Updates dans le volet de gestion, puis l'onglet Settings. Le réglage qui compte est la fenêtre de maintenance (Maintenance window) : elle peut être hebdomadaire, mensuelle, ou None, qui désactive l'installation planifiée et vous laisse installer à la main. Enregistrez avec Save.

Il y a un piège, et il est documenté. Même avec la fenêtre réglée sur None, la date limite de conformité (Compliance deadline) reste active : par défaut, les mises à jour obligatoires sont installées de force 30 jours après leur détection, et ce délai peut être repoussé jusqu'à 90 jours. Passer en manuel ne vous dispense donc pas d'installer : cela vous donne au mieux trois mois pour choisir le moment. Notez aussi que l'Updater interroge le dépôt de Veeam toutes les 12 heures, que la fenêtre par défaut tombe le dimanche à 14 h, heure du serveur de sauvegarde, d'après la KB4966, et que, par défaut, seules les mises à jour de sécurité sont retenues pour l'installation automatique ; les mises à jour optionnelles peuvent s'y ajouter, jamais les versions majeures.

3. Mettre à jour à la main, en surveillant le redémarrage

La procédure manuelle se lance depuis le même endroit : onglet Updates, sélection des mises à jour, bouton What's new? pour lire le détail, puis Install Updates Now, ou Schedule Updates pour choisir un créneau. La documentation de l'Updater rappelle qu'aucune tâche ne doit tourner à ce moment-là : les opérations de restauration en cours échoueraient. Puis vient l'étape qui fait toute la différence : rester devant la console pendant le redémarrage. Si le kernel panic apparaît, éteignez la VM et rallumez-la, autant de fois que nécessaire, jusqu'à ce que le test de santé passe. Les commandes à utiliser sont celles de l'arrêt forcé, pas du redémarrage propre :

# Proxmox VE : arrêt forcé (le processus QEMU est tué), puis démarrage
qm stop 110
qm start 110

# Pour lire la sortie série de la VM si elle est configurée
qm terminal 110

Sur Proxmox VE, qm reboot et qm shutdown passent par un arrêt propre que le noyau figé ignorera. Sur vSphere, utilisez Power Off puis Power On, et non Restart Guest OS ; sur Hyper-V, Turn Off puis Start, et non Shut Down. Si vous administrez l'hyperviseur à distance, assurez-vous avant de lancer l'opération que vous disposez d'un accès à la console de la VM, et idéalement au KVM/IPMI du serveur physique, au cas où ce serait l'hôte lui-même que vous auriez à redémarrer un jour. Notre guide sur la mise à jour et la sécurisation de Proxmox VE sur serveur dédié détaille cette préparation.

Ne pas confondre avec les autres échecs de démarrage de l'appliance

Un serveur de sauvegarde qui ne démarre plus a plusieurs causes possibles, et la 13.1 en documente au moins une autre : sur Hyper-V, l'appliance ne démarre pas si Secure Boot est activé avec un autre modèle que « Microsoft UEFI Certificate Authority ». Ce cas-là est déterministe, pas intermittent, et se manifeste avant même le chargement du noyau, sans message jitterentropy. Le réflexe est le même que pour nos explications sur Secure Boot et les certificats UEFI : vérifier le modèle de certificats de la VM. De même, une mise à jour de noyau qui échoue pour une raison de disque plein ou de dépendance laisse des traces dans les journaux de l'Updater, conservés dans /var/log/veeam/veeam-updater/, alors que le panic de KB4960 intervient si tôt dans le démarrage qu'il ne laisse en général aucune trace dans les journaux sur disque.

Le calendrier n'aide pas à y voir clair : le jour même où la presse spécialisée relayait KB4960, Veeam publiait la KB4966 pour annoncer que plusieurs de ses produits Linux, dont la Software Appliance, étaient concernés par la faille critique CVE-2026-98432 du noyau Linux. Pour l'appliance 13.1, le correctif est disponible dans le dépôt Veeam depuis le 2 novembre, sous la forme d'un nouveau noyau, et Veeam prévient qu'« un redémarrage de l'appliance peut être nécessaire ». Un noyau correctif de sécurité est exactement le type de mise à jour qui déclenche un redémarrage de l'appliance ; sur un hôte EPYC concerné, c'est donc le correctif qui vous expose au blocage. Ce n'est pas une raison pour le retarder, mais une raison de l'installer à la main, en journée, devant la console.

Ce que cela change pour votre plan de sauvegarde

Une appliance bloquée en panic n'est pas une catastrophe en soi, à condition que quelqu'un s'en aperçoive. Pendant qu'elle est figée, aucune sauvegarde ne part, aucune réplication ne tourne, et la fenêtre de rétention continue de s'écouler. Le point faible d'un serveur de sauvegarde unique est là : il est rarement supervisé avec la même attention que la production qu'il protège. Supervisez l'appliance comme un service critique, avec une alerte sur l'absence de ping et sur l'absence de tâche terminée dans les 24 heures, et gardez un second canal pour vérifier que les sauvegardes existent réellement hors de l'appliance, par exemple des copies chiffrées sur un site distant comme nous le décrivons dans le guide sur le chiffrement des sauvegardes hors site. Si l'appliance Veeam est elle-même l'unique copie de votre configuration de sauvegarde, exportez-la avant chaque mise à jour.

Ce bug rappelle aussi une règle de conception valable pour tout plan de sauvegarde et de haute disponibilité sur serveur dédié : le serveur de sauvegarde ne doit pas dépendre d'un seul composant matériel dont vous ne maîtrisez ni le fournisseur ni le calendrier de correction. Veeam renvoie vers le noyau Linux, le noyau vers un test statistique, et personne n'annonce de date. En attendant, l'administrateur d'un hôte EPYC 7262, 7302 ou 7F72 a le choix entre surveiller chaque redémarrage ou changer de processeur. Pour les équipes qui remettent à plat leur infrastructure à cette occasion, nos guides sur le choix entre Proxmox VE et VMware pour un serveur dédié et sur la mise à jour de Veeam après la faille CVE-2026-108142 complètent cette actualité. Si le problème persiste après application des contournements, Veeam invite à ouvrir un dossier auprès de son support.