Ubuntu 24.04 : DKMS cassé après mise à jour du noyau — récupérer les pilotes sans interruption

Comment DKMS échoue réellement après une mise à jour du noyau

DKMS (Dynamic Kernel Module Support) existe parce que les fournisseurs continuent de livrer des modules noyau qui ne sont pas dans le noyau principal. NVIDIA, ZFS‑on‑Linux, certains pilotes NIC et RAID, VirtualBox, certains agents de sécurité — tout ce qui compile contre des en‑têtes du noyau est concerné.

Lorsque Ubuntu installe un nouveau noyau, les scripts du paquet tentent de reconstruire les modules DKMS pour ce noyau. Si cette reconstruction échoue, vous pouvez ne pas le remarquer immédiatement parce que le noyau en cours d’exécution a encore des modules fonctionnels chargés. La panne apparaît lorsque :

• Vous redémarrez et le nouveau noyau démarre sans le module.
• l’initramfs a été généré sans le module, provoquant des échecs en début de démarrage (stockage, root‑on‑ZFS, chiffrement, etc.).
• Secure Boot bloque le module non signé, et vous obtenez le cas particulier « construit mais non chargeable ».
• les en‑têtes du nouveau noyau n’étaient pas installés, donc DKMS n’avait rien contre quoi compiler.

La plupart des incidents « DKMS cassé » sont l’un de ces quatre cas. La solution n’est que rarement mystérieuse ; le problème est le plus souvent chronophage et opérationnellement stressant. L’astuce est de réduire le risque : diagnostiquer précisément, construire pour le noyau dans lequel vous comptez démarrer, valider la possibilité de chargement, et seulement alors autoriser les redémarrages.

Vérité sèche : DKMS n’est pas « dynamique » comme l’imagine la direction. C’est « dynamique » comme un formulaire papier : on peut le remplir à nouveau chaque fois que le noyau change.

Playbook de diagnostic rapide

Quand vous cherchez à éviter une interruption, la vitesse compte. Le chemin le plus rapide est : identifier le noyau cible, confirmer si le module existe pour lui, confirmer s’il peut se charger, puis valider les artefacts de démarrage (initramfs). Tout le reste est de la garniture.

Première étape : quel noyau exécutez‑vous et quels noyaux sont installés ?

• Si vous exécutez encore l’ancien noyau, vous pouvez reconstruire calmement avant de redémarrer.
• Si vous êtes déjà sur le nouveau noyau et que des modules manquent, vous devez rétablir la fonctionnalité sur le noyau en cours (parfois possible, parfois non).

Deuxième étape : DKMS indique‑t‑il « built » pour le noyau cible ?

• Si ce n’est pas construit : vous êtes en mode « reconstruire et résoudre les dépendances de build ».
• Si c’est construit : vérifiez s’il a été installé dans /lib/modules/<kernel> et si modprobe réussit.

Troisième étape : Secure Boot bloque‑t‑il le module ?

• Secure Boot activé + module non signé = il se compilera mais échouera au chargement avec des erreurs de signature.
• C’est la boucle numéro un « je l’ai reconstruit trois fois et rien n’a changé ».

Quatrième étape : l’initramfs contient‑il ce dont vous avez besoin ?

• Si le module est nécessaire au démarrage précoce (root‑on‑ZFS, stockage, crypto), « construit » ne suffit pas.
• Regénérez l’initramfs pour le noyau cible et vérifiez qu’il contient le module.

Cinquième étape : bloquez les changements risqués pendant que vous réparez

• Mettre en attente les paquets noyau si les mises à jour automatiques continuent de tirer de nouveaux noyaux pendant votre récupération.
• Épingler un noyau connu bon comme option de retour arrière.

Faits et contexte intéressants (pourquoi cela se répète)

• DKMS est né dans l’écosystème Dell au milieu des années 2000 pour maintenir les pilotes fournisseurs compilables lors des montées de noyau, surtout sur les flottes d’entreprise.
• Ubuntu intègre DKMS depuis des années, mais cela repose toujours sur les scripts de packaging et la présence des en‑têtes — pas d’en‑têtes, pas de module.
• La rigidité de Secure Boot a transformé les “échecs de build” en “échecs de chargement”. Le module peut compiler parfaitement et être rejeté par le noyau.
• ZFS on Linux a longtemps vécu hors‑arbre pour des raisons de licence ; cette histoire explique pourquoi beaucoup d’installations Ubuntu s’appuient encore sur DKMS pour ZFS.
• La stabilité de l’ABI du noyau n’est pas garantie pour les modules hors‑arbre. Des montées mineures du noyau peuvent casser les builds si le module utilise des API internes.
• Le rythme HWE et SRU d’Ubuntu peut vous surprendre : une mise à jour du noyau peut arriver via unattended upgrades même si vous « n’avez rien changé ».
• l’initramfs est souvent le véritable domaine de défaillance. Le système démarre un noyau ; puis l’espace utilisateur précoce ne trouve pas le module de stockage dont il a besoin.
• Les builds DKMS peuvent être affectés par des changements d’outillage (gcc, make, binutils). « Noyau mis à jour » signifie parfois aussi « votre compilateur a bougé ».
• Certains fournisseurs livrent des modules précompilés pour des versions de noyau spécifiques, mais les versions de noyau d’Ubuntu dérivent ; DKMS devient le repli — jusqu’à ce qu’il ne le soit plus.

Une citation qui a survécu à plus de postmortems que quiconque ne le mérite : « L’espoir n’est pas une stratégie. » — Gene Kranz. Elle s’applique aussi aux reconstructions DKMS.

Tâches pratiques : commandes, sorties et décisions (12+)

Ceci n’est pas « exécutez tout ». C’est une boîte à outils. Chaque tâche inclut : la commande, une sortie d’exemple, ce que cela signifie, et la décision que vous prenez à partir de là.

Task 1: Confirm the running kernel

cr0x@server:~$ uname -r
6.8.0-51-generic

Ce que cela signifie : C’est le noyau en cours d’exécution. Si DKMS a cassé lors de l’installation d’un noyau plus récent, vous pouvez généralement le réparer sans interruption immédiate, car vous n’utilisez pas encore ce nouveau noyau.

Décision : Si le noyau en cours est toujours le noyau connu bon, effectuez votre reconstruction DKMS pour le nouveau noyau maintenant, puis planifiez un redémarrage contrôlé plus tard.

Task 2: List installed kernels and see what the next reboot will likely use

cr0x@server:~$ dpkg -l 'linux-image-*generic' | awk '/^ii/{print $2,$3}'
linux-image-6.8.0-51-generic 6.8.0-51.52
linux-image-6.8.0-52-generic 6.8.0-52.53

Ce que cela signifie : Vous avez au moins deux noyaux installés ; la version la plus élevée est généralement sélectionnée au démarrage.

Décision : Identifiez le noyau « cible » pour lequel vous devez avoir des modules DKMS (ici : 6.8.0-52-generic).

Task 3: Check DKMS status across kernels

cr0x@server:~$ dkms status
zfs/2.2.2, 6.8.0-51-generic, x86_64: installed
zfs/2.2.2, 6.8.0-52-generic, x86_64: built
nvidia/550.90.07, 6.8.0-51-generic, x86_64: installed
nvidia/550.90.07, 6.8.0-52-generic, x86_64: added

Ce que cela signifie : « installed » signifie que le module est compilé et copié dans /lib/modules/<kernel>. « built » est compilé mais peut ne pas être installé. « added » signifie que DKMS connaît la source mais ne l’a pas construite pour ce noyau.

Décision : Pour le noyau cible, tout ce qui n’est pas « installed » est un risque. Construisez + installez maintenant.

Task 4: Verify kernel headers exist for the target kernel

cr0x@server:~$ dpkg -l | awk '/linux-headers-6.8.0-52-generic/{print $1,$2,$3}'
ii linux-headers-6.8.0-52-generic 6.8.0-52.53

Ce que cela signifie : DKMS a besoin des en‑têtes. Si cela manque, DKMS échouera avec des erreurs du type « Kernel headers for target not found. »

Décision : Si les en‑têtes manquent, installez‑les avant de reconstruire les modules DKMS.

Task 5: Install the missing headers (if needed)

cr0x@server:~$ sudo apt-get update
Hit:1 http://archive.ubuntu.com/ubuntu noble InRelease
Reading package lists... Done

cr0x@server:~$ sudo apt-get install -y linux-headers-6.8.0-52-generic
Reading package lists... Done
Building dependency tree... Done
The following NEW packages will be installed:
  linux-headers-6.8.0-52-generic
Setting up linux-headers-6.8.0-52-generic (6.8.0-52.53) ...

Ce que cela signifie : Les en‑têtes sont maintenant présentes ; DKMS a une chance raisonnable.

Décision : Reconstruisez les modules DKMS pour le noyau cible.

Task 6: Trigger DKMS autoinstall for the target kernel

cr0x@server:~$ sudo dkms autoinstall -k 6.8.0-52-generic
Sign command: /lib/modules/6.8.0-52-generic/build/scripts/sign-file
Signing key: /var/lib/shim-signed/mok/MOK.priv
Public certificate (MOK): /var/lib/shim-signed/mok/MOK.der
Building module:
Cleaning build area... done.
Building module(s).... done.
Installing /lib/modules/6.8.0-52-generic/updates/dkms/zfs.ko
Installing /lib/modules/6.8.0-52-generic/updates/dkms/nvidia.ko
depmod... done.

Ce que cela signifie : DKMS a construit et installé les modules pour ce noyau spécifique, et depmod a mis à jour les cartes de dépendances des modules.

Décision : Si cela a réussi, passez à la validation : le module peut‑il se charger (ou au moins est‑il présent et signé) ?

Task 7: If it fails, read the DKMS build log like you mean it

cr0x@server:~$ sudo tail -n 40 /var/lib/dkms/nvidia/550.90.07/build/make.log
CONFTEST: drm_prime_pages_to_sg_has_drm_device_arg
CONFTEST: drm_gem_object_put_unlocked
error: implicit declaration of function ‘drm_gem_object_put_unlocked’
make[2]: *** [scripts/Makefile.build:243: /var/lib/dkms/nvidia/550.90.07/build/nvidia-drm/nvidia-drm-gem.o] Error 1
make[1]: *** [Makefile:1926: /var/lib/dkms/nvidia/550.90.07/build] Error 2
make: *** [Makefile:234: __sub-make] Error 2

Ce que cela signifie : C’est un décalage d’API au moment de la compilation. Ce n’est pas un paquet manquant ; le code source du module ne prend pas en charge cette API du noyau.

Décision : Arrêtez d’essayer des reconstructions aléatoires. Vous avez besoin d’une version du pilote/module compatible avec ce noyau (par ex. mettre à jour le paquet NVIDIA), ou vous devez démarrer sur l’ancien noyau jusqu’à résolution.

Task 8: Validate module presence for the target kernel without rebooting

cr0x@server:~$ ls -l /lib/modules/6.8.0-52-generic/updates/dkms/ | egrep 'zfs|nvidia' | head
-rw-r--r-- 1 root root  8532480 Dec 29 10:12 nvidia.ko
-rw-r--r-- 1 root root 17362944 Dec 29 10:12 zfs.ko

Ce que cela signifie : Les fichiers existent à l’endroit où DKMS les place pour ce noyau.

Décision : Validez ensuite la possibilité de chargement et l’état de signature (surtout si Secure Boot est activé).

Task 9: Check Secure Boot state (the “built but blocked” detector)

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

Ce que cela signifie : Le noyau appliquera la vérification de signature des modules. Les modules DKMS non signés échoueront au chargement.

Décision : Si Secure Boot est activé, assurez‑vous que les modules DKMS sont signés avec une clé enregistrée, ou prévoyez un flux contrôlé d’enregistrement MOK.

Task 10: Attempt to load the module on the running kernel (only when safe)

cr0x@server:~$ sudo modprobe -v zfs
insmod /lib/modules/6.8.0-51-generic/updates/dkms/spl.ko
insmod /lib/modules/6.8.0-51-generic/updates/dkms/zfs.ko

Ce que cela signifie : Sur le noyau en cours, le chargement du module réussit. C’est un contrôle de cohérence montrant que votre installation DKMS n’est pas globalement cassée.

Décision : Si modprobe échoue avec « Required key not available », vous êtes en plein problème de signature Secure Boot. Si il échoue avec « Unknown symbol », vous avez un décalage noyau/module.

Task 11: Inspect kernel logs for signature or symbol errors

cr0x@server:~$ sudo dmesg -T | tail -n 20
[Mon Dec 29 10:19:02 2025] Lockdown: modprobe: unsigned module loading is restricted; see man kernel_lockdown.7
[Mon Dec 29 10:19:02 2025] nvidia: module verification failed: signature and/or required key missing - tainting kernel

Ce que cela signifie : Secure Boot ou la politique lockdown bloque ou marque le noyau. Certains environnements tolèrent la marque (taint) ; d’autres la considèrent comme non conforme.

Décision : Si votre politique exige des modules signés, corrigez la signature et l’enregistrement maintenant, avant de redémarrer sur un noyau qui refusera complètement le module.

Task 12: Verify initramfs was rebuilt for the target kernel

cr0x@server:~$ ls -lh /boot/initrd.img-6.8.0-52-generic
-rw-r--r-- 1 root root 98M Dec 29 10:14 /boot/initrd.img-6.8.0-52-generic

Ce que cela signifie : L’initramfs existe et a été mis à jour récemment, mais cela ne garantit pas qu’il contient votre module.

Décision : Si le module est nécessaire au démarrage (ZFS root, HBA de stockage, NIC spéciale), vous devez vérifier sa présence à l’intérieur de l’initramfs.

Task 13: Confirm the module is inside initramfs (the “trust but verify” step)

cr0x@server:~$ lsinitramfs /boot/initrd.img-6.8.0-52-generic | egrep '/zfs\.ko|/nvidia\.ko' | head
usr/lib/modules/6.8.0-52-generic/updates/dkms/zfs.ko

Ce que cela signifie : ZFS est inclus dans l’espace utilisateur précoce pour ce noyau. Pour les GPU, il n’est généralement pas nécessaire dans l’initramfs ; pour les scénarios de boot stockage/réseau, il peut l’être.

Décision : Si manquant, regénérez l’initramfs après avoir réparé l’installation DKMS.

Task 14: Rebuild initramfs for a specific kernel (targeted, not shotgun)

cr0x@server:~$ sudo update-initramfs -u -k 6.8.0-52-generic
update-initramfs: Generating /boot/initrd.img-6.8.0-52-generic

Ce que cela signifie : Vous avez forcé la régénération de l’initramfs pour le noyau qui vous importe.

Décision : Relancez les contrôles lsinitramfs ; seulement après cela envisagez le redémarrage.

Task 15: Ensure the module dependency map is correct for the target kernel

cr0x@server:~$ sudo depmod -a 6.8.0-52-generic

Ce que cela signifie : modules.dep et assimilés sont mis à jour. Certains scripts postinst le font ; certains échecs l’omettent. Lancer manuellement est peu coûteux.

Décision : Si modprobe se plaint ensuite de dépendances introuvables, vous avez probablement manqué depmod ou les modules ont été placés dans un chemin non standard.

Task 16: Hold kernel updates while you stabilize (optional but often wise)

cr0x@server:~$ sudo apt-mark hold linux-image-generic linux-headers-generic
linux-image-generic set on hold.
linux-headers-generic set on hold.

Ce que cela signifie : Vous empêchez les méta‑paquets de noyau d’installer automatiquement de nouveaux noyaux.

Décision : Utilisez cela pendant la réponse à incident. Retirez la mise en attente une fois que vous avez une chaîne DKMS reproductible et une porte de validation.

Task 17: Confirm what will be the default boot entry (so you don’t reboot into the trap)

cr0x@server:~$ grep -E 'GRUB_DEFAULT|GRUB_TIMEOUT|GRUB_SAVEDEFAULT' /etc/default/grub
GRUB_DEFAULT=0
GRUB_TIMEOUT=5

Ce que cela signifie : Par défaut, l’entrée numéro un du menu est choisie, typiquement le noyau le plus récent.

Décision : Si le noyau le plus récent n’a pas de modules fonctionnels, soit corrigez DKMS pour celui‑ci, soit paramétrez temporairement GRUB pour démarrer sur le noyau connu bon.

Task 18: Spot “half-configured” packages after a messy update

cr0x@server:~$ sudo dpkg --audit
The following packages are in a mess due to serious problems during installation. They must be reinstalled for them to work properly:
 linux-image-6.8.0-52-generic

Ce que cela signifie : L’installation du paquet noyau ne s’est pas terminée proprement, ce qui peut sauter les déclencheurs DKMS et la génération d’initramfs.

Décision : Corrigez l’état du packaging avant de déboguer DKMS indéfiniment.

Task 19: Repair package state and re-run postinst triggers

cr0x@server:~$ sudo apt-get -f install
Reading package lists... Done
Building dependency tree... Done
Correcting dependencies... Done
Setting up linux-image-6.8.0-52-generic (6.8.0-52.53) ...
update-initramfs: Generating /boot/initrd.img-6.8.0-52-generic

Ce que cela signifie : Les hooks post‑install du noyau ont été exécutés. Cela inclut souvent les déclencheurs de reconstruction DKMS.

Décision : Revérifiez dkms status pour le noyau cible ; validez de nouveau la présence des modules et le contenu de l’initramfs.

Blague 1 : DKMS, c’est comme un abonnement à la salle de sport : vous ne remarquez qu’il ne fonctionne pas quand vous essayez de vous en servir.

Récupérer les pilotes sans interruption : stratégie efficace

« Sans interruption » ne signifie pas magie. Cela signifie éviter de redémarrer sur un noyau incapable de charger des modules critiques, et éviter de réinitialiser du matériel en plein trafic. Pour la plupart des incidents DKMS, le système fonctionne encore sur le noyau précédent et tout va bien — jusqu’au redémarrage. C’est votre fenêtre.

Étape 1 : Décidez ce que signifie « pilote critique » sur cet hôte

Ne traitez pas tous les modules DKMS de la même façon. Un module VirtualBox manquant sur un serveur est ennuyeux ; un module de stockage manquant sur un nœud root‑on‑ZFS est catastrophique. Classez l’hôte :

• Critique stockage : root ZFS, pools ZFS, pilotes HBA, dépendances dm‑crypt.
• Critique réseau : pilotes NIC hors‑arbre (rare sur Ubuntu, mais existant), modules DPDK, piles SR‑IOV, offloads fournisseurs.
• Critique calcul : nœuds GPU NVIDIA, clusters ML, transcodeurs vidéo.
• « Agréable à avoir » : pilotes sur postes développeurs et modules non essentiels.

Critique signifie : pas de redémarrage tant que le noyau cible n’a pas un module validé, chargeable et un initramfs sain.

Étape 2 : Construisez pour le noyau dans lequel vous démarrerez, pas pour celui que vous exécutez

Les paramètres par défaut de DKMS peuvent vous induire en erreur. Si vous lancez simplement dkms autoinstall sans -k, il cible souvent le noyau en cours. Ce n’est pas ce dont vous avez besoin en récupération. Vous avez besoin du noyau qui sera utilisé au prochain démarrage.

Construisez explicitement pour la version de noyau cible. Toujours.

Étape 3 : Préférez les paquets fournisseurs qui suivent votre ligne de noyau

Quand un module DKMS ne se compile pas à cause d’un décalage d’API, vous avez deux choix réalistes :

• Mettre à jour le paquet pilote/module vers une version compatible avec le nouveau noyau.
• Retarder le redémarrage et épingler la version du noyau jusqu’à ce qu’un pilote compatible existe.

Tenter de patcher la source du module sur une machine de production à 2h du matin est un hobby, pas une pratique SRE.

Étape 4 : Validez par « peut‑il se charger » et « est‑il dans l’initramfs »

La présence sur disque ne suffit pas. Il vous faut au minimum :

• Un test de chargement sur le noyau cible (difficile sans redémarrer).
• La validation de la signature (si Secure Boot est activé).
• La vérification de l’inclusion dans l’initramfs pour les modules critiques au démarrage.

Un compromis pratique : validez le chemin d’artefact DKMS, lancez des vérifications modinfo, contrôlez l’état de signature du module, et validez l’initramfs. Ensuite redémarrez dans une fenêtre de maintenance contrôlée avec un noyau de retour disponible.

Étape 5 : Ne cassez pas votre propre réseau en réparant un pilote

La plupart des récupérations DKMS sollicitent fortement CPU et disque mais ne perturbent pas le trafic. La zone dangereuse, c’est décharger/recharger des modules sur un système en production. Sauf si vous avez de la redondance (bonding, multipath, clustering), évitez de recharger des modules réseau/stockage sur un hôte critique en simple exemplaire pendant les heures d’activité.

Reconstruire et installer est sûr. Décharger/recharger est un changement.

Étape 6 : Créez une « porte de redémarrage »

En production, le contrôle le plus simple pour éviter l’interruption est une politique : n’autorisez pas le redémarrage si les modules DKMS ne sont pas installés pour le noyau le plus récemment installé. Vous pouvez faire cela avec un script local qui vérifie :

• dkms status pour le noyau cible affiche « installed » pour les modules critiques
• lsinitramfs contient les modules nécessaires au démarrage précoce
• mokutil --sb-state et l’état des signatures sont alignés

Puis intégrez‑le dans votre processus de changement. Ennuyeux. Efficace.

Secure Boot et signature des modules (MOK) : le casseur silencieux

Si vous exécutez Ubuntu 24.04 sur du matériel avec Secure Boot activé — et beaucoup d’organisations le font, pour des raisons de conformité — DKMS peut « réussir » et vous pouvez quand même perdre le fonctionnement. Voici pourquoi :

• DKMS compile un module.
• Le noyau refuse de le charger s’il n’est pas signé (ou signé par une clé non enregistrée).
• Vous ne le découvrez que lorsque le pilote est nécessaire pour la première fois, souvent après un redémarrage.

Comment reconnaître rapidement les échecs de signature Secure Boot

Signes typiques :

• modprobe: ERROR: could not insert '...': Required key not available
• dmesg affiche « module verification failed » ou des restrictions lockdown
• dkms status indique « installed » mais la fonctionnalité est absente

Que faire à ce sujet (options pragmatiques)

1. Signer les modules DKMS et enregistrer la clé (MOK). C’est l’option propre quand Secure Boot doit rester activé.
2. Désactiver Secure Boot dans le firmware. C’est opérationnellement le plus simple mais peut violer la politique.
3. Utiliser des pilotes intégrés signés quand c’est possible. Meilleur à long terme, pas toujours disponible.

Vérifier si DKMS signe les modules

cr0x@server:~$ sudo grep -R "sign-file" -n /etc/dkms /etc/modprobe.d 2>/dev/null | head

Ce que cela signifie : Il peut ne pas y avoir de configuration explicite. Sur Ubuntu, la signature des modules DKMS est souvent liée à l’outillage shim/MOK et aux scripts de packaging.

Décision : Si Secure Boot est activé et que vous voyez des échecs de signature, ne faites pas d’hypothèses. Vérifiez la signature du module avec modinfo.

Inspecter les métadonnées de signature d’un module

cr0x@server:~$ modinfo -F signer /lib/modules/6.8.0-52-generic/updates/dkms/zfs.ko
Canonical Ltd. Secure Boot Signing

Ce que cela signifie : Le module porte une chaîne signer. Si elle est vide, il peut être non signé (ou dépourvu de métadonnées).

Décision : Si le champ signer manque et que Secure Boot est activé, vous devez signer et enregistrer la clé, ou accepter que le module ne se chargera pas.

Vérifier les clés MOK enregistrées

cr0x@server:~$ sudo mokutil --list-enrolled | head
[key 1]
SHA1 Fingerprint: 12:34:56:78:90:...
Subject: CN=Canonical Ltd. Secure Boot Signing

Ce que cela signifie : Le système fait confiance à un ensemble de clés. Si votre signature DKMS utilise une clé différente, le noyau la rejettera.

Décision : Alignez votre clé de signature avec les clés enregistrées, ou enregistrez la bonne clé via MOK (ce qui requiert typiquement un redémarrage vers le gestionnaire MOK).

Blague 2 : Secure Boot est le videur du club du noyau : votre module peut être parfaitement habillé et ne pas être sur la liste.

initramfs, démarrage précoce, et pourquoi « ça a été construit » ne suffit pas

initramfs est l’image compressée d’espace utilisateur précoce que le noyau charge pour passer de « noyau démarré » à « système racine monté ». Si votre module critique n’est pas dans l’initramfs, la présence du module sur le disque est sans objet parce que le disque peut ne pas être encore accessible.

Cela importe pour :

• Systèmes root‑on‑ZFS
• Root chiffré nécessitant des modules spécifiques tôt
• Certaines configurations exotiques de stockage ou de boot réseau

Mode d’échec : modules DKMS installés, mais initramfs généré avant l’installation

Cela arrive lors de mises à jour interrompues, d’opérations de paquets parallèles, ou quand DKMS s’exécute tard et que l’initramfs a déjà été généré. Vous redémarrez et découvrez que l’espace utilisateur précoce ne trouve pas ZFS/SPL, ou que votre pilote de stockage est absent.

Correction : regénérez l’initramfs après l’installation DKMS pour le noyau cible, et vérifiez le contenu avec lsinitramfs.

Mode d’échec : plusieurs noyaux, initramfs obsolète

Vous pouvez avoir un initramfs correct pour le noyau en cours, mais pas pour le noyau le plus récemment installé. C’est ainsi que le piège de redémarrage se pose. Validez toujours l’initramfs correspondant au noyau dans lequel vous allez redémarrer.

Trois mini‑histoires d’entreprise (anonymisées, réalistes)

Mini‑histoire 1 : l’incident causé par une mauvaise hypothèse

Ils exploitaient un petit cluster GPU pour de l’inférence batch. Rien d’exotique : hôtes Ubuntu, pilote NVIDIA DKMS, ordonnanceur de jobs et une fenêtre de changements chaque mardi. Le rythme des mises à jour était « noyau automatiquement, pilotes quand quelqu’un se plaint ». Ça a bien marché… jusqu’à ce que non.

Une mise à jour du noyau est arrivée vendredi soir via unattended upgrades. Personne n’a remarqué parce que les nœuds tournaient encore sur l’ancien noyau et les GPU étaient toujours disponibles. Lundi matin, ils ont drainé un nœud pour maintenance non liée et l’ont redémarré. Il est revenu sans que les modules NVIDIA ne se chargent.

L’hypothèse erronée était subtile : « Si le pilote est installé, il est installé. » Ils n’avaient jamais vérifié si le pilote avait été construit pour le noyau nouvellement installé. Le nœud a redémarré sur le noyau le plus récent (comme prévu), et DKMS avait silencieusement échoué quelques jours plus tôt.

Ils ont essayé la correction classique : réinstaller le paquet pilote. Ça ne s’est toujours pas chargé. Finalement, quelqu’un a regardé dmesg et trouvé un message d’application de signature Secure Boot. Secure Boot avait été activé dans le firmware après un renouvellement de matériel récent, mais personne n’avait mis à jour le runbook.

La réparation a été simple — signer et enregistrer correctement la clé — mais cela a exigé des redémarrages vers le gestionnaire MOK. Ils ont perdu une journée à coordonner les redémarrages entre nœuds, alors que cela aurait pu être évité avec une porte de pré‑redémarrage et une vérification « DKMS installé pour le noyau le plus récent ».

Mini‑histoire 2 : l’optimisation qui s’est retournée contre eux

Une société financière en avait assez des déploiements de correctifs lents. Ils ont décidé d’« optimiser » en retirant les outils de build des serveurs de production : plus de gcc, plus de make, en‑têtes absents, paquets minimaux seulement. La sécurité appréciait. L’image était plus légère, les scans plus propres, et les serveurs avaient un air d’appliance.

Puis une mise à jour du noyau s’est déployée. DKMS a tenté de reconstruire un module NIC hors‑arbre dont ils dépendaient pour certaines fonctionnalités d’une carte particulière. Pas de compilateur, pas d’en‑têtes, pas de build. DKMS a échoué, mais le noyau courant a continué de tourner. L’échec est resté invisible.

La vague de redémarrages suivante a eu lieu pendant une maintenance électrique du datacenter. Les redémarrages étaient obligatoires. Plusieurs hôtes sont revenus sur le nouveau noyau sans le module NIC. Le pilote intégré suffisait à démarrer, mais il manquait les offloads qu’ils avaient réglés pour la latence. Le symptôme n’était pas « pas de réseau ». C’était pire : effondrement de performance intermittent et timeouts sous charge.

Ils sont revenus sur la décision de l’image minimale pour cette flotte et ont déplacé les builds DKMS dans une pipeline contrôlée : précompiler les modules pour le noyau cible dans un environnement de build, livrer les artefacts et vérifier avant le redémarrage. L’optimisation n’était pas mauvaise en soi. Elle l’était sans remplacer la construction implicite par DKMS par une chaîne d’approvisionnement explicite.

La leçon : si vous retirez les compilateurs des hôtes, vous prenez en charge le processus de build des modules de bout en bout. Sinon, vous ne faites que repousser l’échec au moment du redémarrage.

Mini‑histoire 3 : la pratique ennuyeuse mais correcte qui a sauvé la mise

Une société média exploitait beaucoup de serveurs orientés stockage, certains avec pools ZFS. Leur pratique était douloureusement ennuyeuse : après chaque mise à jour du noyau, un contrôle automatisé de « readiness reboot » était lancé. Il vérifiait l’état DKMS pour ZFS par rapport au noyau le plus récemment installé, confirmait que l’initramfs contenait ZFS, et s’assurait qu’un noyau connu bon restait installé comme rollback.

Un matin, le contrôle a signalé une erreur sur un sous‑ensemble d’hôtes. DKMS indiquait ZFS « built » mais pas « installed » pour le noyau le plus récent. Les hôtes tournaient encore normalement, donc ils n’ont pas paniqué. Ils ont bloqué les redémarrages via leur orchestrateur et ouvert un ticket.

La cause racine était une course entre paquets lors d’une précédente unattended upgrade : la génération d’initramfs est arrivée, puis l’installation DKMS a échoué et a été relancée, laissant un état incohérent. Le contrôle ennuyeux l’a détecté avant tout redémarrage. Ils ont exécuté dkms autoinstall -k, regénéré l’initramfs pour le noyau cible, et levé la porte.

Zéro interruption, pas de drame, pas de week‑end perdu. Voilà à quoi ressemble l’excellence opérationnelle quand on retire le PowerPoint.

Erreurs courantes : symptôme → cause → correctif

1) Symptom: dkms status shows “added” for the new kernel

Cause racine : Le module DKMS est enregistré mais pas construit pour ce noyau ; en‑têtes manquants ou build échoué précédemment.

Correctif : Installez les en‑têtes pour le noyau cible, puis lancez sudo dkms autoinstall -k <kernel>. Validez que les fichiers existent sous /lib/modules/<kernel>/updates/dkms.

2) Symptom: DKMS build fails with “Kernel headers not found”

Cause racine : Paquet linux-headers-<kernel> manquant, ou le lien symbolique /lib/modules/<kernel>/build cassé.

Correctif : Installez les en‑têtes correspondants ; vérifiez que ls -l /lib/modules/<kernel>/build pointe vers les en‑têtes.

3) Symptom: Module builds, but modprobe fails with “Required key not available”

Cause racine : Secure Boot activé ; module non signé ou signé avec une clé non enregistrée.

Correctif : Assurez‑vous que les modules DKMS sont signés avec une clé de confiance et enregistrez‑la via MOK, ou désactivez Secure Boot si la politique le permet.

4) Symptom: Boot into new kernel loses ZFS/root storage

Cause racine : initramfs du nouveau noyau manque les modules requis, souvent à cause d’un timing DKMS ou d’échecs de triggers postinst.

Correctif : Après l’installation DKMS, lancez update-initramfs -u -k <kernel>, puis confirmez avec lsinitramfs.

5) Symptom: DKMS compile errors about missing symbols / implicit declarations

Cause racine : Changement d’API du noyau ; la version du pilote n’est pas compatible avec le nouveau noyau.

Correctif : Mettez à jour le paquet pilote/source du module (par ex. version NVIDIA/ZFS plus récente), ou retenez le noyau et redémarrez sur l’ancien noyau jusqu’à disponibilité des paquets compatibles.

6) Symptom: Everything looks installed, but hardware still doesn’t work after reboot

Cause racine : Vous avez construit pour la mauvaise version de noyau (noyau en cours, pas celui installé le plus récent), ou vous avez démarré un noyau différent de celui attendu.

Correctif : Confirmez les noyaux installés, confirmez la sélection de boot par défaut, reconstruisez explicitement pour le noyau de démarrage avec dkms autoinstall -k.

7) Symptom: Package upgrades hang or leave “half-configured” state

Cause racine : Mise à jour interrompue, contention de verrou dpkg, système de fichiers plein, ou échecs de scripts postinst (souvent DKMS).

Correctif : Réparez l’état dpkg : apt-get -f install, vérifiez l’espace disque, et relancez les builds DKMS après que la couche de packaging soit saine.

Listes de vérification / plan étape par étape

Checklist A: No-downtime recovery on a host still running the old kernel

1. Identifier le noyau cible (le plus récemment installé) : utilisez dpkg -l pour les images installées.
2. Vérifier l’état DKMS pour les modules critiques par rapport à ce noyau : dkms status.
3. Installer les en‑têtes pour le noyau cible si elles manquent : apt-get install linux-headers-<kernel>.
4. Reconstruire les modules pour le noyau cible : dkms autoinstall -k <kernel>.
5. Valider la présence des artefacts dans /lib/modules/<kernel>/updates/dkms.
6. Vérification Secure Boot : mokutil --sb-state et confirmer le signer du module via modinfo.
7. Regénérer l’initramfs pour le noyau cible (hôtes stockage critique) : update-initramfs -u -k <kernel>.
8. Vérifier le contenu initramfs : lsinitramfs inclut les modules requis.
9. Conserver un rollback disponible : confirmer qu’un noyau plus ancien connu bon reste installé.
10. Planifier le redémarrage avec plan de retour arrière (accès console, sélection GRUB, intervention distante si nécessaire).

Checklist B: If you already rebooted into the broken kernel

1. Confirmer ce qui manque : lsmod, modprobe, et dmesg.
2. Vérifier Secure Boot immédiatement ; ne perdez pas de temps à reconstruire des modules non signés si Secure Boot va les bloquer.
3. Installer les prérequis de build (temporairement) : en‑têtes, toolchain compilateur si DKMS en a besoin.
4. Reconstruire DKMS pour le noyau en cours : dkms autoinstall -k $(uname -r).
5. Si le build échoue à cause d’un décalage d’API : arrêtez et choisissez une version de pilote compatible ou redémarrez sur le noyau précédent via GRUB.
6. Corriger l’initramfs si des modules critiques au démarrage sont impliqués, puis tester le redémarrage.

Checklist C: Prevent it next time (production hygiene)

1. Créer une « porte de redémarrage » qui vérifie que DKMS est installé pour le noyau le plus récent et valide l’initramfs si nécessaire.
2. Stager les mises à jour du noyau sur des hôtes canaris avec du matériel représentatif.
3. Traquer la politique Secure Boot comme une contrainte de première classe, pas une note de BIOS.
4. Garder au moins un noyau de rollback installé et bootable en permanence.
5. Contrôler les unattended upgrades pour que les noyaux ne changent pas sans validation.

FAQ

1) Pourquoi DKMS « s’est cassé » seulement après la mise à jour du noyau ?

Parce que les modules DKMS sont compilés contre les en‑têtes d’une version précise du noyau. Quand le noyau change, le module doit être reconstruit. Si cette reconstruction échoue, vous ne le remarquerez pas tant que vous ne redémarrerez pas sur le nouveau noyau ou que vous n’essayerez pas de charger le module pour celui‑ci.

2) Puis‑je réparer DKMS sans redémarrer ?

Vous pouvez reconstruire et installer des modules pour le noyau suivant sans redémarrer, oui. Vous ne pouvez généralement pas tester leur chargement dans ce noyau suivant sans réellement le démarrer. C’est pourquoi vous validez les artefacts, les signatures et le contenu de l’initramfs avant le redémarrage.

3) Que signifient « added » vs « built » vs « installed » dans dkms status ?

added : DKMS connaît la source du module mais ne l’a pas construite pour ce noyau. built : compilé mais pas nécessairement installé dans l’arbre de modules du noyau. installed : placé dans /lib/modules/<kernel> et depmod a été (ou devrait être) exécuté.

4) Ai‑je vraiment besoin des en‑têtes correspondants au noyau ?

Oui. DKMS construit contre les en‑têtes pour la version de noyau ciblée. Il n’existe pas de « assez proche » ; installez linux-headers-<version-exacte>.

5) Pourquoi Secure Boot rend‑il cela tellement pire ?

Parce qu’il transforme un problème de compilation en un problème d’application à l’exécution. Vous pouvez construire le module avec succès et quand même être incapable de le charger. Le noyau rejettera les modules non signés par une clé de confiance quand Secure Boot et les politiques lockdown l’exigent.

6) Si Secure Boot est activé, dois‑je le désactiver ?

Uniquement si votre politique le permet. Désactiver Secure Boot peut être la solution opérationnellement la plus simple, mais la bonne correction dans des environnements régulés est de signer les modules DKMS avec une clé que vous contrôlez et de l’enregistrer via MOK.

7) Pourquoi mon système a‑t‑il démarré mais le stockage ou le réseau était cassé ensuite ?

Souvent parce que le pilote est chargé plus tard que vous ne le pensez, ou qu’un pilote intégré de secours existe mais n’a pas les fonctionnalités. Une autre cause fréquente : l’initramfs manque un module nécessaire tôt, donc le démarrage réussit partiellement, puis les périphériques apparaissent tard ou incorrectement.

8) Quel est le rollback le plus sûr si je ne peux pas faire construire DKMS pour le nouveau noyau ?

Démarrez sur le noyau précédent connu bon et mettez temporairement en attente les méta‑paquets noyau. Ensuite mettez à jour le paquet pilote/module vers une version qui prend en charge le nouveau noyau avant de retenter le redémarrage.

9) Dois‑je garder les compilateurs hors des serveurs de production ?

Ça dépend. Si vous vous appuyez sur des builds DKMS sur la machine hôte, vous avez besoin de la toolchain de build et des en‑têtes. Si vous les retirez, vous devez remplacer la construction locale DKMS par une pipeline qui produit et distribue des modules compatibles pour chaque noyau déployé.

10) Comment éviter que des noyaux « piège de reboot » s’accumulent ?

Mettez en place une étape de validation après l’installation du noyau qui vérifie l’état DKMS pour les modules critiques sur le noyau le plus récent installé. Si elle échoue, bloquez l’automatisation des redémarrages et alertez. C’est moins coûteux que la réponse à incident.

Prochaines étapes à effectuer aujourd’hui

Si vous exécutez Ubuntu 24.04 avec des pilotes gérés par DKMS, cessez de traiter les mises à jour du noyau comme « juste des patches de sécurité ». Ce sont aussi des événements de reconstruction de pilotes. Le chemin pratique vers zéro interruption est court :

1. Choisissez vos modules DKMS critiques par rôle d’hôte (stockage, réseau, GPU).
2. Après chaque installation de noyau, reconstruisez les modules pour le noyau le plus récemment installé (dkms autoinstall -k).
3. Validez les signatures si Secure Boot est activé ; ne supposez pas qu’un build réussi équivaut à un chargement réussi.
4. Regénérez et vérifiez l’initramfs pour les modules nécessaires au démarrage précoce.
5. Only then reboot. Keep a rollback kernel installed and bootable.

Faites cela, et « DKMS cassé après mise à jour du noyau » cessera d’être un incident. Ce deviendra un élément de checklist terminé avant que quelqu’un ne le remarque.