CyberSDF

Reprenez la main sur votre numérique

Écran noir après un pilote NVIDIA : reprendre la main en console texte

un poste de travail sobre vu de trois quarts, ecran eteint, clavier mecanique, carnet ouvert

Un redémarrage après l’installation du paquet nvidia-driver laisse parfois un écran noir, sans écran de connexion ni souris. Le module noyau nvidia ne s’est pas chargé, le serveur graphique n’a plus de pilote à utiliser, et la machine continue pourtant de tourner. Ce détail change tout : la panne se répare depuis la console texte, sans réinstaller la distribution.

Sommaire
  1. La réparation tient en cinq étapes, de Ctrl+Alt+F3 à nvidia-smi
  2. Trois messages de journal désignent trois causes distinctes
  3. Le paquet réinstallé dépend de la distribution et de la carte
  4. Secure Boot refuse un module compilé sur la machine
  5. La série 550 bloque certains portables au redémarrage
  6. La réinstallation ne tranche pas ces cinq questions
  7. Sources

La console texte répond encore par Ctrl+Alt+F3, parce qu’elle dépend du noyau et pas du pilote défectueux. Cinq étapes suffisent dans la majorité des cas : lire le journal, vérifier le module, purger, réinstaller, confirmer. Elles valent pour Debian 13 comme pour Ubuntu 24.04, et les autres pannes de démarrage de ces deux distributions sont regroupées dans la rubrique Linux.

La réparation tient en cinq étapes, de Ctrl+Alt+F3 à nvidia-smi

La console texte reste disponible pendant un écran noir, parce qu’elle est tenue par le noyau et non par le serveur graphique. Presser Ctrl+Alt+F3 fait apparaître une invite login: sur la troisième console virtuelle, où le compte habituel ouvre une session même si GDM ne démarre plus. Aucune réinstallation du système n’est nécessaire à ce stade, et la session graphique en panne n’est pas perdue : le noyau a gardé la machine en vie.

Cinq manipulations suffisent ensuite, dans cet ordre : basculer en console, lire les messages du noyau, vérifier que le module nvidia est chargé, purger puis réinstaller le pilote, confirmer avec nvidia-smi. Chaque étape se termine par ce qui doit apparaître à l’écran, car une commande muette est déjà une information. La dernière ligne attendue nomme la version du pilote actif et la carte détectée.

  1. Basculer sur la console texte avec Ctrl+Alt+F3, puis ouvrir une session avec l’identifiant et le mot de passe habituels.

    who

    Ce que vous devez voir : une ligne portant tty3 suivie de l’invite login:, puis une invite de commande et la ligne who.

  2. Lire les messages du noyau pour le démarrage en cours, puis pour le précédent si la machine a déjà redémarré.

    journalctl -k -b | grep -i -E 'nvrm|nvidia'
    journalctl -k -b -1 | grep -i -E 'nvrm|nvidia'

    Ce que vous devez voir : des lignes préfixées par NVRM: quand le module s’est chargé, et aucune ligne nvidia quand il ne l’a jamais été. Les erreurs du serveur X sont dans /var/log/Xorg.0.log, avec le même tri que les services et journaux systemd.

  3. Vérifier que les modules nvidia sont chargés et que DKMS a construit celui du noyau en cours.

    lsmod | grep -E 'nvidia|nouveau'
    dkms status

    Ce que vous devez voir : les lignes nvidia, nvidia_modeset, nvidia_drm et nvidia_uvm dans lsmod, et une ligne installed par noyau dans dkms status. La présence seule de nouveau confirme que le pilote propriétaire n’a pas pris la carte.

  4. Purger les paquets nvidia, puis réinstaller le pilote et les en-têtes du noyau en cours.

    sudo apt purge '^nvidia'
    sudo apt autoremove
    sudo apt update
    sudo apt install nvidia-driver linux-headers-$(uname -r)
    sudo update-initramfs -u

    Ce que vous devez voir : apt annonce le retrait des paquets nvidia-*, puis la compilation du module par DKMS pour le noyau en cours, sans erreur.

  5. Redémarrer la machine, puis confirmer le chargement du pilote après la réouverture de session.

    sudo systemctl reboot
    nvidia-smi

    Ce que vous devez voir : le tableau de nvidia-smi, avec Driver Version, CUDA Version et la liste des cartes. Driver Version affiche la branche installée, 550.163.01 sur Debian 13 selon le tracker Debian.

Trois messages de journal désignent trois causes distinctes

Le message d’erreur nomme la cause mieux que l’écran noir, à condition de lire le bon fichier. Xorg consigne ses erreurs dans /var/log/Xorg.0.log, le noyau dans le journal systemd, et DKMS dans la sortie d’apt pendant la réinstallation. Trois lignes reviennent dans les rapports de bogue, et chacune envoie vers un remède différent.

Un module noyau absent se répare par une réinstallation propre, un en-tête de compilation manquant par l’ajout du paquet correspondant, et un matériel hors support par un changement de branche. Confondre les trois fait perdre une soirée, car purger nvidia-driver ne corrige ni le chargeur de démarrage ni une carte hors support. La distinction se lit au préfixe des lignes : NVRM pour le pilote, EE pour le serveur X. Chaque cause a son propre remède.

(EE) NVIDIA(0): Failed to initialize the NVIDIA kernel module. Please see the
(EE) NVIDIA(0):     system's kernel log for additional error messages and
(EE) NVIDIA(0):     consult the NVIDIA README for details.
(EE) NVIDIA(0): *** Aborting ***

Ces quatre lignes, relevées par le wiki Arch dans Xorg.0.log, disent que le serveur graphique a trouvé le module nvidia absent : l’étape 4 répond à ce cas.

Module build for kernel 6.17.0-14-generic was skipped since the kernel headers for this kernel do not seem to be installed.

Le message ci-dessus, relevé dans le suivi de questions d’Ubuntu, remplace la compilation par un saut silencieux : les en-têtes manquent, et sudo apt install linux-headers-$(uname -r) les pose.

NVRM: The NVIDIA GPU 0000:01:00.0 (PCI ID: 10de:139b)
NVRM: installed in this system is not supported by the 370.28
NVRM: NVIDIA Linux driver release.

La carte est reconnue sur le bus PCI mais refusée par la branche installée. Le wiki Arch donne cet exemple pour un GPU rejeté par la branche 370.28 ; réinstaller le même paquet ne changera rien.

Le paquet réinstallé dépend de la distribution et de la carte

Debian ne choisit pas le pilote dans un catalogue : le paquet nvidia-driver suit la branche publiée dans la suite utilisée. Le tracker Debian attribue 550.163.01-2 à Debian 13, 535.309.01-0+deb12u1 à bookworm par le dépôt de sécurité, et 470.256.02-2 à bullseye. Canonical publie de son côté nvidia-driver-550 en 550.163.01-0ubuntu0.24.04.2 pour Ubuntu 24.04 LTS, sur Launchpad.

L’écart entre les branches décide du comportement, car une carte récente ignore les pilotes antérieurs à une certaine série et un portable peut tomber sur un défaut propre à la sienne. La branche livrée par la distribution est aussi la seule à recevoir les correctifs : le tracker Debian recense encore neuf avis de sécurité ouverts sur 550.163.01 au 1er septembre 2026. apt installe la branche de la suite, et le dépôt de sécurité la fait évoluer.

Distribution Paquet du pilote Version publiée Dépôt qui la sert
Debian 13 (trixie) nvidia-driver 550.163.01-2 suite stable
Debian 12 (bookworm) nvidia-driver 535.309.01-0+deb12u1 bookworm-security
Debian 11 (bullseye) nvidia-driver 470.256.02-2 oldoldstable
Ubuntu 24.04 LTS nvidia-driver-550 550.163.01-0ubuntu0.24.04.2 updates et security

Ces paquets vivent dans le composant non-free-firmware, activé dans /etc/apt/sources.list comme le détaillent les dépôts APT. La documentation NVIDIA de la branche 560.35.03 range le KMS DRM de nvidia_drm parmi les fonctions expérimentales, désactivées par défaut et activables par modeset.

Secure Boot refuse un module compilé sur la machine

Sous Secure Boot, le noyau refuse tout module dont la signature n’est pas reconnue par le micrologiciel. Le pilote propriétaire n’échappe pas à la règle : un module compilé sur la machine par DKMS n’est signé par personne, et son chargement est bloqué. Ce cas est propre aux pilotes construits localement, comme l’explique le forum Ubuntu, parce que les paquets distribués par Canonical portent une signature reconnue.

La distinction tient à l’endroit où la compilation a lieu. Les pilotes livrés dans les paquets linux-modules-nvidia-* sont construits dans l’archive Ubuntu et signés avec les clés du noyau Canonical ; un pilote DKMS est assemblé sur la machine, où la partie secrète de ces clés n’existe pas. Poser la version précompilée pour son noyau suffit alors à garder Secure Boot actif, sans toucher au micrologiciel.

modprobe: ERROR: could not insert 'nvidia': Key was rejected by service

Ce message ne se produit qu’avec Secure Boot activé ; désactiver la protection dans le micrologiciel dépanne aussi, au prix de la sécurité de la machine.

La série 550 bloque certains portables au redémarrage

La branche que Debian 13 installe porte un défaut connu : le wiki Arch signale un blocage pendant une mise à jour ou un redémarrage avec les pilotes de la série 550, limité aux portables. Le tracker Debian attribue 550.163.01-2 à cette suite, ce qui place ces machines sur la branche concernée. Un portable figé après la réinstallation du pilote n’a donc pas forcément un matériel en cause : le bogue se déclare pendant la mise à jour ou le redémarrage, pas pendant une session de travail.

Le contournement passe par une autre branche : les paquets de la série ouverte quand la carte est prise en charge, ou une série 535xx sinon. Ces deux pistes viennent du même paragraphe du wiki Arch, qui relève le défaut sur les portables seulement, pas sur les machines de bureau équipées d’une carte séparée.

La réinstallation ne tranche pas ces cinq questions

Faut-il désactiver Secure Boot pour que le module nvidia se charge ?

Seulement si le module vient de DKMS. Les pilotes des paquets linux-modules-nvidia-* sont signés dans l’archive Ubuntu et se chargent avec Secure Boot actif ; un module compilé sur la machine reste refusé. Poser la version précompilée pour son noyau évite de toucher au micrologiciel.

La compilation DKMS est sautée à chaque mise à jour du noyau, que manque-t-il ?

Les en-têtes du noyau qui vient d’être installé. DKMS le signale par was skipped since the kernel headers for this kernel do not seem to be installed, et le pilote n’existe pas pour ce noyau ; le paquet linux-headers-$(uname -r) fournit ces en-têtes.

Le noyau répond que la carte n’est pas supportée, faut-il la remplacer ?

Une carte de ce type fonctionne toujours, mais la branche installée ne la prend pas en charge. Le wiki Arch montre un GPU refusé par une branche 370.28, et Debian 11 publie encore une branche 470.256.02-2 selon le tracker Debian. Une branche figée ou le pilote libre nouveau règlent le cas.

La machine se bloque avant l’écran de connexion, comment démarrer quand même ?

Le wiki Arch conseille de désactiver le mode KMS, en ajoutant nomodeset à la ligne du noyau dans GRUB. L’affichage reste en basse résolution, suffisant pour purger le pilote fautif. Le menu GRUB démarre aussi sur un noyau antérieur, comme le décrit GRUB et mises à jour.

Faut-il accepter la mise à jour de branche proposée par apt ?

Oui, c’est le seul canal des correctifs : Debian a publié 535.309.01-0+deb12u1 dans bookworm-security le 23 août 2026, et le tracker recense neuf avis de sécurité ouverts sur 550.163.01 au 1er septembre 2026.

Sources