Dkms

Support Debian
#1

Bonsoir à tous,

Suite à une intéressante discussion sur le site de FlightGear, et au reste depuis un certain temps déjà, je me pose des questions sur DKMS, qui a sans doute des avantages et des inconvénients vis-à-vis de l’utilisation de sa carte graphique.

De toute évidence, sur les quatre modes d’installation du driver Nvidia (DKMS, module-assistant seul, SGFXI, .run) les plus couramment recensés, les trois derniers ignorent DKMS et d’ailleurs installent un nvidia-kernel quelque chose (pas le common, ni le source, requis par tous les procédés, un autre encore), enfin peu importe ici.

DKMS, comme son nom l’indique, a quelque chose de particulier.

Tout cela pour dire que, les quatre méthodes d’installation rappelées plus haut n’aboutissant pas exactement au même résultat, j’aimerais bien en savoir plus sur, justement, cette différence, et bien sûr à l’utilisation.

Qu’apporte exactement DKMS ? En termes d’exploitation de la carte, avec toutes les conséquences (dégagement de chaleur, ou au contraire stabilité) qui peuvent venir à l’esprit.

Bon, je sais pas si mon affaire est très bien ficelée, mais si cela peut inspirer les habitués de la 3D et des simulateurs…

A+

Sergio

#2

Les 4 méthode ne changeront rien aux performances de ta cartes graphique les une par rapport aux autres, aller sauf peut-être pour le .run qui du coup te permettra d’avoir le tout dernier drivers à la mode avec les derniers correctifs et amélioration, donc pourquoi pas une amélioration sensible des perfs ( ou pas ).

C’est très simple, sans DKMS, à chaque mlise a jour ou changement de version du noyau -> Tu devra réinstaller une nouvelle fois ton drivers nvidia, ce qui n’est pas super pratique . . .

DKMS te permet tout simplement de conserver ton module nvidia fonctionnel même après un changement de noyau, ou mise à jour de celui-ci. ( la source du module est recompilé à chaque fois si je ne dit pas de connerie )

#3

[quote=“nokcy”]C’est très simple, sans DKMS, à chaque mlise a jour ou changement de version du noyau -> Tu devra réinstaller une nouvelle fois ton drivers nvidia, ce qui n’est pas super pratique . . .

DKMS te permet tout simplement de conserver ton module nvidia fonctionnel même après un changement de noyau, ou mise à jour de celui-ci. ( la source du module est recompilé à chaque fois si je ne dit pas de connerie )[/quote]
C’est tout à fait ça. J’utilise la version DKMS depuis qu’elle est disponible, et pfioooout plus de prises de têtes ou d’interventions manuelles lors des mises à jour du kernel ou du driver, tout est géré pendant l’installation des paquets et fonctionne nickel. :smiley:

#4

C’est le cas aussi avec sgfxi. La commande sgfxi -B permet même d’installer le driver béta du moment si il existe.

#5

Donc il faudrait laisser en permanence nvidia-kernel-source dans le /usr/src. En fait je l’ai enlevé immédiatement avoir installé le driver nvidia, il y a un mois, et depuis on a eu pas mal de mises à jour de linux-image. Seulement rien ne dit que ces linux-image concernaient la partie affichage. A aucune de ces mises à jour je n’ai planté X en rebootant, mais c’est peut-être un coup de chance.

(il n’y a absolument plus rien dans mon /usr/src, même pas les headers)

#6

Je n’ai plus le détail sur le process exacte qu’utilise dkms a chaque mise a jour, mais on peut supposer qu’il récupère les sources dont il à besoin et s’en débarasse une fois qu’il a fini ? Bref doit bien y avoir une page DKMS sur le wiki debian qui explique tout sa :slightly_smiling:

#7

À priori les sources à recompiler sont dans le paquet nvidia-kernel-dkms (qu’il faut bien évidemment laisser installé en permanence).
De toutes façons ce n’est pas bien lourd, sachant que la majeure partie du pilote est un blob binaire dont on n’a pas les sources.

$ aptitude search ~invidia i A glx-alternative-nvidia - allows the selection of NVIDIA as GLX prov i A libgl1-nvidia-alternatives - transition libGL.so* diversions to glx-alt i A libgl1-nvidia-alternatives-ia32 - simplifies replacing MESA libGL with GPU v i A libgl1-nvidia-glx - NVIDIA binary OpenGL libraries i libgl1-nvidia-glx-ia32 - NVIDIA binary OpenGL 32-bit libraries i A libglx-nvidia-alternatives - transition libgl.so diversions to glx-alte i A nvidia-alternative - allows the selection of NVIDIA as GLX prov i A nvidia-glx - NVIDIA metapackage i A nvidia-installer-cleanup - Cleanup after driver installation with the i A nvidia-kernel-common - NVIDIA binary kernel module support files i A nvidia-kernel-dkms - NVIDIA binary kernel module DKMS source i nvidia-settings - Tool for configuring the NVIDIA graphics d i A nvidia-support - NVIDIA binary graphics driver support file i A nvidia-vdpau-driver - NVIDIA vdpau driver i A xserver-xorg-video-nvidia - NVIDIA binary Xorg driver

#8

tout ce qui n’est pas officiel est evidament a éviter car le parcour d’un paquet pour devenir stable a une raison, dkms tien aussi compte des autre module a compiler sa ne ce limite pas qu’a la carte video ,ce qui est utiliser par dkms est lister dans le paquet on c’est donc ce qu’il fait.

Ensuite le .run est déconseillier et vu le nombre de post a ce sujet google est ton amis.
Pour le sgfxi encore une fois c’est pas officiel, Bien que je ne l’utilise pas je parie qu’il télécharge le .run et que du coup c est donc deconseillier …bref

il y a un wiki il ser a quelque chose :slightly_smiling:

Bref je pense que chaque methode a son pour et contre…
donc perso je fait:
tout ce qui est officiel d’abords dkms
le module assitant si sa coince …
et le run/sgfxi si vraiment sa coince … a éviter…

#9

Juste pour dire que sgfxi utilise le module-assistant tout comme dkms pourrais le faire.

A la rigueur après avoir utilisé sgfxi et de s’être assuré pour un novice que tous fonctionne nickel d’installer dkms et permet ainsi de pouvoir rester au sec :033

  • EDIT - :033
#10

Perso moi c’est dkms for ever xD Pas envie de me faire chier à chaque maj du noyau ( imagine le merdier en sid oO )

EDIT : Clochette j’ai pas bien compris ta phrase ( Go la ponctuation :stuck_out_tongue: ), avec sgfxi on peut installer dkms ?

#11

Bonjour

Je trouve DKMS bien pratique. A condition de surveiller un peu ce qui se passe lors d’un changement de noyau. Exemple, il y a quelques minutes :

[quote=“aptitude safe-upgrade”]…
Paramétrage de linux-image-3.0.0-2-amd64 (3.0.0-5) …
Running depmod.
Examining /etc/kernel/postinst.d.
run-parts: executing /etc/kernel/postinst.d/dkms 3.0.0-2-amd64 /boot/vmlinuz-3.0.0-2-amd64
Error! Your kernel headers for kernel 3.0.0-2-amd64 cannot be found.
Please install the linux-headers-3.0.0-2-amd64 package,
or use the --kernelsourcedir option to tell DKMS where it’s located
…[/quote]

#12

Et voilà, c’est un peu ce que j’attendais : cela veut dire qu’il faut en permanence dans le /usr/src d’une part les linux-headers (qui dès lors seront mis à jour, chaque fois, conjointement avec linux-image), d’autre part le nvidia-kernel-source puisqu’il va bel et bien s’agir d’une recompilation du driver Nvidia. Et ce n’est pas tout, lorsque l’on est avec un noyau 2.6, il faut non seulement que gcc-4.3 soit installé, mais encore réponde à la commande “gcc” par le biais d’une variable d’environnement.

Sinon, commme je suis moi avec un /usr/src vide comme un chameau dans le désert, à la première mise à jour du noyau qui concernera l’affichage graphique, X ne montera plus au reboot et il faudra que je réinstalle le driver Nvidia comme si je n’avais pas DKMS.

#13

[quote=“panthere”]tout ce qui n’est pas officiel est evidament a éviter car le parcour d’un paquet pour devenir stable a une raison, dkms tien aussi compte des autre module a compiler sa ne ce limite pas qu’a la carte video ,ce qui est utiliser par dkms est lister dans le paquet on c’est donc ce qu’il fait.

Ensuite le .run est déconseillier et vu le nombre de post a ce sujet google est ton amis.
Pour le sgfxi encore une fois c’est pas officiel, Bien que je ne l’utilise pas je parie qu’il télécharge le .run et que du coup c est donc deconseillier …bref

il y a un wiki il ser a quelque chose :slightly_smiling:

Bref je pense que chaque methode a son pour et contre…
donc perso je fait:
tout ce qui est officiel d’abords dkms
le module assitant si sa coince …
et le run/sgfxi si vraiment sa coince … a éviter…[/quote]

Je ne fais pas du lobbying pour sgfxi et je ne force personne à l’utiliser, mais juste pour mettre les choses au point une fois de plus. Quand tu installes le .run directement l’installation est “sale” dans le sens où APT n’est pas informé des librairies installées. sgfxi par contre compile le module avec module-assistant, à partir du .run certes, mais l’installation est propre. Donc le fait que sgfxi télécharge le .run n’est pas en soi un problème.
A ma connaissance, les paquets non-free des dépôts officiels contenant les drivers nvidia ne font pas autre chose.
Si je me trompe quelque part je serai très heureux de l’apprendre.

#14

[quote=“nokcy”]Perso moi c’est dkms for ever xD Pas envie de me faire chier à chaque maj du noyau ( imagine le merdier en sid oO )

EDIT : Clochette j’ai pas bien compris ta phrase ( Go la ponctuation] :stuck_out_tongue: ), avec sgfxi on peut installer dkms ?[/quote]

te loupe pas et utilise au maximum le français car moi je te raterai pas :005 :005 :005
As-tu été lire le petit wiki à propos de dkms ?

[quote=“Clochette”]
Juste pour dire que sgfxi utilise le module-assistant tout comme dkms pourrais le faire.

A la rigueur après avoir utilisé sgfxi et de s’être assuré pour un novice que tous fonctionne nickel d’installer dkms et permet ainsi de pouvoir rester au sec :033[/quote]

#15

Et voilà, c’est un peu ce que j’attendais : cela veut dire qu’il faut en permanence dans le /usr/src d’une part les linux-headers (qui dès lors seront mis à jour, chaque fois, conjointement avec linux-image), d’autre part le nvidia-kernel-source puisqu’il va bel et bien s’agir d’une recompilation du driver Nvidia. Et ce n’est pas tout, lorsque l’on est avec un noyau 2.6, il faut non seulement que gcc-4.3 soit installé, mais encore réponde à la commande “gcc” par le biais d’une variable d’environnement.

Sinon, commme je suis moi avec un /usr/src vide comme un chameau dans le désert, à la première mise à jour du noyau qui concernera l’affichage graphique, X ne montera plus au reboot et il faudra que je réinstalle le driver Nvidia comme si je n’avais pas DKMS.[/quote]
C’est sûr que c’est vachement plus pratique (et logique) de réinstaller toute la chaîne de compilation à chaque mise à jour du kernel ou des pilotes, puis de la supprimer à nouveau juste après… :smiley:
Il suffit que tu aies en plus par exemple VirtualBox (qui a besoin de compiler des modules du kernel lui aussi), et ça devient vite invivable.
Enfin, chacun ses méthodes et ses habitudes. :wink:

#16

Et le record du Monde, c’est qu’en ce moment il y a sur Wheezy et SID un “280.13really275”. Troublant, isn’t ?

Bon je ferme le thread, merci à tous, au moins j’ai compris en quoi consiste exactement DKMS.

#17

Pas quand on a suivi l’histoire : on a eu la version 280 pendant peu de temps, mais ils ont décidé de downgrader en 275 (apparemment à cause des soucis avec la nouvelle ABI Xorg).
Vu comment le système de paquets fonctionne, pour que le downgrade soit proposé aux utilisateurs il fallait déclarer une version de paquet “supérieure” à la 280.13, d’où la 280.13really275… :wink:

#18

[quote=“youki”]
Je ne fais pas du lobbying pour sgfxi et je ne force personne à l’utiliser, mais juste pour mettre les choses au point une fois de plus. Quand tu installes le .run directement l’installation est “sale” dans le sens où APT n’est pas informé des librairies installées. sgfxi par contre compile le module avec module-assistant, à partir du .run certes, mais l’installation est propre. Donc le fait que sgfxi télécharge le .run n’est pas en soi un problème.
A ma connaissance, les paquets non-free des dépôts officiels contenant les drivers nvidia ne font pas autre chose.
Si je me trompe quelque part je serai très heureux de l’apprendre.[/quote]

j’y voi vois pas très claire :017
pour ce que je sai du run: :unamused:
le *.run peux avoir des lib qui vont écraser ceux du systeme. de memoire le run lui meme passe aussi par module assitant
Toi tu dis le contraire parce que tu passe par module assitant, c est la que je ne croit pas trop a ton histoire ?
je voudrai donc bien savoir ou le listing des fichier ce trouve a partir du *.run installer avec module assistant ?
cat si apt est bien informer le listing devrai donc exister :think:

peux etre que ces fichier son déjà existant,et présent dans la base de apt-file ce que voudrai dire que des fichier pourrait être écraser.

#19

Effectivement, il peut m’arriver une sorte de voile lumineux, très rapide et aléatoire (toutes les quelques minutes), avec un 3D que j’utilise, Ayam3D, en déplaçant des points de courbes NURBS, mais non en agitant à la souris la scène complète. J’ai fait différents essais, et puis de toutes manières j’ai l’Xorg de Squeeze, là j’en suis sûr. Pour le moment je m’acharne sur les nvidia-settings, il semblerait qu’en ôtant le “allow flipping”, cela arrange mon affaire. Les Vblank aussI. De toutes manières, c’est pratiquement rien du tout.

#20

A ma connaissance non, le .run ne s’installe pas via module-assistant.

C’est pas moi qui passe par module-assistant, c’est sgfxi.

Pour le reste je ne peux pas chercher plus que ça parce que j’utilise Nouveau, mais je pense qu’en gros le script télécharge le .run de nvidia (comme je viens de le faire à l’instant sur le site de nvidia), le décompresse (comme je viens de le faire) :

Ce qui créé un dossier NVIDIA-Linux-x86_64-285.05.09 qui contient ceci :

~/NVIDIA-Linux-x86_64-285.05.09$ ls 32 libnvidia-cfg.so.285.05.09 LICENSE nvidia-settings.desktop glext.h libnvidia-compiler.so.285.05.09 makeself.sh nvidia-settings.png gl.h libnvidia-glcore.so.285.05.09 mkprecompiled nvidia-smi glxext.h libnvidia-ml.so.285.05.09 nvidia-bug-report.sh nvidia-smi.1.gz glx.h libnvidia-tls.so.285.05.09 NVIDIA_Changelog nvidia-xconfig html libnvidia-wfb.so.285.05.09 nvidia-debugdump nvidia-xconfig.1.gz kernel libOpenCL.so.1.0.0 nvidia_drv.so pkg-history.txt libcuda.so.285.05.09 libvdpau_nvidia.so.285.05.09 nvidia.icd README.txt libGL.la libvdpau.so.285.05.09 nvidia-installer tls libGL.so.285.05.09 libvdpau_trace.so.285.05.09 nvidia-installer.1.gz tls_test libglx.so.285.05.09 libXvMCNVIDIA.a nvidia-settings tls_test_dso.so libnvcuvid.so.285.05.09 libXvMCNVIDIA.so.285.05.09 nvidia-settings.1.gz

Je suppose que là dedans y’a tout ce qu’il faut pour compiler le module, comment ça exactement, je n’en sais pas plus. Mais nul doute que module-assistant est utilisé.

Par contre je pense que le .run ne fait qu’installer les librairies extraites là où il faut en les copiant/collant et écrasant celles qui existent déjà sans en informer le système.

Mais une fois de plus si quelqu’un plus doué que moi lis ces lignes et a la réponse, ça m’interesse. Ceci dit, sgfxi est un script libre tu peux le consulter et regarder ce qu’il fait exactement si tu en as le courage et les capacités, ce n’est pas mon cas.