Si votre écran reste noir après une mise à jour Linux, ce n’est pas la carte graphique : c’est la clé qui n’a jamais été réenrôlée

Un écran qui reste désespérément noir après une mise à jour, avec juste un curseur clignotant en haut à gauche, et le réflexe classique : accuser la carte graphique, réinstaller les pilotes NVIDIA, parfois même changer de matériel. Mais dans une bonne partie des cas sous Linux, le vrai coupable n’a rien à voir avec le GPU : c’est une clé MOK (Machine Owner Key) qui n’a jamais été réenrôlée dans le firmware après la mise à jour du noyau.

Le mécanisme est bien documenté, et pourtant il continue de piéger des utilisateurs à chaque cycle de mise à jour majeure. Quand le Secure Boot est activé, chaque module noyau chargé au démarrage doit être signé par une clé reconnue par l’UEFI. Les modules DKMS (ceux qui se recompilent automatiquement à chaque changement de noyau, typiquement les pilotes NVIDIA propriétaires, VirtualBox ou VMware) sont signés avec une clé locale, générée sur votre machine. Cette clé doit être « enrôlée » une fois dans le firmware pour que le système accepte de charger les modules signés avec elle. Le problème, c’est que cette étape d’enrôlement ne se déclenche pas automatiquement à chaque mise à jour : elle dépend d’un écran bleu façon MOK Manager qui apparaît (ou pas) au reboot suivant l’installation.

Pourquoi la mise à jour casse tout sans prévenir

Le cas le plus parlant a été signalé sur le dépôt GitHub de Linux Mint concernant la migration LMDE 6 vers LMDE 7. Lors de la mise à jour de LMDE 6 vers LMDE 7 sur des systèmes avec Secure Boot activé et des paquets basés sur DKMS (comme les pilotes NVIDIA, VirtualBox, VMware), la mise à niveau se termine avec succès, mais après le redémarrage, les nouveaux modules DKMS ne se chargent pas jusqu’à ce que la clé MOK DKMS soit enrôlée. L’outil de mise à niveau ne prévenait même pas l’utilisateur que cette étape manuelle était nécessaire, alors que tous les indicateurs étaient disponibles côté système.

Concrètement, ça donne quoi dans les logs ? Cela évite la confusion où les utilisateurs voient « missing key – tainting kernel » ou démarrent en mode texte après des mises à jour de pilotes, alors même que l’installation a techniquement réussi. Le noyau démarre bien, la session graphique s’effondre, et rien dans l’interface ne dit clairement « il te manque une signature ». Un utilisateur du forum Linux Mint a documenté exactement ce scénario après une mise à jour de BIOS suivie d’un changement de noyau : chaque fois qu’il montait de version de kernel, les pilotes NVIDIA cessaient de charger et il devait réenrôler la clé MOK à la main pour que tout reparte.

Ce qui rend le diagnostic piégeux, c’est que le message d’erreur attendu (« not keyed », lié au MOK) n’apparaît pas systématiquement dans journalctl. Sur un cas remonté dans les forums Mint, les modules noyau NVIDIA étaient bien présents, mais pas chargés. Ils n’étaient pas non plus blacklistés. Dans cette situation, il y a souvent un message dans journalctl disant qu’ils ne sont pas signés (MOK avec secure boot). Pourtant, ce message n’apparaissait pas. Même les indices censés vous orienter peuvent manquer à l’appel, ce qui pousse naturellement vers la fausse piste matérielle.

Le vrai diagnostic, en trois commandes

Avant de désinstaller quoi que ce soit, la vérification tient en deux lignes de terminal. On commence par checker l’état du Secure Boot, puis on regarde si le module est signé :

• mokutil --sb-state pour confirmer que le Secure Boot est actif
• modinfo nvidia | grep sig pour voir si le module porte une signature valide
• ls -lt /var/lib/dkms/ ou les logs DKMS pour repérer un build récent sans enrôlement associé

Si le module est marqué comme non signé alors que le Secure Boot tourne, la solution ne consiste pas à couper le Secure Boot (ce que beaucoup de tutoriels suggèrent en premier réflexe, un peu par facilité). Sur Ubuntu et dérivés, la commande sudo update-secureboot-policy --enroll-key relance le processus d’enrôlement : si aucune clé MOK n’existe, le script se termine avec un message à cet effet. Si la clé est déjà enrôlée, le script se termine sans rien faire. Sur les systèmes où DKMS génère sa propre paire de clés (souvent dans /var/lib/dkms/mok.pub et mok.key), il faut repasser par mokutil --import puis valider l’enrôlement au reboot suivant via l’écran bleu MOK Manager, en tapant le mot de passe défini au moment de l’import.

Un utilisateur ayant creusé le sujet après une mise à jour Ubuntu 24 LTS a résumé la manip qui a fonctionné pour lui : réinstaller le module DKMS, régénérer l’initramfs, puis ajouter la clé MOK du pilote à la liste. En regardant attentivement les logs de la réinstallation DKMS, on trouve l’emplacement de la clé à utiliser. Définir le mot de passe, suivre le reste des étapes, redémarrer. Enrôler les clés avec le mot de passe défini et redémarrer. Ce n’est pas franchement intuitif pour un débutant, mais ça évite de désactiver une protection qu’on a justement activée pour une bonne raison.

Ce qu’il faut retenir avant le prochain reboot

Le piège se reproduit à chaque montée de version majeure de noyau tant que le module DKMS n’est pas re-signé et re-enrôlé, et ça vaut aussi bien pour NVIDIA que pour VirtualBox ou VMware, tous trois cités dans le rapport de bug Mint comme candidats typiques. La bonne pratique, avant toute mise à jour de noyau sur une machine avec Secure Boot et pilotes propriétaires, c’est de garder un œil sur l’écran MOK Manager au premier reboot suivant l’update : s’il apparaît, il ne faut jamais l’ignorer ni redémarrer dans la panique comme l’a fait un utilisateur du forum Mint qui, ne sachant pas quoi faire face à l’écran de gestion MOK, a simplement éteint et rallumé sa machine plusieurs fois avant de comprendre qu’il fallait valider l’enrôlement avec le mot de passe créé juste avant. Ce réflexe de couper l’alimentation au mauvais moment est justement ce qui transforme un simple oubli de signature en vraie galère de dépannage.

Sources : forums.linuxmint.com | forum-debian.fr