Ubuntu 24.04 : Secure Boot bloque les pilotes — réparez sans tout casser la configuration

janvier 15, 2026 • février 3, 2026 • Lecture : 29 min • Views: 10

Cet article vous a aidé ?

Secure Boot est censé renforcer la sécurité de votre système. Puis vous installez une mise à jour de pilote, redémarrez, et soudain votre GPU disparaît, le Wi‑Fi s’évapore ou VirtualBox se comporte comme s’il n’avait jamais rencontré votre noyau. Les journaux indiquent « verification failed ». La machine dit « non ». Et votre calendrier dit que vous avez une réunion dans six minutes.

Ceci est la réalité d’Ubuntu 24.04 sur les systèmes UEFI modernes : Secure Boot + modules noyau hors-arbre (NVIDIA, VirtualBox, ZFS DKMS, pilotes Wi‑Fi fournis par le fabricant, agents EDR) est un contrat. Si vous ne signez pas, ça ne s’exécute pas. La solution n’est pas « réinstaller Ubuntu ». La solution consiste à diagnostiquer ce qui est bloqué et soit (a) inscrire une clé et signer les modules, soit (b) désactiver délibérément Secure Boot en connaissance de cause. Vous pouvez conserver votre configuration intacte.

Mode d’emploi pour un diagnostic rapide

Si vous avez besoin d’un système fonctionnel rapidement, ne commencez pas par réinstaller des pilotes. Ne commencez pas par reconstruire le noyau. Commencez par prouver sous quelle politique vous êtes et ce qui est exactement rejeté.

Première étape : confirmez l’état de Secure Boot et l’application des signatures des modules

Secure Boot est-il activé ? S’il est désactivé, cessez de l’accuser et cherchez ailleurs.
Le noyau applique-t-il l’obligation de signature des modules ? Ubuntu peut appliquer l’exigence de signature quand Secure Boot est actif. Cela transforme beaucoup de « ça marchait avant » en « c’est bloqué maintenant ».
Quel module échoue à se charger ? Vous voulez le nom du module et la chaîne d’erreur exacte.

Deuxième étape : identifiez la source et le cycle de vie du module

Est-ce un module DKMS ? DKMS signifie « reconstruit lors des mises à jour », ce qui veut dire « continuera de casser tant que la signature n’est pas automatisée ».
Provient-il des paquets Ubuntu ? Si oui, il existe des points d’intégration officiels (comme les invites MOK lors de l’installation) que vous pouvez exploiter.
Est-il fourni par le vendeur ? Dans ce cas, il peut être livré non signé ou avec son propre mécanisme de signature.

Troisième étape : choisissez entre deux stratégies raisonnables

Préférée pour les flottes gérées : gardez Secure Boot activé, inscrivez une Machine Owner Key (MOK) et signez vos modules hors-arbre (idéalement automatiquement).
Acceptable pour postes de travail mono-utilisateur avec tolérance au risque : désactivez Secure Boot dans le firmware et passez à autre chose — documentez la décision pour que le Vous du futur ne passe pas une nuit à traquer des fantômes.

Une vérité opérationnelle : le « correctif » le plus rapide est souvent de désactiver Secure Boot, et le meilleur correctif est rarement cela. La différence dépend si la machine doit être défendable en audit et si vous voulez que les mises à jour cessent d’être une aventure.

Ce que Secure Boot fait réellement sur Ubuntu 24.04

Secure Boot est une fonctionnalité UEFI qui vérifie les signatures des chargeurs de démarrage et (sur la plupart des distributions Linux modernes) peut étendre la chaîne de confiance jusqu’au chemin de chargement des modules du noyau. Sur Ubuntu, la chaîne est typiquement : le firmware vérifie shim, shim vérifie GRUB et le noyau, puis le noyau utilise des clés (intégrées et inscrites) pour décider quels modules noyau sont autorisés à se charger.

Voici le point clé : si Secure Boot est activé et que votre noyau applique l’obligation de signature, un module noyau sans signature de confiance se charge comme une fausse carte d’identité dans une boîte de nuit — peu importe à quel point il vous semble « légitime ».

Ubuntu essaie de rendre cela supportable avec le système de Machine Owner Key (MOK) : vous générez ou installez une clé de signature, vous inscrivez la partie publique via le gestionnaire MOK au démarrage, puis vous signez vos modules avec la clé privée. Une fois inscrite, le noyau fait confiance aux modules signés par cette clé.

Ce qui pique les gens, c’est le timing. Vous installez un pilote, DKMS construit un module, et tout semble correct — jusqu’au reboot où l’application de la politique Secure Boot fait que le noyau le rejette. Votre pilote « installé » et ne fonctionne toujours pas. Bienvenue dans l’informatique pilotée par la politique.

Une idée paraphrasée (non littérale) de James Hamilton (Amazon, fiabilité) : « On obtient de la fiabilité en concevant l’échec comme un état normal, pas comme un événement surprenant. » Le rejet de modules par Secure Boot est un échec par politique ; traitez-le comme une condition conçue, pas comme un bug bizarre.

Faits et contexte que vous auriez aimé connaître plus tôt

Secure Boot est apparu avec le matériel de l’ère Windows 8 (environ 2012) et est devenu courant parce que les fabricants l’activent par défaut.
Ubuntu utilise shim spécifiquement pour fonctionner avec l’écosystème Microsoft UEFI CA afin que les systèmes puissent démarrer Linux sans que chaque utilisateur gère ses propres clés de plateforme.
MOK existe parce que demander à chaque utilisateur de remplacer les clés du firmware est irréaliste et souvent impossible sur des laptops verrouillés.
L’application de la signature des modules n’est pas universelle entre distributions ; certaines la traitent comme optionnelle même avec Secure Boot activé, alors qu’Ubuntu tend à l’appliquer pour les modules hors-arbre non signés.
DKMS est une épée à double tranchant : il reconstruit automatiquement les modules pour les nouveaux noyaux, ce qui est génial — jusqu’à ce que vous réalisiez que les reconstructions non signées sont automatiquement cassées sous Secure Boot.
Les pilotes NVIDIA sont un point de douleur récurrent parce qu’ils vivent hors de l’arbre du noyau et de nombreuses configurations dépendent des reconstructions DKMS pour le noyau exact en cours d’exécution.
vboxdrv de VirtualBox est un exemple classique d’un module qui « marche jusqu’au reboot » quand Secure Boot applique la signature.
Le noyau dispose de plusieurs porte-clés impliqués (builtin, secondary, MOK/Platform) ; le débogage est plus simple une fois que vous acceptez que vous traitez des porte-clés, pas des impressions.
Certaines machines réinitialisent silencieusement les paramètres Secure Boot lors de mises à jour firmware, ce qui explique comment vous pouvez « soudainement » voir des rejets de modules sur une station auparavant stable.

Tâches de diagnostic essentielles (commandes, sorties, décisions)

Voici les tâches que j’exécute en production quand Secure Boot bloque des pilotes. Chacune inclut : commande, sortie réaliste, ce que cela signifie, et la décision à prendre.

Tâche 1 : Vérifier si Secure Boot est activé

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

Sens : Le firmware indique que Secure Boot est activé, et shim/mokutil le voit.

Décision : Procédez en supposant que les modules non signés seront probablement bloqués. S’il indique « disabled », votre problème n’est probablement pas Secure Boot — changez d’axe et regardez la compatibilité du pilote, un décalage ABI du noyau, ou des blobs firmware manquants.

Tâche 2 : Confirmer que vous avez démarré en mode UEFI (pas legacy/CSM)

cr0x@server:~$ [ -d /sys/firmware/efi ] && echo UEFI || echo BIOS
UEFI

Sens : Vous êtes bien dans le monde Secure Boot. Le démarrage legacy signifie que Secure Boot n’est pas en jeu.

Décision : Si vous voyez « BIOS », arrêtez — vos corrections liées à Secure Boot ne s’appliqueront pas. Trouvez pourquoi vous êtes en mode legacy (réglage firmware, ordre de démarrage, ancienne installation) et corrigez ceci si nécessaire.

Tâche 3 : Vérifier l’état de lockdown du noyau

cr0x@server:~$ cat /sys/kernel/security/lockdown
integrity

Sens : Le lockdown du noyau est actif en mode « integrity », généralement déclenché par Secure Boot. Cela s’accompagne souvent de l’application de la signature et restreint certaines opérations bas-niveau.

Décision : Attendez-vous à un comportement plus strict. Si vous essayez de charger des modules non signés ou d’utiliser des outils qui accèdent à la mémoire du noyau, vous allez buter. Prévoyez de signer plutôt que de « forcer ».

Tâche 4 : Identifier le symptôme du pilote manquant (module qui ne se charge pas)

cr0x@server:~$ sudo modprobe nvidia
modprobe: ERROR: could not insert 'nvidia': Key was rejected by service

Sens : Le module était présent mais a été rejeté pour cause d’échec de confiance de signature.

Décision : Ce n’est pas un problème d’« pilote non installé ». C’est un problème de confiance/signature. Allez vers l’inscription MOK et la signature.

Tâche 5 : Lire le journal du noyau pour la raison exacte du rejet

cr0x@server:~$ sudo dmesg -T | tail -n 12
[Sat Dec 28 10:11:41 2025] Lockdown: modprobe: unsigned module loading is restricted; see man kernel_lockdown.7
[Sat Dec 28 10:11:41 2025] nvidia: module verification failed: signature and/or required key missing - tainting kernel
[Sat Dec 28 10:11:41 2025] nvidia: loading out-of-tree module taints kernel.
[Sat Dec 28 10:11:41 2025] nvidia: module license 'NVIDIA' taints kernel.

Sens : Vous avez à la fois des erreurs de lockdown et de vérification. Notez la différence : « tainting kernel » est informatif ; « restricted » peut signifier qu’il ne se chargera pas du tout.

Décision : S’il est restreint/rejeté, vous devez signer/inscrire ou désactiver l’application en désactivant Secure Boot. S’il se charge mais « taints », le pilote fonctionne ; votre problème est ailleurs.

Tâche 6 : Vérifier que le module est présent et quel fichier est chargé

cr0x@server:~$ modinfo -n nvidia
/lib/modules/6.8.0-41-generic/updates/dkms/nvidia.ko

Sens : Le module provient de la sortie DKMS (updates/dkms). C’est une cible prioritaire pour la signature.

Décision : Traitez-le comme « sera reconstruit lors d’un upgrade du noyau », donc « doit être signé automatiquement après reconstruction ».

Tâche 7 : Vérifier le statut DKMS (ce qui est construit pour quel noyau)

cr0x@server:~$ dkms status
nvidia/550.90.07, 6.8.0-41-generic, x86_64: installed
vboxhost/7.0.20, 6.8.0-41-generic, x86_64: installed

Sens : DKMS a construit des modules pour votre noyau courant. « installed » ne signifie pas « chargeable sous Secure Boot ».

Décision : Si Secure Boot est activé, supposez que ces produits DKMS doivent être signés (sauf si le packaging s’en charge et que la clé est inscrite).

Tâche 8 : Vérifier si des clés MOK sont inscrites

cr0x@server:~$ sudo mokutil --list-enrolled | head
[key 1]
SHA1 Fingerprint: 7a:9d:2b:1c:2f:7c:de:aa:8b:10:1b:6c:4f:5b:89:9a:1d:00:aa:41
Subject: CN=Ubuntu Secure Boot Module Signature key
Issuer: CN=Ubuntu Secure Boot Module Signature key

Sens : Une MOK est inscrite. C’est une bonne nouvelle, mais ce n’est peut-être pas la clé que vous utilisez (ou le module peut ne pas être du tout signé).

Décision : S’il n’y a pas de clés inscrites, vous devez en inscrire une. Si des clés existent, vérifiez que votre module est signé par l’une d’elles.

Tâche 9 : Vérifier si un module est signé (et par qui)

cr0x@server:~$ modinfo nvidia | egrep -i 'signer|sig_key|sig_hash'
signer:         CN=My DKMS Signing Key
sig_key:        3A:7F:1C:2D:4F:AA:11:9B:5A:1C:0D:32:77:2B:10:8F:DE:55:21:90
sig_hashalgo:   sha256

Sens : Le module est signé. La question suivante est de savoir si le certificat du signataire est de confiance pour le noyau (c.-à-d. inscrit via MOK ou dans le porte-clés intégré).

Décision : S’il n’est pas signé (pas de champs signer), signez-le. S’il est signé mais toujours rejeté, vous avez probablement inscrit une clé différente de celle utilisée pour signer.

Tâche 10 : Confirmer quels porte-clés le noyau a disponibles (vérification opérationnelle)

cr0x@server:~$ sudo keyctl list %:.system_keyring
3 keys in keyring:
  260754792: --alswrv     0     0 asymmetric: Ubuntu Secure Boot Module Signature key: X509.rsa
  412884911: --alswrv     0     0 asymmetric: Microsoft Windows Production PCA 2011: X509.rsa
  101388220: --alswrv     0     0 asymmetric: Canonical Ltd. Secure Boot Signing: X509.rsa

Sens : Le porte-clés système inclut les clés Ubuntu/Canonical et souvent la chaîne Microsoft UEFI CA. Les clés MOK peuvent apparaître dans un porte-clés secondaire selon la configuration.

Décision : Si votre clé personnalisée n’apparaît dans aucun porte-clés pertinent, vous ne l’avez pas inscrite (ou vous avez inscrit mais n’avez pas complété l’étape du gestionnaire MOK au démarrage).

Tâche 11 : Vérifier si un module est bloqué par la politique Secure Boot vs. une dépendance manquante

cr0x@server:~$ sudo modprobe vboxdrv
modprobe: ERROR: could not insert 'vboxdrv': Key was rejected by service

Sens : Même schéma d’application de signature. VirtualBox est classique ici.

Décision : Ne réinstallez pas VirtualBox dix fois. Signez le module et inscrivez la clé. La réinstallation produit le même module non signé, juste avec une nouvelle déception.

Tâche 12 : Inspecter rapidement les variables Secure Boot (utile pour détecter les incidents de « reset firmware »)

cr0x@server:~$ sudo bootctl status | sed -n '1,18p'
System:
     Firmware: UEFI 2.70 (American Megatrends 5.17)
  Secure Boot: enabled
   Setup Mode: user
 TPM2 Support: yes
 Boot into FW: supported

Current Boot Loader:
      Product: systemd-boot 255.4-1ubuntu8
     Features: ✓ Boot counting
               ✓ Menu timeout control
               ✓ One-shot menu timeout control
               ✓ EFI variable boot loader control

Sens : Secure Boot est activé et le firmware est en mode user (pas setup). Le mode setup peut indiquer que les clés ont été effacées/réinitialisées.

Décision : Si vous voyez « Setup Mode: setup », considérez que les clés de plateforme ont peut‑être été effacées, ce qui peut casser les chaînes de démarrage précédemment approuvées et le comportement MOK. Montez en escalade vers des étapes de gestion des clés/firmware.

Tâche 13 : Confirmer le noyau en cours d’exécution et les noyaux installés (éviter de courir après le mauvais ABI)

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

cr0x@server:~$ dpkg -l 'linux-image-*' | awk '/^ii/{print $2,$3}' | tail -n 5
linux-image-6.8.0-40-generic 6.8.0-40.40
linux-image-6.8.0-41-generic 6.8.0-41.41
linux-image-generic 6.8.0.41.44

Sens : Si DKMS a construit pour un noyau mais que vous avez démarré un autre, les modules ne correspondront pas et peuvent échouer pour des raisons non liées aux signatures.

Décision : Assurez-vous que DKMS a construit pour le noyau en cours. Sinon, reconstruisez DKMS pour le noyau actif avant de signer.

Tâche 14 : Reconstruire DKMS pour le noyau courant (quand les sorties ne correspondent pas)

cr0x@server:~$ sudo dkms autoinstall -k 6.8.0-41-generic
Sign command: /lib/modules/6.8.0-41-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...
make -j16 KERNELRELEASE=6.8.0-41-generic...
Installing to /lib/modules/6.8.0-41-generic/updates/dkms/

Sens : Cette sortie montre un chemin sain : DKMS connaît une clé de signature et appelle sign-file.

Décision : Si votre sortie DKMS ne mentionne pas du tout la signature et que Secure Boot est activé, vous devez configurer l’intégration de la clé de signature (ou signer manuellement les modules après la construction).

Tâche 15 : Vérifier une signature de module au niveau fichier (quand `modinfo` est ambigu)

cr0x@server:~$ sudo tail -c 256 /lib/modules/6.8.0-41-generic/updates/dkms/vboxdrv.ko | strings | tail -n 5
~Module signature appended~
PKCS#7
X.509
sha256

Sens : Le module contient un blob de signature ajouté. C’est rustique mais efficace quand vous avez besoin d’une preuve rapide.

Décision : S’il n’y a pas de marqueur de signature, signez-le. S’il y en a un mais qu’il est rejeté, vous avez un décalage de confiance/inscription.

Tâche 16 : Assurez-vous d’avoir réellement complété l’inscription MOK au redémarrage

cr0x@server:~$ sudo mokutil --test-key /var/lib/shim-signed/mok/MOK.der
/var/lib/shim-signed/mok/MOK.der is already enrolled

Sens : La clé est inscrite. Si vous avez encore des rejets, vous signez probablement avec une clé différente, ou le module n’est pas signé.

Décision : Alignez « clé utilisée pour signer » avec « clé inscrite ». Une clé privée, un certificat public inscrit, pas d’improvisation.

Voies de correction : choisissez la moins pire

Il existe trois approches dans le monde réel. Deux sont défendables. Une est « je vais le regretter plus tard ».

Voie A (meilleure) : Garder Secure Boot activé, inscrire MOK, signer les modules

C’est ce que vous faites sur des flottes, des laptops d’entreprise et tout ce qui a besoin d’un récit de sécurité propre. C’est aussi ce que vous faites si vous ne voulez pas que chaque mise à jour du noyau casse vos pilotes à nouveau.

À haut niveau :

Générez une paire de clés de signature (la clé privée reste sur la machine, idéalement avec des permissions de système de fichiers appropriées).
Inscrivez le certificat public via MOK.
Signez les modules hors-arbre (NVIDIA, VirtualBox, ZFS DKMS, modules fournisseur).
Assurez-vous que DKMS signe automatiquement lors de la reconstruction, ou ajoutez un hook post-build.

Voie B (parfois acceptable) : Désactiver Secure Boot dans le firmware

C’est une décision légitime quand vous assumez le risque et que vous avez besoin que la machine fonctionne maintenant. C’est courant sur des postes de laboratoire à usage unique, des machines isolées ou des machines de loisir. C’est aussi courant pour certains agents de sécurité fournisseurs qui ne supportent pas bien le kernel lockdown.

Mais si vous faites cela sur des endpoints gérés sans le documenter, vous laissez un piège pour le prochain ingénieur de garde (qui pourrait être vous, à 2h du matin).

Voie C (à éviter) : « Forcer » le chargement de modules non signés

Les gens cherchent des paramètres de démarrage et des sysctls pour contourner l’application. Cette voie est incohérente selon les noyaux, souvent bloquée par lockdown, et a tendance à s’effondrer au prochain update. De plus, vous obtiendrez un état système non auditable.

Blague courte #1 : Secure Boot n’est pas « difficile ». Il fait juste le boulot qu’on lui a demandé, contrairement à la moitié des logiciels qu’on livre.

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

Cette section est le plan « faites-le, ne débattez pas ». Choisissez le scénario qui correspond à votre système.

Scénario 1 : Le pilote NVIDIA est installé, mais bloqué après reboot

Confirmez que le blocage est lié à la signature (Tâches 4 et 5). Si vous voyez « Key was rejected by service », vous êtes au bon endroit.
Identifiez le chemin du module (Tâche 6). S’il se trouve sous updates/dkms, vous signerez le module construit par DKMS.
Vérifiez les clés inscrites (Tâche 8) et si le module est signé (Tâche 9).
Si la clé manque : inscrivez une MOK :
```
cr0x@server:~$ sudo update-secureboot-policy --new-key
Creating new MOK key pair...
Key created in /var/lib/shim-signed/mok/
Importing new key into MOK...
input password:
```
Sens : Ubuntu a généré une paire de clés et a mis en file d’attente le certificat public pour inscription. Il demande un mot de passe unique utilisé par le gestionnaire MOK au démarrage.

Décision : Redémarrez maintenant, complétez l’inscription dans l’écran bleu du gestionnaire MOK. Si vous l’ignorez, rien ne changera et vous perdrez une heure à accuser la couche erronée.
Après le redémarrage, confirmez l’inscription (Tâche 16).

Reconstruisez + signez via DKMS (Tâche 14). Ensuite chargez le module :

cr0x@server:~$ sudo modprobe nvidia

Sens : Aucune sortie est synonyme de succès. Linux est poli comme ça.

Décision : S’il se charge, vérifiez avec :

cr0x@server:~$ nvidia-smi
Sat Dec 28 10:26:12 2025
+---------------------------------------------------------------------------------------+
| NVIDIA-SMI 550.90.07              Driver Version: 550.90.07      CUDA Version: 12.4   |
+---------------------------------------------------------------------------------------+

Sens : Le pilote est actif.

Décision : Terminé. Ne touchez pas aux réglages du firmware.

Scénario 2 : Le pilote noyau VirtualBox échoue (« vboxdrv not loaded »)

Prouvez que c’est un rejet de signature (Tâche 11).
Vérifiez le statut DKMS (Tâche 7).
Si DKMS n’est pas installé, installez le bon paquet :
```
cr0x@server:~$ sudo apt-get install virtualbox-dkms
Reading package lists... Done
Building dependency tree... Done
The following NEW packages will be installed:
  virtualbox-dkms
```
Sens : DKMS construira des modules pour votre noyau courant.

Décision : Avec Secure Boot activé, vous devez toujours vous assurer que la signature est en place (inscription MOK).
Inscrivez/confirmes la clé MOK (Scénario 1, étapes 4/5).

Reconstruisez DKMS et confirmez la signature (Tâche 14). Ensuite :

cr0x@server:~$ sudo modprobe vboxdrv

Sens : Succès silencieux.

Décision : Confirmez que VirtualBox voit le pilote :

cr0x@server:~$ VBoxManage list hostinfo | sed -n '1,12p'
Host Information:
Host name:            server
Operating system:     Linux
Operating system version: Ubuntu 24.04.1 LTS
Processor online count: 16
VirtualBox kernel modules: loaded

Scénario 3 : ZFS DKMS ou autres modules liés au stockage ne se chargent pas

Si vous utilisez ZFS-on-Linux via DKMS, Secure Boot peut vous mordre le plus fort au pire moment : quand vous redémarrez après une mise à jour du noyau et que vos pools ne s’importent plus parce que le module ne se charge pas. Les incidents de stockage ont toujours le meilleur timing.

Vérifiez l’échec de chargement du module :
```
cr0x@server:~$ sudo modprobe zfs
modprobe: ERROR: could not insert 'zfs': Key was rejected by service
```
Décision : C’est de la signature/inscription, pas « ZFS cassé ».

Confirmez le chemin du module :

cr0x@server:~$ modinfo -n zfs
/lib/modules/6.8.0-41-generic/updates/dkms/zfs.ko

Confirmez que vous avez une clé inscrite et que DKMS signe (Tâches 8, 14, 16).

Après la correction, importez les pools :

cr0x@server:~$ sudo zpool import
   pool: tank
     id: 1034459023344556677
  state: ONLINE
 action: The pool can be imported using its name or numeric identifier.
 config:

        tank        ONLINE
          mirror-0  ONLINE
            sda     ONLINE
            sdb     ONLINE

Sens : Le module noyau est chargé et ZFS voit les disques.

Décision : Procédez à l’import. Si les pools n’apparaissent pas, vous avez un problème de détection stockage (HBA, multipath, chiffrement), pas Secure Boot.

Scénario 4 : Écran noir au démarrage de l’interface graphique après activation de Secure Boot

Parfois le symptôme « pilote bloqué » se manifeste par un écran noir ou un framebuffer de secours. C’est courant quand les modules NVIDIA sont bloqués et que le système tente (et échoue) de se replier proprement.

Démarrez en mode récupération ou depuis une console texte (essayez de changer de TTY).
Confirmez les erreurs de signature via dmesg (Tâche 5).
Si vous avez besoin d’un retour rapide à l’interface graphique : utilisez temporairement les pilotes libres ou supprimez les paquets en conflit. Ensuite faites le flux de travail Correctif Secure Boot proprement.

cr0x@server:~$ sudo apt-get purge 'nvidia*'
Reading package lists... Done
The following packages will be REMOVED:
  nvidia-dkms-550 nvidia-driver-550 ...

Sens : Vous supprimez l’ensemble de modules bloqués pour que le système puisse utiliser des chemins non-NVIDIA.

Décision : Utilisez ceci seulement pour récupérer l’accès. Ensuite réinstallez NVIDIA avec un plan de signature, pas avec de l’espoir aveugle.

Trois mini-récits en entreprise

Mini-récit 1 : L’incident causé par une mauvaise hypothèse

L’entreprise avait une norme de poste propre : Ubuntu LTS, Secure Boot activé, chiffrement disque sur les laptops. Raisonnable. Puis une équipe a déployé un paquet pilote Wi‑Fi fournisseur pour une série de nouveaux laptops parce que le pilote intégré au noyau sous-performait dans un bureau avec beaucoup de bruit RF.

L’hypothèse était casuale et mortelle : « Si le paquet s’installe proprement, le pilote se chargera. » C’était vrai sur leur machine de test parce que Secure Boot avait été désactivé des mois plus tôt lors d’un échange matériel et personne ne l’a noté.

En production, le nouveau pilote s’est installé, DKMS a construit, et tout semblait vert dans les logs de déploiement. Après la fenêtre de reboot planifiée, les laptops sont revenus sans Wi‑Fi. Pas du Wi‑Fi capricieux. Aucun. Les gens ont utilisé le tethering pour assister aux réunions, ce qui est l’indicateur d’un vrai incident.

La cause racine était visible en cinq secondes de dmesg : « Key was rejected by service. » La correction n’était pas compliquée — inscrire une MOK et signer le module DKMS — mais la récupération fut lente parce que les machines étaient à distance et l’inscription MOK requiert une étape interactive au redémarrage. Ils ont fini par déployer temporairement un rollback vers le pilote intégré pour retrouver la connectivité, puis faire le travail de signature dans un second changement contrôlé.

Conclusion : si votre déploiement dépend de DKMS et que Secure Boot est activé, vous n’avez pas un processus d’« installation de pilote ». Vous avez un processus de « gestion de clés » qui aboutit à un pilote.

Mini-récit 2 : L’optimisation qui s’est retournée contre eux

Une équipe plateforme voulait adopter plus vite les patches noyau. Ils ont accéléré leur cadence de mises à jour pour que les postes reçoivent rapidement de nouveaux noyaux, et ils ont purgé les anciens noyaux pour garder les disques propres et les menus de démarrage succincts. Propre. Efficace. Tout le monde aime l’efficacité jusqu’à ce qu’elle morde.

Ils dépendaient aussi d’un module de sécurité endpoint hors-arbre distribué comme paquet DKMS. Il avait été correctement signé une fois, tout fonctionnait pendant des mois. Puis l’« optimisation » : après les mises à jour du noyau, ils ont poussé des reboots immédiats pour réduire la fenêtre d’exposition. La fenêtre entre « DKMS a construit un module » et « la machine a redémarré dans le nouveau noyau » est devenue très courte.

Un sous-ensemble de machines a redémarré dans le nouveau noyau avant que l’étape post-install DKMS n’ait fini de signer — ou avant que la clé de signature ne soit disponible à cause d’une dérive de configuration. Le résultat fut une panne éparse : l’agent de sécurité ne se chargeait pas et le scanner de conformité marquait les endpoints comme « non protégés ».

Ils avaient créé un bug de fiabilité en compressant le temps. La correction n’était pas de ralentir toutes les mises à jour ; c’était de rendre la signature déterministe et observable. Ils ont ajouté une porte : si le module signé attendu n’est pas présent pour le noyau cible, le reboot est différé. Ennuyeux, oui. Efficace, absolument.

Conclusion : la vitesse n’est pas la même chose que le contrôle. Si un processus inclut de la crypto et de la politique noyau, supprimez les conditions de course ou elles vous supprimeront.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une équipe stockage utilisait ZFS sur une flotte de serveurs Ubuntu pour des artefacts de build. Pas tendance, mais ça fonctionnait. Ils avaient aussi une règle stricte : chaque serveur disposait d’un playbook « break glass » imprimé dans leur runbook, incluant des vérifications d’état Secure Boot, procédures d’inscription MOK, et un petit stock de noyaux connus bons retenus de l’autopurge.

Un jour, une mise à jour firmware a été déployée par le fournisseur hardware. Après cette mise à jour, quelques serveurs sont revenus avec Secure Boot activé alors qu’il avait été désactivé auparavant (ou l’inverse, selon le modèle). Le symptôme immédiat était simple : après redémarrage, ZFS ne se chargeait pas sur deux nœuds. Les pools étaient ok. Les disques aussi. Le noyau appliquait la signature et le module ZFS construit par DKMS n’était pas approuvé.

Parce qu’ils avaient un processus ennuyeux, la réponse fut ennuyeuse aussi : vérifier l’état Secure Boot, confirmer le rejet de signature, inscrire la MOK correcte, reconstruire DKMS, signer, vérifier le chargement, importer les pools. Pas de « fsck » paniqué, pas d’expériences aléatoires sur le chemin de données, pas de downgrades sauvages en production.

Ça a quand même demandé du travail, parce que l’inscription de clé est interactive, mais ils ont évité le grand mode défaillance : faire des changements désespérés sur la pile stockage alors que le système était déjà dégradé. Ils ont récupéré le service sans dommages collatéraux, ce qui est le seul type de récupération qui mérite d’être célébré.

Conclusion : le meilleur outil d’intervention est le runbook que vous avez écrit quand vous vous ennuyiez.

Erreurs courantes (symptôme → cause → correction)

1) « Pilote installé, mais périphérique manquant après reboot »

Symptôme : GPU/Wi‑Fi/VirtualBox semble correct jusqu’au reboot ; ensuite le module ne se charge plus.

Cause racine : Secure Boot activé + module non signé/non approuvé, donc rejeté au chargement.

Correction : Utilisez mokutil --sb-state, lisez dmesg pour « Key was rejected by service », inscrivez la MOK, signez le module (ou désactivez Secure Boot en connaissance de cause).

2) « J’ai inscrit une MOK mais ça échoue toujours »

Symptôme : Vous avez fait une étape d’inscription MOK, mais les modules sont toujours rejetés.

Cause racine : Vous avez inscrit un certificat public différent de la clé privée utilisée pour signer, ou vous n’avez jamais complété l’UI MOK Manager au redémarrage.

Correction : Exécutez mokutil --test-key sur le cert que vous pensez inscrit. Confirmez que modinfo montre le bon signer. Si différence, re-signez avec la clé inscrite ou ré-inscrivez le certificat correct.

3) « DKMS dit installed, donc ça doit marcher »

Symptôme : dkms status indique « installed », mais le module échoue à se charger.

Cause racine : « installed » signifie seulement « construit et copié », pas « approuvé sous Secure Boot ».

Correction : Confirmez la signature avec modinfo. Configurez la signature DKMS (outillage Ubuntu via update-secureboot-policy, ou vos propres hooks de signature).

4) « Écran noir après activation de Secure Boot »

Symptôme : Le système démarre sur un écran noir ; le TTY peut fonctionner.

Cause racine : Module GPU bloqué ; le gestionnaire d’affichage démarre sans accélération matérielle ou échoue.

Correction : Démarrez en récupération/TTY, inspectez dmesg, soit retirez temporairement le pilote problématique soit signez-le correctement et assurez l’inscription de la clé.

5) « Après mise à jour firmware, tout a planté »

Symptôme : Des modules DKMS auparavant stables sont maintenant rejetés, l’état Secure Boot semble avoir changé.

Cause racine : Le firmware a réinitialisé ou modifié l’état Secure Boot ; l’inscription MOK peut être de nouveau nécessaire ou le flux de boot a changé.

Correction : Confirmez avec mokutil --sb-state et bootctl status. Ré-inscrivez la MOK si besoin ; vérifiez les porte-clés ; re-signez les modules.

6) « J’ai désactivé Secure Boot, mais ça dit encore ‘rejected’ »

Symptôme : Vous affirmez que Secure Boot est désactivé, mais les modules échouent toujours.

Cause racine : Vous avez togglé la mauvaise entrée du firmware (certains UEFI ont des réglages séparés), ou vous démarrez sur une entrée de boot différente, ou vous confondez Secure Boot avec un kernel lockdown causé par d’autres paramètres.

Correction : Vérifiez l’état depuis l’OS (mokutil --sb-state) et contrôlez le mode UEFI. Ne vous fiez pas uniquement à l’UI du firmware.

7) « J’ai signé le module mais les mises à jour le cassent à nouveau »

Symptôme : Ça marche jusqu’à la prochaine mise à jour du noyau ; ensuite ça casse.

Cause racine : La reconstruction DKMS crée un nouveau module non signé à chaque installation de noyau ; votre signature était manuelle et non automatisée.

Correction : Intégrez la signature avec DKMS (assurez-vous que la clé de signature existe là où DKMS l’attend ; vérifiez que la sortie DKMS inclut la signature). Ajoutez des contrôles opérationnels avant de redémarrer sur un nouveau noyau.

Blague courte #2 : La façon la plus rapide d’apprendre Secure Boot est de l’ignorer une fois, puis de programmer votre séance d’apprentissage pour le reboot suivant.

FAQ

1) Dois‑je simplement désactiver Secure Boot ?

Si c’est une machine personnelle et que vous acceptez le compromis, oui — c’est un choix valide. Sur des systèmes gérés, préférez garder Secure Boot activé et signer les modules. Désactiver Secure Boot est facile ; le défendre ensuite ne l’est pas.

2) Qu’est‑ce que MOK, en termes simples ?

MOK (Machine Owner Key) est un moyen d’ajouter votre propre certificat de signature de confiance dans la chaîne de démarrage sans réécrire les clés de plateforme du firmware. Vous inscrivez un certificat public ; ensuite le noyau fait confiance au code signé par la clé privée correspondante.

3) Pourquoi Ubuntu bloque‑t‑il des modules qui sont « installés correctement » ?

Parce que « installé » signifie que les fichiers sont présents sur le disque. L’application Secure Boot porte sur la confiance de ces fichiers au moment du chargement. Le noyau applique la politique ; les gestionnaires de paquets ne la remplacent pas.

4) Comment savoir si c’est Secure Boot et non un pilote cassé ?

Cherchez « Key was rejected by service » ou « module verification failed: signature and/or required key missing » dans dmesg. Vérifiez aussi mokutil --sb-state. Si Secure Boot est désactivé, votre échec vient probablement d’ailleurs.

5) Signer des modules « réduit la sécurité » ?

Ça modifie la frontière de confiance. Vous dites au noyau de faire confiance au code signé par votre clé. C’est acceptable si vous protégez la clé privée et contrôlez ce qui est signé. C’est mieux que de désactiver Secure Boot entièrement.

6) Pourquoi NVIDIA est‑il spécifiquement souvent impliqué ?

Parce que le pilote est hors arbre et souvent reconstruit via DKMS. Cette combinaison fait que les nouveaux noyaux déclenchent des reconstructions, les reconstructions exigent une signature, et la signature exige une clé inscrite. Sauter une étape casse tout au reboot.

7) Puis‑je signer des modules sur une machine et les déployer ailleurs ?

Vous pouvez, mais prudence : les machines cibles doivent faire confiance au certificat de signature (MOK inscrit partout), et vous avez besoin d’un processus sécurisé pour protéger la clé de signature. Sur des flottes, cela devient du PKI et du provisioning — faites‑le délibérément ou ne le faites pas du tout.

8) Que faire si j’ai perdu la clé privée utilisée pour signer des modules ?

Générez une nouvelle paire de clés, inscrivez le nouveau certificat public (MOK), puis re-signez les modules avec la nouvelle clé privée. Supprimez les anciennes clés si vous souhaitez garder un périmètre de confiance serré.

9) Pourquoi l’inscription MOK nécessite‑t‑elle un redémarrage interactif ?

Parce que l’inscription fait partie du processus de confiance au démarrage. L’environnement firmware/shim présente l’interface MOK Manager pour confirmer que vous aviez l’intention d’ajouter la clé. C’est un choix de conception anti‑malware, pas une fonctionnalité d’ergonomie.

10) Comment éviter que cela ne se reproduise lors des mises à jour du noyau ?

Assurez‑vous que la signature DKMS est automatique et vérifiable. Votre processus doit inclure : après l’installation du noyau, vérifier que DKMS a construit les modules pour ce noyau et qu’ils sont signés, puis redémarrer. Si vous ne pouvez pas vérifier la signature, ne redémarrez pas encore.

Conclusion : prochaines étapes pratiques

Ubuntu 24.04 avec Secure Boot n’est pas fragile — il est strict. Vos pilotes ne « tombent pas en panne au hasard ». Ils sont rejetés parce qu’ils ne sont pas approuvés selon la politique de démarrage en vigueur.

Faites ceci ensuite, dans l’ordre :

Exécutez mokutil --sb-state et confirmez que vous êtes en mode UEFI.
Tentez de charger le module en échec et capturez l’erreur exacte.
Lisez dmesg pour confirmer le rejet par signature.
Choisissez une stratégie : inscrire MOK + signer (préféré), ou désactiver Secure Boot (risque accepté explicitement).
Si vous signez : confirmez l’inscription, confirmez le signataire du module, et rendez la signature DKMS automatique avant de laisser les mises à jour noyau redémarrer votre système.

Si vous gérez Secure Boot comme une politique que vous administrez — pas comme une case à cocher qui fait peur — vous obtiendrez le meilleur résultat : une chaîne de démarrage sécurisée, des pilotes fonctionnels et des mises à jour qui ne se transforment pas en pannes surprises.