Kmorph récupère un noyau Linux qui panique sans redémarrer la machine
Annoncé le 7 novembre 2026, le projet Kmorph remplace le reboot par un « takeover » : un noyau successeur pré-démarré reprend la main en une seconde et remet Nginx en ligne en deux secondes après un crash noyau. Il repose pour l’instant sur Multikernel, hors mainline — à surveiller, pas encore à déployer en production.
7 novembre 2026. Michael Larabel relaie sur Phoronix l’annonce de Kmorph, un projet de récupération de crash noyau sans reboot pour Linux. Une seconde. C’est le temps annoncé pour que le noyau de secours prenne la main après une panique. Deux secondes. C’est le délai pour remettre Nginx en ligne derrière. Pourquoi c’est important : un crash noyau ne signifie plus forcément un arrêt complet de la machine, un redémarrage firmware, un fsck et un opérateur de garde — mais un basculement quasi instantané vers un second noyau déjà chargé.
La panique noyau, dernier bastion du « reboot obligatoire »
Pour un SRE, une panique noyau est l’événement le plus cher du poste : elle coupe tout, sans préavis, et la seule réponse historique est le reboot. Or le reboot a un coût cumulé — arrêt des services, réinitialisation du firmware, fsck sur des volumes qui ont encaissé un arrêt sale, réassociation réseau, puis remontée de tous les services dans l’ordre. Pendant ce temps, l’application est indisponible.
Le noyau mainline propose déjà des mécanismes pour amortir le choc. Kexec permet de charger un nouveau noyau sans repasser par le firmware, et kdump capture un vmcore exploitable par crash pour comprendre l’origine de la panique. Kexec Handover (KHO) et le Live Update Orchestrator (LUO) de systemd poussent plus loin en préservant l’état des périphériques à travers un kexec — nous les avons détaillés dans notre analyse du LUO. Mais aucun de ces outils ne survit à un crash : ils accélèrent les mises à jour planifiées, pas la récupération après une panique inopinée. C’est exactement la brèche que Kmorph prétend combler.
Multikernel : plusieurs noyaux sur une même machine
Kmorph n’invente pas le basculement dans le vide. Il s’appuie sur Multikernel, un travail mené hors de l’arbre mainline depuis environ un an. Le principe : faire coexister plusieurs instances de noyau indépendantes sur une même machine physique, chacune possédant ses propres CPU, sa mémoire et ses périphériques, et communiquant entre elles par vsock — le socket virtuel habituellement réservé aux machines virtuelles, ici détourné pour la conversation entre noyaux.
Cette coexistence change la nature de la panne. Un noyau qui crashe n’est plus la machine qui meurt : c’est un noyau qui meurt, pendant qu’un second attend, déjà démarré, sur un ou deux CPU et une tranche de mémoire réservés à côté. C’est ce voisin que Kmorph orchestre.
Le « takeover » : clôturer, adopter, reprendre
Le cœur de Kmorph tient dans un mot : takeover. Quand le noyau prédécesseur panique ou se fige, le successeur exécute une séquence précise :
- il clôture (fences) les CPU du noyau mort pour garantir qu’ils ne touchent plus rien ;
- il adopte et réinitialise ses périphériques ;
- il restaure l’identité réseau de la machine — même adresse, même routage ;
- il sauvegarde, en option, un vmcore compatible kdump pour l’analyse post-mortem ;
- il ajoute à chaud les CPU et la mémoire restants et devient le noyau de la machine.
La détection jusqu’au successeur opérationnel prendrait environ une seconde, sans reboot, sans firmware, sans opérateur. Le même mécanisme sert aussi aux mises à jour : kmorph upgrade transfère une machine saine vers un successeur qui exécute un noyau plus récent. Et une fois installé, ce nouveau noyau peut armer son propre successeur, génération après génération.
La partie réellement nouvelle, selon le projet, réside dans le noyau Multikernel lui-même : la clôture, le passage de main des périphériques et de l’IOMMU, et l’ajout à chaud de CPU et de mémoire depuis un device tree hôte. Kmorph n’est que de l’orchestration en C au-dessus de ces interfaces, et il s’intègre aux distributions comme le fait kdump — via dracut, initramfs-tools, kernel-install et un service systemd.
Des services en attente pour accélérer la reprise
Le vrai saut pour l’exploitant est ailleurs : Kmorph permet de faire tourner des services systemd importants en veille sur le noyau de secours. Résultat, la reprise ne se contente pas de « redémarrer la machine » : Nginx peut revenir en ligne en deux secondes environ, avant que les services moins critiques ne redémarrent à leur tour.
C’est la différence entre disponibilité de la machine et disponibilité du service. Un reboot classique rend la machine avant de rendre le service ; Kmorph inverse la priorité en prépositionnant le service critique là où il reprendra la main. Pour un frontal web ou un point de terminaison sensible, les deux secondes annoncées se lisent presque comme une continuité de service plutôt qu’une simple récupération.
La portabilité est déjà tangible : le projet fonctionne sur x86_64 et ARM64, avec RISC-V en cours. C’est un signal sérieux — les trois architectures couvrent l’essentiel des serveurs et des machines embarquées qui peuvent se payer le luxe de deux noyaux.
Le talon d’Achille : Multikernel n’est pas mainline
La limite est structurelle, pas technique. Kmorph ne fonctionne pas sur le noyau Linux mainline : il dépend de Multikernel, qui n’a pas encore été intégré en amont, et rien ne garantit qu’il le sera. Sans l’arrivée de Multikernel dans l’arbre principal, l’adoption à grande échelle reste hypothétique.
C’est la frontière entre une preuve de concept prometteuse et un produit. Aujourd’hui, KHO et le LUO sont les réponses mainline aux mises à jour sans reboot, mais aucune ne couvre la récupération après un crash ni ne survit à une panique noyau. Kmorph montre ce qui manque : un mécanisme où le crash n’est plus un point terminal, mais un événement qu’un voisin préchargé peut absorber.
Verdict
Si vous exploitez des services critiques sur du bare metal, suivez Kmorph comme un indicateur, pas comme un composant à déployer. Son mécanisme de takeover répond à un vrai trou : la panique noyau reste le dernier scénario où l’on paie un arrêt complet. Mais tant que Multikernel n’est pas mainline, Kmorph est un projet de recherche — déployer un noyau hors arbre pour gagner deux secondes de reprise revient à échanger un risque d’indisponibilité contre un risque de maintenance exotique. En attendant, vos leviers restent kdump pour le diagnostic et KHO/LUO pour les mises à jour planifiées. Le jour où le takeover atterrit dans l’arbre principal, la question « combien coûte une panique noyau ? » changera de réponse.