Installation Pop!_OS 24.04 LTS : pilotes NVIDIA, Secure Boot et un bureau propre

février 17, 2026 • février 17, 2026 • Lecture : 27 min • Views: 0

Cet article vous a aidé ?

La façon la plus rapide de gâcher une journée parfaite est de mélanger une nouvelle installation Linux, les pilotes NVIDIA et Secure Boot,
puis de supposer que les paramètres par défaut vous sauveront. Ils ne le feront pas. Ils fonctionneront la plupart du temps, jusqu’à la première mise à jour du noyau,
votre premier écran externe, ou le moment où vous attendez que votre portable se mette en veille et se réveille comme un adulte responsable.

Ceci est un guide d’installation orienté production pour Pop!_OS 24.04 LTS : démarrage prévisible, comportement NVIDIA connu et stable,
et un bureau assez propre pour le rester. Si vous voulez des « modifications esthétiques », vous pourrez les faire plus tard—après avoir des logs.

Priorisez d’abord : choisissez vos batailles (et votre chaîne de démarrage)

Une installation propre de Pop!_OS n’est pas difficile. Une installation propre de Pop!_OS qui survit aux mises à jour du noyau avec NVIDIA et Secure Boot
est un petit exercice de conception système. Vous devez décider ce que vous optimisez :

Posture de sécurité : Exigez‑vous l’application de Secure Boot ? (Politique d’entreprise, démarrage mesuré, environnements régulés.)
Posture de fiabilité : Avez‑vous besoin d’un comportement de pilote prévisible entre les mises à jour ? (Disponibilité du poste, utilisateurs distants, pas de babysitting.)
Posture temporelle : Avez‑vous besoin que « ça marche ce soir » plutôt que « prouvé correct » ? (Vous aurez tout de même besoin de logs.)

Voici la grille honnête :

Si c’est une station de travail personnelle et que vous contrôlez la machine physiquement, désactiver Secure Boot est généralement le chemin le moins douloureux.
Si c’est un portable d’entreprise avec Secure Boot imposé, vous devez soit (a) utiliser des modules signés par une chaîne de confiance du fournisseur/distribution,
soit (b) enregistrer votre propre Machine Owner Key (MOK) et signer vous‑même les modules NVIDIA.
Si vous utilisez des graphiques hybrides (iGPU Intel/AMD + dGPU NVIDIA), l’approche « forcer NVIDIA tout le temps » est celle qui vous donnera
une autonomie mesurée en pauses café.

Une vérité sèche : Secure Boot n’existe pas pour vous faciliter la vie. Il existe pour compliquer la vie de votre attaquant, et il réussit en étant exigeant.
Le module noyau qui pilote votre GPU est exactement le genre de composant que Secure Boot veut ne pas faire confiance par défaut.

Faits et contexte intéressants (pour que les bizarreries aient du sens)

UEFI Secure Boot est apparu dans les PC grand public au début des années 2010, principalement pour empêcher les bootkits qui altèrent le système avant le chargement de l’OS.
Le pilote NVIDIA sur Linux a été historiquement propriétaire, ce qui complique son intégration aux workflows noyau ouverts des distributions.
DKMS (Dynamic Kernel Module Support) existe pour que les modules tiers se reconstruisent automatiquement lors des mises à jour du noyau—idéal jusqu’à ce que Secure Boot refuse le module reconstruit.
nouveau est le pilote communautaire pour les GPU NVIDIA ; il suffit pour l’affichage basique sur beaucoup de cartes, mais n’est pas un remplacement direct pour les usages CUDA intensifs.
Wayland est l’avenir des bureaux Linux depuis des années ; le support NVIDIA s’est beaucoup amélioré dans les générations récentes de pilotes, mais il reste des cas limites.
systemd-boot est un gestionnaire d’amorçage UEFI simple ; Pop!_OS l’utilise traditionnellement, ce qui est rapide et propre—jusqu’à ce que vous ayez à jongler avec plusieurs OS.
Le chiffrement LUKS du disque complet est maintenant mature et ennuyeux, ce qui est exactement ce que vous voulez pour le chiffrement.
Le basculement des graphiques hybrides sur Linux était autrefois un désastre. C’est maintenant en grande partie gérable avec les bons outils et des attentes réalistes.

Pré-vol : vérifiez le mode du firmware, les disques et la carte GPU que vous possédez réellement

Avant d’écrire quoi que ce soit sur le disque, collectez les faits. Vous n’êtes pas paranoïaque ; vous êtes efficace.
La plupart des échecs « mystérieux » sont juste du matériel non documenté et un mode de démarrage flou.

Connaître votre mode de démarrage : UEFI ou legacy

Vous voulez UEFI. Pas parce que c’est à la mode, mais parce que Secure Boot et les entrées de démarrage propres sont plus faciles à raisonner.
Si vous êtes accidentellement en mode legacy, vous pouvez perdre un après‑midi à chasser des fantômes.

Connaître la topologie de votre GPU

« J’ai un GPU NVIDIA » ne suffit pas. Est‑ce le seul GPU, ou êtes‑vous sur un portable hybride avec un iGPU ?
La stratégie de pilote est différente. Le comportement d’alimentation est différent. Le comportement des écrans est différent.

Connaître votre disposition de disque et ce que vous êtes prêt à effacer

L’installation de Pop!_OS est sans douleur quand la réponse est « effacer tout le disque ». Ce n’est pas sans douleur si vous conservez
une partition Windows, un ancien volume /home Linux, ou un environnement de récupération d’entreprise.

Média d’installation préparé comme il faut

Téléchargez le bon ISO. Pop!_OS propose généralement une variante NVIDIA et une variante Intel/AMD. Si vous avez un GPU NVIDIA,
l’ISO NVIDIA est en général le bon choix car il réduit les problèmes d’affichage en early‑boot et vous évite la première danse d’installation des pilotes.

Faites maintenant la partie peu glamour : validez ce que vous avez téléchargé, écrivez‑le proprement, et démarrez‑le dans le mode attendu.
Le nombre de rapports « l’installateur Linux est cassé » qui sont en réalité « clé USB défaillante » n’est pas négligeable.

Blague #1 : les clés USB ont un seul travail, et elles le traitent toujours comme une suggestion.

Secure Boot + NVIDIA : trois stratégies viables

Voici les trois chemins qui n’aboutissent pas en larmes. Choisissez‑en un et tenez‑vous‑y. Les mélanger en vol est la façon d’obtenir une machine qui ne démarre
que lorsque la lune est dans la bonne phase.

Stratégie A : Désactiver Secure Boot (plus rapide, moins fragile)

Si vous possédez le matériel et n’avez pas d’exigence politique, désactivez Secure Boot dans le firmware.
L’avantage : les reconstructions DKMS de NVIDIA ne seront pas bloquées. Les mises à jour du noyau vous surprendront moins.
L’inconvénient : vous perdez cette couche d’application d’intégrité pré‑OS.

Stratégie B : Laisser Secure Boot activé, utiliser des modules signés via l’intégration fournisseur/distribution (idéal quand disponible)

Dans un monde parfait, les modules noyau NVIDIA installés sur votre système sont signés avec une clé approuvée par votre firmware.
Quand c’est le cas, Secure Boot reste activé et la vie est belle. Quand ce n’est pas le cas, votre système démarre avec un pilote d’affichage basique ou échoue à charger le module NVIDIA.

Que vous ayez cela « gratuitement » dépend du packaging, de la saveur du noyau et de la manière dont Pop!_OS intègre NVIDIA sur 24.04 LTS.
Prévoyez de vérifier plutôt que d’assumer.

Stratégie C : Laisser Secure Boot activé, enregistrer votre propre MOK et signer les modules NVIDIA (plus de contrôle, plus de travail)

C’est la réponse adaptée en entreprise quand vous ne pouvez pas désactiver Secure Boot mais avez besoin du module propriétaire NVIDIA.
Vous générez une paire de clés, enregistrez la clé publique via MOK, et signez les modules noyau après leur construction.

C’est aussi là où les gens coupent les coins et découvrent plus tard que « mise à jour du noyau » est un événement récurrent, pas une gêne ponctuelle.
Automatisez l’étape de signature ou acceptez que quelqu’un la manque à 2 h du matin.

Listes de contrôle / plan pas à pas : installation propre jusqu’au premier démarrage

Checklist : avant de démarrer l’installateur

Confirmez que la machine démarre en UEFI.
Décidez de la stratégie Secure Boot (A/B/C ci‑dessus).
Si double amorçage, identifiez quel disque/partition peut être effacé sans risque.
Ayez un second appareil à portée de main pour les bascules firmware et les étapes de récupération.

Checklist : choix de l’installateur qui comptent

Chiffrement du disque : activez‑le si c’est un portable ou une machine susceptible de quitter votre bureau.
/home séparé : optionnel ; pour la plupart des postes, une racine chiffrée unique suffit. Un /home séparé aide si vous réinstallez souvent.
Swap : assurez‑vous d’avoir assez de swap pour l’hibernation si vous prévoyez de l’utiliser ; sinon ne vous en faites pas trop.

Checklist : premier démarrage après l’installation

Mettre à jour complètement le système avant de commencer les réglages.
Vérifier quel pilote GPU est actif et si l’accélération fonctionne.
Ce n’est qu’ensuite que vous ajustez Wayland/Xorg, le mode graphique hybride et le nettoyage du bureau.

Durcissement post‑installation : pilotes, mises à jour et contrôles de cohérence

Pop!_OS facilite l’accès à un bureau fonctionnel. Votre travail est de le maintenir fonctionnel après les mises à jour.
Cela signifie vérifier la pile de pilotes, garder le firmware sain, et s’assurer qu’il existe des logs quand les choses tournent mal.

Wayland vs Xorg : choisissez selon votre charge de travail

Si vous faites beaucoup de capture d’écran, utilisez des gestionnaires de fenêtres de niche ou des workflows de bureau à distance, Xorg peut rester la voie de la moindre surprise.
Si vous voulez une meilleure gestion multi‑écran et des propriétés de sécurité modernes, Wayland est la direction.
Sur NVIDIA, les deux peuvent fonctionner—jusqu’à ce qu’ils ne fonctionnent pas—alors validez avec votre charge de travail réelle, pas une démo.

Mises à jour du noyau : le piège prévisible

Le module NVIDIA doit correspondre à votre noyau. Si vous mettez à jour le noyau et que le module NVIDIA échoue à se construire ou à se charger,
vous obtenez une station de travail « fonctionnait mardi, cassée mercredi ». C’est pourquoi nous faisons des tâches de vérification avec des commandes.

Un bureau propre : quoi supprimer, quoi garder, et pourquoi

Propre ne veut pas dire minimal. Propre signifie que vous pouvez dire ce qui a changé, que vous pouvez annuler, et que vous pouvez diagnostiquer.
Le principal anti‑motif du bureau est « accumulation aléatoire de réglages » jusqu’à ce que vous ne sachiez plus quel bouton a causé la régression.

Ce que je garde

Un terminal : et je l’épingle. Si votre terminal bouge, vous perdez du temps.
Un workflow de mise à jour : GUI ou CLI, choisissez‑en un comme source de vérité.
Une politique de mode graphique : intégré pour l’autonomie, NVIDIA pour la performance, hybride quand vous en avez vraiment besoin.
Logs et outils : accès au journal, paquets de diagnostic basiques, et l’habitude de les consulter.

Ce que je supprime ou désactive

Démarrages automatiques inutiles qui créent du bruit de fond et des notifications confuses.
Boutiques d’applications redondantes ou mécanismes de mise à jour qui se font concurrence.
Extensions de shell expérimentales sauf si vous êtes prêt à déboguer les ruptures GNOME après les mises à jour.

Blague #2 : les extensions de bureau sont comme des animaux de compagnie—adoptez‑les, nourrissez‑les, et attendez‑vous à ce qu’elles cassent quelque chose de coûteux quand vous ne regardez pas.

Graphismes hybrides et portables : arrêtez de lutter contre votre GPU

Sur les portables hybrides, votre iGPU est généralement câblé aux écrans internes et votre dGPU est là pour des pics de performance.
Forcer NVIDIA tout le temps peut :

augmenter la consommation au repos,
rendre la suspension/reprise moins fiable,
introduire des comportements étranges avec les écrans externes selon le design du mux du portable.

L’approche correcte est basée sur une politique :

Par défaut : graphiques intégrés pour le travail normal.
À la demande : exécuter des applications spécifiques sur NVIDIA.
Mode NVIDIA complet : seulement si vous êtes sur une station d’accueil, branché, et que vous poussez vraiment les pixels.

Braîve‑fiche de diagnostic rapide

Quand quelque chose ne va pas—écran noir, faible FPS, écran externe mort, suspension cassée—ne commencez pas par réinstaller.
Commencez par réduire le goulot d’étranglement. C’est la même mentalité que pour la réponse à incident en production : isolez la couche.

Premier point : le module noyau est‑il chargé et sain ?

Vérifiez si le pilote NVIDIA est présent et chargé.
Vérifiez si Secure Boot le bloque.
Vérifiez si nouveau a pris l’appareil.

Deuxième point : le chemin du serveur d’affichage est‑il cohérent (Wayland/Xorg) et correspond‑il à votre pilote ?

Identifiez le type de session (Wayland vs X11).
Confirmez que le compositeur utilise l’accélération GPU.

Troisième point : est‑ce un problème de firmware/chaîne de démarrage ?

Vérifiez les entrées UEFI et que vous démarrez bien ce que vous pensez démarrer.
Vérifiez les mises à jour récentes du noyau et les échecs de construction DKMS.

Quatrième point : est‑ce un problème de topologie matérielle (hybride/mux/ports externes) ?

Cartographiez quel GPU pilote quelles sorties d’affichage.
Décidez si vous avez besoin du mode intégré, hybride ou NVIDIA.

Idée paraphrasée de Werner Vogels (CTO d’Amazon) : vous construisez des systèmes en supposant que la panne arrivera, puis vous concevez pour que les pannes soient survivables.

Erreurs courantes : symptômes → cause racine → correction

1) Démarrage sur un écran noir après une mise à jour

Symptômes : le système démarre, le rétroéclairage est actif, peut‑être un curseur, pas de bureau.

Cause racine : le module NVIDIA ne s’est pas chargé (DKMS a échoué) ou Secure Boot l’a bloqué ; le serveur d’affichage repasse mal.

Correction : démarrez un noyau précédent si disponible, inspectez l’état DKMS et le Secure Boot, réinstallez le pilote NVIDIA, et assurez‑vous de la signature des modules si vous laissez Secure Boot activé.

2) « Using llvmpipe » ou performance médiocre

Symptômes : animations saccadées, applications lourdes GPU lentes, glxinfo montre du rendu logiciel.

Cause racine : pilote non chargé ; Xorg/Wayland tourne sans accélération GPU ; mauvais GPU sélectionné sur un système hybride.

Correction : vérifiez le module noyau nvidia, assurez‑vous du type de session correct, sélectionnez le mode graphique approprié, et confirmez avec nvidia-smi.

3) Écran externe non détecté sur dock de portable

Symptômes : l’écran fonctionne sous Windows, pas sous Pop!_OS ; ou seulement en mode NVIDIA.

Cause racine : le port est câblé sur un GPU spécifique ; le dock utilise DisplayLink ; ou le chemin du compositeur diffère sur Wayland.

Correction : identifiez le câblage avec lspci/inxi et testez les modes ; si DisplayLink, installez la pile de pilotes appropriée ; sinon utilisez le mode GPU qui pilote le port.

4) Secure Boot activé, le pilote NVIDIA « s’installe » mais ne se charge jamais

Symptômes : paquets installés, mais modprobe nvidia échoue ; les logs mentionnent « Required key not available. »

Cause racine : module noyau non signé bloqué par Secure Boot.

Correction : désactivez Secure Boot, ou enregistrez un MOK et signez les modules, ou utilisez des paquets signés si disponibles dans votre environnement.

5) Suspension/reprise échoue ou ventilateurs qui tournent tout le temps

Symptômes : le portable se réveille sur un écran noir ; la batterie se vide pendant la veille ; les ventilateurs tournent.

Cause racine : le dGPU n’est pas mis hors tension correctement, paramètres d’alimentation/pilote non appariés, mauvaise configuration du mode hybride.

Correction : testez intégré vs hybride vs mode NVIDIA ; assurez‑vous de la version correcte du pilote NVIDIA ; vérifiez les logs autour de la suspension/reprise et envisagez de désactiver l’hibernation si elle n’est pas nécessaire.

Trois mini‑histoires d’entreprise issues du terrain

Incident causé par une fausse hypothèse : « Secure Boot est activé, donc les pilotes doivent être ok »

Une entreprise a déployé une série de portables Linux pour une équipe réalisant de l’analyse GPU‑accélérée et du développement CUDA léger.
L’image de base était dans l’esprit Pop!_OS : bureau moderne, pilotes NVIDIA préinstallés, chiffrement activé.
En test, tout semblait correct. Chacun pouvait se connecter, ouvrir un terminal et exécuter quelques charges d’exemple.

L’hypothèse erronée était subtile : ils ont supposé que parce que Secure Boot était activé et que le système démarrait proprement,
le module noyau NVIDIA était aussi approuvé et chargé. Sur les machines de test, une configuration firmware particulière
était moins stricte ; sur la flotte de production, l’application de Secure Boot était plus stricte.

La première mise à jour du noyau est arrivée. La moitié de la flotte est revenue avec du rendu logiciel et des écrans externes cassés.
Les utilisateurs ont ouvert des tickets du type « Linux est lent maintenant » et « le dock ne marche plus », ce qui ressemble à de véritables incidents : symptômes vagues,
opinions fortes, et aucune étape reproductible.

La correction n’était pas difficile, mais la réponse a été chaotique parce que l’équipe n’avait pas de stratégie Secure Boot arrêtée.
Certaines machines avaient Secure Boot désactivé à la va‑vite. Certaines avaient un MOK enregistré manuellement. Quelques‑unes sont restées à moitié configurées,
ce qui a fait que la mise à jour suivante les a re‑cassées.

La leçon : on ne peut pas improviser la chaîne de démarrage. Soit vous concevez pour Secure Boot avec la signature de modules comme workflow de première classe,
soit vous le désactivez intentionnellement et documentez pourquoi. « On n’a rien touché » n’est pas une stratégie.

Optimisation qui s’est retournée contre eux : « Forcer le mode NVIDIA partout pour la performance »

Une autre organisation a standardisé des portables hybrides. Un ingénieur a bien intentionné mis le mode par défaut sur NVIDIA uniquement,
arguant que cela réduirait les « bizarreries graphiques » et rendrait la performance constante pour les appels vidéo et l’accélération du navigateur.
Sur le tableau blanc, ça paraissait propre.

En pratique, l’autonomie a implosé. Les utilisateurs ont commencé à traîner des chargeurs comme des talismans. Les échecs de suspension/reprise ont augmenté,
mais les échecs étaient suffisamment intermittents pour être rejetés comme « Linux qui fait Linux » jusqu’à ce que suffisamment de personnes se plaignent.

Le pire : le changement a rendu le débogage plus difficile. Quand tout tourne sur le dGPU, on ne peut pas facilement distinguer
« problème de compositeur » de « problème de gestion d’énergie ». Tout ressemble à un « problème GPU ».

Ils sont revenu au mode intégré par défaut avec offload à la demande pour les applications lourdes spécifiques.
La performance est restée correcte en usage normal, et la machine a recommencé à se comporter comme un portable.

La leçon : optimiser une station pour un seul indicateur (« GPU max toujours ») déplace souvent la douleur ailleurs.
Batterie, thermiques et mise en veille sont des fonctionnalités de fiabilité, pas des bonus.

Pratique ennuyeuse mais correcte qui a sauvé la mise : « Une base connue‑bonne, un script de validation »

Une troisième équipe gérait une flotte mixte : quelques postes fixes avec GPU NVIDIA simple, des portables hybrides,
et une poignée de machines qui devaient garder Secure Boot activé pour des raisons de politique.
Ils ont fait une chose systématique : maintenir une checklist d’installation de référence et un petit script de validation.

La validation n’était pas sophistiquée. Elle vérifiait l’état de Secure Boot, la version du noyau, le chargement du module NVIDIA, le type de session (Wayland/Xorg),
et si l’accélération matérielle était réellement active. Elle collectait aussi les logs pertinents dans un tarball unique
que les utilisateurs pouvaient joindre aux tickets sans un aller‑retour de deux heures.

Lorsqu’une mise à jour a causé un décalage de pilote sur un sous‑ensemble de machines, ils n’ont pas polémiqué.
Ils ont comparé les sorties de validation et ont immédiatement vu que les constructions DKMS avaient échoué sur des systèmes manquant les en‑têtes du noyau.
Ce n’est pas glamour. C’est juste correct.

Ils ont corrigé l’image, mis à jour la checklist pour s’assurer que les en‑têtes étaient présents, et le problème a cessé de réapparaître.
Personne n’a fait la fête, ce qui est signe que c’était une bonne pratique opérationnelle.

La leçon : la répétabilité ennuyeuse bat le dépannage héroïque. À chaque fois.

Tâches pratiques : commandes, sorties et la décision que vous prenez

Voici les tâches que j’exécute réellement quand je veux de la confiance. Chacune inclut : la commande, ce que la sortie signifie, et ce que vous décidez ensuite.
Exécutez‑les dans l’ordre quand vous construisez un nouveau système, ou sautez‑y pendant un incident.

Task 1: Confirm you booted in UEFI mode

cr0x@server:~$ test -d /sys/firmware/efi && echo "UEFI boot" || echo "Legacy boot"
UEFI boot

Signification : « UEFI boot » indique que vous êtes en mode UEFI et que les variables UEFI sont accessibles.
Décision : Si vous voyez « Legacy boot », arrêtez et corrigez les réglages du firmware avant de déboguer Secure Boot ou les entrées de démarrage.

Task 2: Check Secure Boot state

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

Signification : Secure Boot est appliqué.
Décision : Si activé, choisissez la Stratégie B ou C. Si votre module NVIDIA est non signé, il sera bloqué.

Task 3: Identify GPUs present

cr0x@server:~$ lspci -nn | egrep -i 'vga|3d|display'
00:02.0 VGA compatible controller [0300]: Intel Corporation Raptor Lake-P [8086:a7a0]
01:00.0 3D controller [0302]: NVIDIA Corporation GA107M [GeForce RTX 3050 Mobile] [10de:25a2]

Signification : C’est un système hybride (Intel iGPU + NVIDIA dGPU).
Décision : Planifiez votre mode graphique (intégré/hybride/NVIDIA). Ne supposez pas que « NVIDIA toujours » est optimal.

Task 4: See what driver is bound to the NVIDIA device

cr0x@server:~$ sudo lshw -c display -short
H/W path           Device      Class          Description
=========================================================
/0/100/2           /dev/fb0    display        Intel Corporation Raptor Lake-P
/0/100/1/0                     display        NVIDIA Corporation GA107M [GeForce RTX 3050 Mobile]

Signification : Le matériel est détecté. Cela ne prouve pas que le module noyau NVIDIA est actif pour le rendu.
Décision : Continuez avec les vérifications de module et de l’accélération.

Task 5: Confirm the NVIDIA kernel module is loaded

cr0x@server:~$ lsmod | grep -E '^nvidia'
nvidia              9994240  120
nvidia_drm            86016  12
nvidia_modeset       1605632  18 nvidia_drm

Signification : Les modules NVIDIA sont chargés dans le noyau en cours.
Décision : Si rien ne correspond, vous n’utilisez pas NVIDIA, le module a échoué à se charger, ou Secure Boot l’a bloqué. Vérifiez les logs ensuite.

Task 6: If the module isn’t loaded, see why (kernel log)

cr0x@server:~$ sudo dmesg -T | egrep -i 'nvidia|nouveau|secure|signature|key' | tail -n 20
[Mon Feb  5 10:12:03 2026] nvidia: loading out-of-tree module taints kernel.
[Mon Feb  5 10:12:03 2026] nvidia: module verification failed: signature and/or required key missing - tainting kernel

Signification : La vérification de la signature du module a échoué. Sur un système avec Secure Boot activé vous pourriez plutôt voir « Required key not available » et le module ne se chargera pas.
Décision : Si Secure Boot est activé, procédez à l’enregistrement MOK et à la signature ou désactivez Secure Boot.

Task 7: Confirm whether nouveau is active (it often shouldn’t be)

cr0x@server:~$ lsmod | grep nouveau
nouveau              2387968  0
drm_ttm_helper         16384  1 nouveau
ttm                  102400  2 drm_ttm_helper,nouveau

Signification : nouveau est chargé.
Décision : Si vous comptez utiliser le pilote propriétaire NVIDIA, vous voulez généralement désactiver/blacklister nouveau et charger le module NVIDIA à la place.

Task 8: Check which session type you’re running (Wayland vs X11)

cr0x@server:~$ echo $XDG_SESSION_TYPE
wayland

Signification : Vous êtes en Wayland.
Décision : Si vous avez des problèmes d’affichage NVIDIA, testez une session X11 pour isoler les problèmes de compositeur vs pilote.

Task 9: Validate acceleration path with OpenGL renderer

cr0x@server:~$ glxinfo -B | egrep 'OpenGL renderer|OpenGL vendor|direct rendering'
direct rendering: Yes
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: NVIDIA GeForce RTX 3050 Laptop GPU/PCIe/SSE2

Signification : L’accélération matérielle via NVIDIA est active (au moins pour ce chemin GL).
Décision : Si vous voyez « llvmpipe » ou le fournisseur « Mesa », vous êtes en rendu logiciel ou sur l’iGPU ; revenez au chargement du module et au mode graphique.

Task 10: Confirm the NVIDIA driver stack sees the GPU

cr0x@server:~$ nvidia-smi
Tue Feb  5 10:14:44 2026
+---------------------------------------------------------------------------------------+
| NVIDIA-SMI 550.54.14              Driver Version: 550.54.14      CUDA Version: 12.4  |
|-----------------------------------------+------------------------+--------------------|
| GPU  Name                 Persistence-M | Bus-Id          Disp.A | Volatile Uncorr. ECC |
|   0  GeForce RTX 3050 ...          Off  | 00000000:01:00.0  Off  |                  N/A |
+-----------------------------------------+------------------------+--------------------+

Signification : Le pilote est installé et communique avec le GPU.
Décision : Si cela échoue, concentrez‑vous sur l’état d’installation du pilote, les erreurs de chargement du module, et le blocage par Secure Boot.

Task 11: Inspect DKMS status (did a kernel update break module builds?)

cr0x@server:~$ dkms status
nvidia/550.54.14, 6.8.0-49-generic, x86_64: installed

Signification : DKMS a construit et installé le module pour le noyau en cours.
Décision : Si vous voyez « added » ou « build error », corrigez les en‑têtes/outils et reconstruisez avant de redémarrer sur un noyau plus récent.

Task 12: Ensure kernel headers exist for the running kernel

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

cr0x@server:~$ dpkg -l | grep -E "linux-headers-$(uname -r)" | awk '{print $2, $3}'
linux-headers-6.8.0-49-generic 6.8.0-49.49

Signification : Les en‑têtes sont installés pour le noyau actif.
Décision : Si elles manquent, installez les en‑têtes avant d’essayer de reconstruire les modules NVIDIA (surtout après les mises à jour).

Task 13: Check boot entries (sanity for multi-boot and “why did it boot the wrong thing?”)

cr0x@server:~$ sudo efibootmgr -v | head -n 8
BootCurrent: 0003
Timeout: 1 seconds
BootOrder: 0003,0001,0000
Boot0003* Pop!_OS  HD(1,GPT,3b7c3d5a-7ed5-4f5b-a2e0-9f2e1b0e1e4a,0x800,0x100000)/File(\EFI\systemd\systemd-bootx64.efi)
Boot0001* Windows Boot Manager  HD(1,GPT,3b7c3d5a-7ed5-4f5b-a2e0-9f2e1b0e1e4a,0x800,0x32000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)

Signification : Vous voyez quel gestionnaire de démarrage vous utilisez réellement et l’ordre de démarrage.
Décision : Si le firmware continue de démarrer Windows ou une ancienne entrée, corrigez BootOrder. Ne réinstallez pas l’OS en espérant qu’il apprenne les bonnes manières.

Task 14: Check journal for NVIDIA and display-manager errors (last boot)

cr0x@server:~$ sudo journalctl -b -p err --no-pager | egrep -i 'nvidia|gdm|sddm|wayland|xorg|drm' | head -n 30
Feb 05 10:11:58 cr0x kernel: nvidia_drm: loading out-of-tree module taints kernel.
Feb 05 10:11:59 cr0x gdm[1189]: GdmDisplay: Session never registered, failing

Signification : Des erreurs existent autour du démarrage NVIDIA et/ou du gestionnaire d’affichage.
Décision : Si le gestionnaire d’affichage échoue, testez le changement de type de session ou la réinstallation de la pile de pilotes ; évitez les réglages de bureau aléatoires tant que ce n’est pas propre.

Task 15: Confirm installed NVIDIA packages (what’s actually on disk)

cr0x@server:~$ dpkg -l | grep -E 'nvidia-driver|nvidia-dkms|libnvidia|cuda' | head -n 20
ii  nvidia-driver-550      550.54.14-0pop0~1700000000~24.04~abcd123  amd64  NVIDIA driver metapackage
ii  nvidia-dkms-550        550.54.14-0pop0~1700000000~24.04~abcd123  amd64  NVIDIA DKMS package
ii  libnvidia-gl-550       550.54.14-0pop0~1700000000~24.04~abcd123  amd64  NVIDIA OpenGL/GLX/EGL/GLES GLVND libraries

Signification : Vous avez les paquets attendus installés.
Décision : Si des paquets manquent ou sont mélangés entre versions, nettoyez et réinstallez pour une version cohérente du pilote.

Task 16: If you need MOK: verify enrolled keys exist

cr0x@server:~$ mokutil --list-enrolled | head -n 20
MokListRT:
  SHA1 Fingerprint: 3a:9f:19:2e:7c:2a:0f:9b:51:4b:4c:9e:2d:14:0a:aa:ef:01:22:de
  Subject: CN=Local NVIDIA Module Signing

Signification : Un MOK est enregistré.
Décision : Si aucune clé pertinente n’est enregistrée et que Secure Boot est activé, vous devez en enregistrer une avant que des modules signés puissent se charger.

FAQ

1) Dois‑je utiliser l’ISO NVIDIA ou l’ISO standard ?

Si votre machine a un GPU NVIDIA et que vous voulez le pilote propriétaire, utilisez l’ISO NVIDIA.
Il réduit les problèmes d’affichage en early‑boot et vous amène à un bureau utilisable plus rapidement.

2) Puis‑je garder Secure Boot activé et utiliser NVIDIA ?

Oui, mais vous devez vous assurer que le module noyau NVIDIA est approuvé par Secure Boot.
Cela signifie des modules signés via l’intégration de packaging ou l’enregistrement d’un MOK et la signature vous‑même.

3) J’ai activé Secure Boot et maintenant le pilote NVIDIA « s’installe » mais ne fonctionne pas. Pourquoi ?

Parce que l’installation n’est pas l’activation. Secure Boot peut bloquer le module au moment de l’exécution.
Vérifiez mokutil --sb-state, dmesg, et si lsmod montre nvidia.

4) Wayland ou Xorg avec NVIDIA ?

Utilisez Wayland si votre flux de travail est grand public et que vous voulez le comportement moderne du compositeur.
Utilisez Xorg si vous dépendez d’outils de bureau à distance spécifiques, d’apps graphiques de niche, ou que vous déboguez un problème d’affichage NVIDIA tenace.
La bonne réponse est : testez les deux et gardez celle qui échoue le moins pour votre charge de travail.

5) Mon écran externe ne fonctionne qu’en mode NVIDIA. Est‑ce normal ?

Sur certains portables, oui. Certains ports sont câblés sur le dGPU. Si le port est du côté NVIDIA du mux matériel,
le mode intégré ne le conduira pas. Validez votre topologie, puis choisissez le mode qui correspond au câblage physique.

6) Dois‑je blacklister nouveau ?

Si vous utilisez le pilote propriétaire NVIDIA, généralement oui—nouveau peut revendiquer le périphérique ou interférer avec l’initialisation.
Si vous utilisez volontairement nouveau (bureau basique, pas de CUDA), alors n’installez pas la pile propriétaire.

7) Pourquoi une mise à jour du noyau a‑t‑elle cassé mes graphiques ?

Parce que le module NVIDIA est étroitement couplé à l’ABI du noyau.
Si DKMS échoue à construire (en‑têtes manquants, incompatibilité du compilateur, problème de packaging) vous redémarrez sur un noyau sans module NVIDIA fonctionnel.
Vérifiez toujours dkms status après les mises à jour avant de redémarrer.

8) Dois‑je activer le chiffrement du disque complet ?

Oui pour les portables et tout ce qui quitte votre contrôle. C’est mature et l’impact sur les performances est généralement négligeable sur le matériel moderne.
Pour les postes fixes dans des salles verrouillées, c’est toujours raisonnable, mais priorisez vos exigences opérationnelles.

9) Pop!_OS est‑il « bon pour NVIDIA » comparé à d’autres distributions ?

Il est souvent plus accueillant dès la sortie de la boîte, surtout avec l’ISO NVIDIA et une approche cohérente des pilotes.
Cela dit, NVIDIA sur Linux n’est jamais « oublié et terminé » si vous mettez fréquemment le noyau à jour. La vérification est la vraie fonctionnalité.

10) Quelle est la récupération la plus simple quand le bureau ne démarre pas ?

Démarrez dans un TTY, vérifiez si le module NVIDIA s’est chargé, inspectez journalctl pour les erreurs du gestionnaire d’affichage,
et revenez à un noyau précédent si disponible. Réinstallez la pile de pilotes seulement après avoir identifié ce qui a échoué.

Prochaines étapes à réaliser réellement

Si vous voulez que cette installation reste propre, faites ces étapes suivantes dans l’ordre :

Verrouillez votre décision Secure Boot (désactivez‑le ou implémentez la signature MOK). Ne laissez pas cela ambigu.
Exécutez les tâches de validation après chaque mise à jour noyau/pilote : module chargé, état DKMS, type de session, et nvidia-smi.
Choisissez une politique de mode graphique pour les portables hybrides et tenez‑vous‑y. Intégré par défaut est généralement la base raisonnable.
Gardez le bureau ennuyeux : moins d’extensions, moins d’agents en arrière‑plan, moins de surprises.
Capturez les logs quand ça casse avant de redémarrer trois fois et d’effacer les preuves.

L’objectif n’est pas un système parfait. L’objectif est un système que vous comprenez sous pression—parce qu’un jour, vous serez sous pression.