[Résolu] Incompatibilité du pilote non-libre nvidia avec Linux 5.9

Herve5 · 25-10-2020 15:19:09

OK. Comment je reviens au bureau après l'avoir quitté? Un truc comme startx?
Sinon, mes vilaines alertes "unable to locate..." en rouge ou "Error getting user list from org.freedesktop..." c'est pas grave?
Je vais me relogguer en user et tester ctrl-alt-F2

anonyme · 25-10-2020 15:35:16

F7 ou F6 tu revient pas sur le bureau ?
normalement la session graphique n'est pas fermé

oct. 25 15:35:37 LinuxHerve lightdm[1324]: gkr-pam: gnome-keyring-daemon started properly and unlocked keyring  => tout va bien

oct. 25 14:45:54 LinuxHerve lightdm[5008]: Error getting user list from org.freedesktop.Accounts: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: TThe name org.freedesktop.Accounts was not provided by any .service files   => cela ne devrait pas exister en user

oct. 25 14:45:54 LinuxHerve lightdm[5008]: pam_unix(lightdm-greeter:session): session opened for user lightdm by (uid=0) ça aussi du a root (normalement un truc comme "1000"

oct. 25 14:45:56 LinuxHerve lightdm[5076]: pam_unix(lightdm:auth): Couldn't open /etc/securetty: No such file or directory  => bidon securetty n'existe plus un bug pas méchant

oct. 25 14:45:59 LinuxHerve lightdm[5076]: pam_unix(lightdm:auth): Couldn't open /etc/securetty: No such file or directory  => idem

oct. 25 14:45:59 LinuxHerve lightdm[5076]: gkr-pam: unable to locate daemon control file => bidon aussi , a la fin ça se termine correctement (dernière ligne )

oct. 25 14:45:59 LinuxHerve lightdm[5076]: gkr-pam: stashed password to try later in open session  => surement du a root aussi

oct. 25 14:45:59 LinuxHerve lightdm[5076]: Error getting user list from org.freedesktop.Accounts: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.Accounts was not provided by any .service files  => normal root n'est pas un user

oct. 25 14:46:00 LinuxHerve lightdm[5076]: pam_unix(lightdm:session): session opened for user root by (uid=0)  pam fait son job pour root

oct. 25 14:46:00 LinuxHerve lightdm[5076]: gkr-pam: gnome-keyring-daemon started properly and unlocked keyring   => tout se termine bien

pourquoi j'ai pas la même chose , les paquets sont présent (gnome-keyring , libpam-gnome-keyring )

oct. 25 15:29:20 debian4 systemd[1]: Starting Light Display Manager...

oct. 25 15:29:20 debian4 systemd[1]: Started Light Display Manager.

oct. 25 15:29:21 debian4 lightdm[693]: pam_unix(lightdm-greeter:session): session opened for user lightdm by (uid=0)

oct. 25 15:29:34 debian4 lightdm[742]: pam_unix(lightdm:session): session opened for user robert by (uid=0)

uid=0 je sais pas , ça semble correct

Dernière modification par anonyme (25-10-2020 15:54:05)

Herve5 · 25-10-2020 15:50:05

Merci! effectivement je reviens dans la session ainsi, je n'ai pas l'habitude.
Donc, est-ce que je considère correctement que lightdm va bien?

anonyme · 25-10-2020 15:55:51

oui je pense mais je vois pas ce qui cloche

journalctl -r -p err

 

Herve5 · 25-10-2020 16:24:37

anonyme a écrit :

oui je pense mais je vois pas ce qui cloche

journalctl -r -p err

j'ai été obligé d'ouvrir une session en root car en user avec mes fenêtres sans bord je ne pouvais redimensionner la largeur, et tout était coupé...

Voici:

-- Logs begin at Sun 2020-10-25 13:10:09 CET, end at Sun 2020-10-25 16:55:53 CET. --

oct. 25 16:55:40 LinuxHerve lightdm[4872]: gkr-pam: unable to locate daemon control file

oct. 25 16:55:34 LinuxHerve bluetoothd[653]: src/profile.c:ext_start_servers() RFCOMM server failed for Headset unit: rfcomm_bind: Address already in use (98)

oct. 25 16:55:34 LinuxHerve bluetoothd[653]: src/profile.c:ext_start_servers() RFCOMM server failed for Headset Voice gateway: rfcomm_bind: Address already in use (98)

oct. 25 16:50:38 LinuxHerve lightdm[4577]: gkr-pam: unable to locate daemon control file

oct. 25 16:39:38 LinuxHerve bluetoothd[653]: src/profile.c:ext_start_servers() RFCOMM server failed for Headset unit: rfcomm_bind: Address already in use (98)

oct. 25 16:39:38 LinuxHerve bluetoothd[653]: src/profile.c:ext_start_servers() RFCOMM server failed for Headset Voice gateway: rfcomm_bind: Address already in use (98)

oct. 25 16:24:59 LinuxHerve bluetoothd[653]: src/profile.c:ext_start_servers() RFCOMM server failed for Object Push: rfcomm_bind: Address already in use (98)

oct. 25 16:24:59 LinuxHerve bluetoothd[653]: src/profile.c:ext_start_servers() RFCOMM server failed for File Transfer: rfcomm_bind: Address already in use (98)

oct. 25 16:24:59 LinuxHerve bluetoothd[653]: src/profile.c:ext_start_servers() RFCOMM server failed for Synchronization: rfcomm_bind: Address already in use (98)

oct. 25 16:24:59 LinuxHerve bluetoothd[653]: src/profile.c:ext_start_servers() RFCOMM server failed for Phone Book Access: rfcomm_bind: Address already in use (98)

oct. 25 16:24:59 LinuxHerve bluetoothd[653]: src/profile.c:ext_start_servers() RFCOMM server failed for Message Access: rfcomm_bind: Address already in use (98)

oct. 25 16:24:59 LinuxHerve bluetoothd[653]: src/profile.c:ext_start_servers() RFCOMM server failed for Message Notification: rfcomm_bind: Address already in use (98)

oct. 25 16:24:58 LinuxHerve lightdm[3605]: gkr-pam: unable to locate daemon control file

oct. 25 16:24:51 LinuxHerve bluetoothd[653]: src/profile.c:ext_start_servers() RFCOMM server failed for Headset unit: rfcomm_bind: Address already in use (98)

oct. 25 16:24:51 LinuxHerve bluetoothd[653]: src/profile.c:ext_start_servers() RFCOMM server failed for Headset Voice gateway: rfcomm_bind: Address already in use (98)

oct. 25 16:19:32 LinuxHerve lightdm[3240]: gkr-pam: unable to locate daemon control file

oct. 25 16:00:50 LinuxHerve bluetoothd[653]: src/profile.c:ext_start_servers() RFCOMM server failed for Headset unit: rfcomm_bind: Address already in use (98)

oct. 25 16:00:50 LinuxHerve bluetoothd[653]: src/profile.c:ext_start_servers() RFCOMM server failed for Headset Voice gateway: rfcomm_bind: Address already in use (98)

oct. 25 15:42:46 LinuxHerve agetty[2819]: tty2: invalid character 0x1b in login name

oct. 25 15:42:18 LinuxHerve agetty[2797]: tty2: invalid character 0x1b in login name

oct. 25 16:41:21 LinuxHerve lightdm[1306]: gkr-pam: unable to locate daemon control file

oct. 25 16:41:09 LinuxHerve systemd[1]: Failed to start Raise network interfaces.

oct. 25 16:41:09 LinuxHerve dhclient[823]: exiting.

oct. 25 16:41:09 LinuxHerve dhclient[823]: 

oct. 25 16:41:09 LinuxHerve dhclient[823]: process and the information we find helpful for debugging.

oct. 25 16:41:09 LinuxHerve dhclient[823]: before submitting a bug.  These pages explain the proper

oct. 25 16:41:09 LinuxHerve dhclient[823]: bugs on either our web page at www.isc.org or in the README file

oct. 25 16:41:09 LinuxHerve dhclient[823]: than a configuration issue please read the section on submitting

oct. 25 16:41:09 LinuxHerve dhclient[823]: If you think you have received this message due to a bug rather

oct. 25 16:41:09 LinuxHerve dhclient[823]: 

oct. 25 16:41:09 LinuxHerve dhclient[823]: Failed to get interface index: No such device

oct. 25 16:41:09 LinuxHerve bluetoothd[653]: sap-server: Operation not permitted (1)

oct. 25 16:41:09 LinuxHerve bluetoothd[653]: profiles/sap/server.c:sap_server_register() Sap driver initialization failed.

oct. 25 16:41:06 LinuxHerve kernel: iwlwifi 0000:52:00.0: firmware: failed to load iwl-debug-yoyo.bin (-2)

oct. 25 16:41:06 LinuxHerve kernel: firmware_class: See https://wiki.debian.org/Firmware for information about missing firmware

oct. 25 16:41:06 LinuxHerve kernel: iwlwifi 0000:52:00.0: firmware: failed to load iwlwifi-cc-a0-56.ucode (-2)

oct. 25 16:41:06 LinuxHerve kernel: tpm tpm0: [Firmware Bug]: TPM interrupt not working, polling instead

oct. 25 16:41:06 LinuxHerve kernel: tpm tpm0: tpm_try_transmit: send(): error -5

oct. 25 16:41:06 LinuxHerve kernel: x86/cpu: VMX (outside TXT) disabled by BIOS

-- Reboot --

(etc.)

En dernier recours, est-il imaginable que je puisse créer un nouvel utilisateur (dont j'imagine qu'il hériterait des bonnes caractéristiques de root)?

Dernière modification par Herve5 (25-10-2020 17:00:27)

Herve5 · 25-10-2020 17:16:00

Bon, je viens de vérifier qu'en créant un nouvel utilisateur non root toutes ses fenêtres fonctionnent bien.
Y aurait-il une commande un peu concise qui me permettrait de rendre ce second user également propriétaire de tous les fichiers du home du premier, histoire ensuite de les rapatrier doucement?
Procéder ainsi m'ennuirait clairement beaucoup car l'ai des tonnes de trucs bien réglés, mais ça donne un horizon pas trop désespéré...
Sinon comment pourrais-je comparer l'état de ces deux users?

Dernière modification par Herve5 (25-10-2020 17:16:40)

anonyme · 25-10-2020 18:21:55

dans ton /home/tonuser les fichiers cachés peut être
le seul truc qui n'est pas commun avec ton "newuser"
rien a voir avec le noyau 5.9 et le driver nvidia
peut être ouvrir un autre fil pour ce souci ?

car l'ai des tonnes de trucs bien réglés,

 

jusqu' a perdre le bureau ?

Herve5 · 25-10-2020 18:34:49

anonyme a écrit :

jusqu' a perdre le bureau ? tongue

mais je jure que ça s'est produit précisément lors du passage au 5.9 (dont je comprends qu'il est incompatible avec ma carte NVidia)....
Ce que je n'ai pas vu venir c'est qu'apparemment en revenant au 5.8 les impact sur mon /home n'ont pas été inversés...
Je vais basculer sur user2 et tenter de comparer fichier à fichier les trucs cachés...
Ce qui m'énerve c'est que j'ai déjà remplacé mon /home/user1 par un backup qui clairement marchait (il y a quelques jours), et que malgré ça rien n'est amélioré... donc en plus je suis pessimiste...
En outre en lisant le man de chmod je comprends que chaque fichier n'a qu'un utilisateur et un seul, pas deux, donc je ne peux pas vraiment "commonaliser" mes énormes bases de données de livres, de photos etc.
Est-ce que le fait d'ajouter user2 dans le groupe user1 va lui donner accès?
Est-ce que je peux ajuster ce groupe pour que tous ses membres, par exemple, aient tous les accès sur les fichiers du groupe?
Merci dans tous les cas!
Je commence à comparer les dossiers home et la seule chose qui semble modifiée récemment ce sont des fichiers nommés .pEp_management.db... qui semblent correspondre au cryptage des mails, donc rien à voir avec les fenêtres... Faut que je creuse plus...
Que seraient les préférences de l'afficheur de fenêtres?

Dernière modification par Herve5 (25-10-2020 18:57:55)

Herve5 · 26-10-2020 18:55:38

Je reviens ici pour clore, bien que ce soit sans vraiment beaucoup d'information, ni plus vraiment en rapport avec le titre initial...
En bref :
- passer au noyau 5.9 avec une carte nvidia a planté mon affichage
- je suis revenu en 5.8 en attendant que nvidia ajuste ses drivers, mais l'affichage user est resté planté
- j'ai mis de côté tous les fichiers cachés de mon répertoire home/user, ce qui a restitué le bon fonctionnement des fenêtres et du bureau
- j'ai ensuite réinstallé ces fichiers par paquets, et au final j'ai retrouvé tous mes réglages, mais il y a eu tellement de décisions de remplacement ou non à prendre que je ne sais plus lequel était le fautif... Mais cette méthode a été efficace en tout cas.

Herve5 · 27-10-2020 13:14:37

vv222 a écrit :

Gaffe par contre si tu choisis de rester sur le noyau 5.8 : celui-ci n'est plus maintenu chez Debian, donc tu n'en recevras aucune mise-à-jour en cas de faille de sécurité.

en même temps, comme on dit, je note que dans l'annonce triomphale de la nouvelle version d'Ubuntu*, ils viennent, eux, de... "passer au noyau 5.8"... Que je suis content d'être chez Debian, en amont!

(*) https://lwn.net/Articles/834977/rss

vv222 · 27-10-2020 13:45:35

Gaffe aux conclusions trop rapides

Si Ubuntu fournit une version 5.8 du noyau, ils la maintiennent très probablement, au moins sur les points de sécurité.

Après c’est certain que si tu veux rester "à la pointe", rien ne vaut une bonne Debian Sid

Herve5 · 03-11-2020 18:38:51

vv222 a écrit :

Je confirme que les pilotes propriétaires nVIDIA semblent incompatibles avec la version 5.9 du noyau Linux : NVIDIA Driver not yet supported for Linux Kernel 5.9+

En gros tu as pour l'instant le choix entre utiliser le pilote libre nouveau, ou rester sur le noyau 5.8.

Rebonjour!
Je vois ce soir que Nvidia vient de publier une énorme liste de mise à jour de ses pilotes dans le repo testing : quelqu'un a-t-il vérifié qu'elle résoud l'incompatibilité avec le noyau 5.9?
(car l'annonce dans la change list est assez cryptique : "improved compatibility with recent kernels", sans plus...)
Merci!
Hervé
qui nononon ne veut pas recommencer juste pour le plaisir ;-)
P. S. en outre, comme apparemment j'ai dégagé le package de mise à jour du noyau de façon un peu trop musclée, il n'apparaît plus dans ma liste des disponibles : je ne sais même pas comment le réinstaller!!

Dernière modification par Herve5 (03-11-2020 18:41:08)

vv222 · 03-11-2020 19:47:21

Herve5 a écrit :

Je vois ce soir que Nvidia vient de publier une énorme liste de mise à jour de ses pilotes dans le repo testing : quelqu'un a-t-il vérifié qu'elle résoud l'incompatibilité avec le noyau 5.9?

Pas moi, je n’utilise pas le pilote non-libre nvidia

---

Herve5 a écrit :

P. S. en outre, comme apparemment j'ai dégagé le package de mise à jour du noyau de façon un peu trop musclée, il n'apparaît plus dans ma liste des disponibles : je ne sais même pas comment le réinstaller!!

Normalement, quoi que puisse te dire Synaptic ou autre gestionnaire de paquets, tu pourras toujours installer le dernier noyau avec :

apt-get install linux-image-amd64

Herve5 · 04-11-2020 08:44:55

vv222 a écrit :

Pas moi, je n’utilise pas le pilote non-libre nvidia

Merci vv222!
De fait je n'ai installé ces pilotes que pour être sûr que mes logiciels de traitement photo utilisent toutes les capacités de la carte NVidia (j'avais choisi une carte graphique externe exprès pour ça).
J'aimerais bien faire une comparaison précise entre free et non-free, sur telle série de traitements identiques, mais l'étendue de la manip à effectuer dans les deux sens m'effraie un peu...

Dernière modification par Herve5 (04-11-2020 08:45:37)

taureau89_9 · 04-11-2020 09:28:22

Bonjour.

Il est arrivé ce matin une nouvelle version de nvidia-driver, la 450.80.02-1 .
Elle semble capable de résoudre l'incompatibilité avec le noyau 5.9 ?

J'ai en effet essayé de réinstaller linux-headers-5.9.0-1-common et linux-headers-5.9.0-amd64 et à priori c'est passé :

Sélection du paquet linux-headers-5.9.0-1-common précédemment désélectionné.

(Lecture de la base de données... 251594 fichiers et répertoires déjà installés.)

Préparation du dépaquetage de .../linux-headers-5.9.0-1-common_5.9.1-1_all.deb ...

Dépaquetage de linux-headers-5.9.0-1-common (5.9.1-1) ...

Sélection du paquet linux-headers-5.9.0-1-amd64 précédemment désélectionné.

Préparation du dépaquetage de .../linux-headers-5.9.0-1-amd64_5.9.1-1_amd64.deb ...

Dépaquetage de linux-headers-5.9.0-1-amd64 (5.9.1-1) ...

Sélection du paquet linux-headers-amd64 précédemment désélectionné.

Préparation du dépaquetage de .../linux-headers-amd64_5.9.1-1_amd64.deb ...

Dépaquetage de linux-headers-amd64 (5.9.1-1) ...

Paramétrage de linux-headers-5.9.0-1-common (5.9.1-1) ...

Paramétrage de linux-headers-5.9.0-1-amd64 (5.9.1-1) ...

/etc/kernel/header_postinst.d/dkms:

dkms: running auto installation service for kernel 5.9.0-1-amd64:

Kernel preparation unnecessary for this kernel.  Skipping...

applying patch kernel-5.7.0-set-memory-array.patch...patching file conftest.sh

applying patch use-kbuild-compiler.patch...patching file Makefile

applying patch use-kbuild-flags.patch...patching file Kbuild

patching file nvidia/nvidia.Kbuild

patching file Makefile

patching file nvidia-modeset/nvidia-modeset.Kbuild

applying patch use-kbuild-gcc-plugins.patch...patching file Kbuild

applying patch conftest-verbose.patch...patching file Kbuild

applying patch cc_version_check-gcc5.patch...patching file conftest.sh

applying patch nvidia-use-ARCH.o_binary.patch...patching file nvidia/nvidia.Kbuild

applying patch nvidia-modeset-use-ARCH.o_binary.patch...patching file nvidia-modeset/nvidia-modeset.Kbuild

applying patch conftest-prefer-arch-headers.patch...patching file conftest.sh

Building module:

cleaning build area...

unset ARCH; env NV_VERBOSE=1 make -j8 modules KERNEL_UNAME=5.9.0-1-amd64...............

cleaning build area...

DKMS: build completed.

nvidia-current.ko:

Running module version sanity check.

 - Original module

   - No original module exists within this kernel

 - Installation

   - Installing to /lib/modules/5.9.0-1-amd64/updates/dkms/

nvidia-current-modeset.ko:

Running module version sanity check.

 - Original module

   - No original module exists within this kernel

 - Installation

   - Installing to /lib/modules/5.9.0-1-amd64/updates/dkms/

nvidia-current-drm.ko:

Running module version sanity check.

 - Original module

   - No original module exists within this kernel

 - Installation

   - Installing to /lib/modules/5.9.0-1-amd64/updates/dkms/

nvidia-current-uvm.ko:

Running module version sanity check.

 - Original module

   - No original module exists within this kernel

 - Installation

   - Installing to /lib/modules/5.9.0-1-amd64/updates/dkms/

depmod...

DKMS: install completed.

.

Paramétrage de linux-headers-amd64 (5.9.1-1) ...

anonyme · 04-11-2020 13:04:26

@taureau89_9

oui ça fonctionne , j'ai testé celui d' expérimental c'était correct
pas testé depuis mais contourné le souci en passant a buster (stable)
je suppose que tu n'utilise pas cuda ?

@Herve5
pour le noyau il te suffit de remettre les 2 méta paquet

apt-get --reinstall install linux-image-amd64 linux-headers-amd64

 

et un update

apt update

 

et tu dois retrouver le dernier noyau

idem si tu n'utilise pas cuda c'est plus simple

pour basculer de nouveau a nonfree pour nvidia et vice versa c'est assez simple.
mais tu va être déçu par nouveau
ps: j'ai eu des erreurs avec une GTX750 et pas avec une GTX1060 3Go avec nouveau au démarrage
AMD reste quand même mieux en driver libre

sauf si tu a besoin d une prise en charge sérieuse de OpenCL ou Cuda vaut mieux rester en propriétaire

taureau89_9 · 04-11-2020 14:03:06

anonyme a écrit :

@taureau89_9
oui ça fonctionne , j'ai testé celui d' expérimental c'était correct
pas testé depuis mais contourné le souci en passant a buster (stable)
je suppose que tu n'utilise pas cuda ?

Non, je n'utilise pas cuda.
Ceci dit j'avais vu qu'il y avait un autre driver en experimental, mais je ne l'avais pas testé, j'ai attendu qu'une nouvelle version arrive en testing.

taureau89_9 · 04-11-2020 14:04:54

vv222 a écrit :

Pas moi, je n’utilise pas le pilote non-libre nvidia

Chacun ses choix.

Moi je n'utilise que le non libre nvidia.

Plus performant à mon sens pour mes besoins.

Herve5 · 04-11-2020 14:35:34

Merci à tous de ces infos bien utiles pour moi!
Je comprends que désormais seul manque le support OpenCL, qui hélas est utile à Darktable.
Or traiter rapidement mes photos sur Darktable est quasiment la seule raison pour laquelle je me suis fendu d'une carte graphique séparée!
Je vais donc attendre encore un peu avec le noyau 5.8, mais j'envisage quand même de faire les mises à jour Nvidia déjà disponibles.
J'imagine que ce n'est pas contradictoire sur 5.8?

vv222 · 04-11-2020 15:42:09

Je me suis permis de renommer cette discussion pour la rendre plus facile à retrouver par ceux qui auraient un problème similaire. Le nouveau titre est : « Incompatibilité du pilote non-libre nvidia avec Linux 5.9 ».

Debian-facile

#26 25-10-2020 15:19:09

Re : [Résolu] Incompatibilité du pilote non-libre nvidia avec Linux 5.9

#27 25-10-2020 15:35:16

Re : [Résolu] Incompatibilité du pilote non-libre nvidia avec Linux 5.9

#28 25-10-2020 15:50:05

Re : [Résolu] Incompatibilité du pilote non-libre nvidia avec Linux 5.9

#29 25-10-2020 15:55:51

Re : [Résolu] Incompatibilité du pilote non-libre nvidia avec Linux 5.9

#30 25-10-2020 16:24:37

Re : [Résolu] Incompatibilité du pilote non-libre nvidia avec Linux 5.9

#31 25-10-2020 17:16:00

Re : [Résolu] Incompatibilité du pilote non-libre nvidia avec Linux 5.9

#32 25-10-2020 18:21:55

Re : [Résolu] Incompatibilité du pilote non-libre nvidia avec Linux 5.9

#33 25-10-2020 18:34:49

Re : [Résolu] Incompatibilité du pilote non-libre nvidia avec Linux 5.9

#34 26-10-2020 18:55:38

Re : [Résolu] Incompatibilité du pilote non-libre nvidia avec Linux 5.9

#35 27-10-2020 13:14:37

Re : [Résolu] Incompatibilité du pilote non-libre nvidia avec Linux 5.9

#36 27-10-2020 13:45:35

Re : [Résolu] Incompatibilité du pilote non-libre nvidia avec Linux 5.9

#37 03-11-2020 18:38:51

Re : [Résolu] Incompatibilité du pilote non-libre nvidia avec Linux 5.9

#38 03-11-2020 19:47:21

Re : [Résolu] Incompatibilité du pilote non-libre nvidia avec Linux 5.9

#39 04-11-2020 08:44:55

Re : [Résolu] Incompatibilité du pilote non-libre nvidia avec Linux 5.9

#40 04-11-2020 09:28:22

Re : [Résolu] Incompatibilité du pilote non-libre nvidia avec Linux 5.9

#41 04-11-2020 13:04:26

Re : [Résolu] Incompatibilité du pilote non-libre nvidia avec Linux 5.9

#42 04-11-2020 14:03:06

Re : [Résolu] Incompatibilité du pilote non-libre nvidia avec Linux 5.9

#43 04-11-2020 14:04:54

Re : [Résolu] Incompatibilité du pilote non-libre nvidia avec Linux 5.9

#44 04-11-2020 14:35:34

Re : [Résolu] Incompatibilité du pilote non-libre nvidia avec Linux 5.9

#45 04-11-2020 15:42:09

Re : [Résolu] Incompatibilité du pilote non-libre nvidia avec Linux 5.9

Pied de page des forums