Nvidia et la sauvagerie

Les blobs sont sur la plage

Si vous avez une carte video Nvidia dans votre PC, voire même un chipset de la même marque, vous utilisez forcément le driver proprio. À part bien sûr les afficionados de la 2D avec Nouveau.

C'est comme ça. Et si vous n'êtes pas d'accord avec ce qui précède, vous tournez avec un chipset Intel ou vous attendez comme le Messie la venue d'un driver open-source correct pour votre ATI (AMD aura probablement déposé le bilan avant ce jour lointain, mais splendide).


Mais pourquoi de la sauvagerie ?

Vous êtes un adepte des kernel customs.

La sauvagerie n'est pas là, le kernel custom n'a rien de mauvais en soit. C'est même une nécessité pour le support de TuxOnIce (aka «l'hibernation qui fonctionne») ou encore les drivers critiques dans le noyau (comme le RAID par exemple, au lieu d'un chargement via une image des modules placée dans un ramdisk au boot).

Cependant, qui dit kernel custom, dit également fin du support Nvidia par votre distribution.

Vous pourriez bien sûr utiliser un des affreux noyaux disponibles dans AUR, mais soyons sérieux cinq minutes. À part vous faire perdre votre temps, ceux-ci ne servent pas à grand chose, tant il vrai que d'un cas qui se veut général, ils n'arriveront jamais à vos particularités.


Haine vidia

Ne me cachez rien. Vous vous êtes retrouvés à installer les drivers Nvidia directement à partir d'une archive chargée de leur site.

Et de ce choix douteux (ne nous voilons pas la face) est né un insurmontable chaos rampant qui explose maintenant à la face de notre innocence perdue.

Pour Arch, en ce début d'année 2013, le diagnostic est simple. Vous souffrez de ces problèmes si vous avez encore des fichiers dans /usr/lib64 qui est censé être vide.


$~ ls /usr/lib64

libcuda.so            libnvidia-cfg.so.310.19       libOpenCL.so
libcuda.so.1          libnvidia-compiler.so.310.19  libOpenCL.so.1
libcuda.so.310.19     libnvidia-encode.so           libOpenCL.so.1.0
libGL.la              libnvidia-encode.so.1         libOpenCL.so.1.0.0
libGL.so              libnvidia-encode.so.310.19    libvdpau_nvidia.so
libGL.so.1            libnvidia-glcore.so.310.19    libvdpau.so
libGL.so.310.19       libnvidia-ml.so               libvdpau.so.1
libnvcuvid.so         libnvidia-ml.so.1             libvdpau.so.310.19
libnvcuvid.so.1       libnvidia-ml.so.310.19        libvdpau_trace.so
libnvcuvid.so.310.19  libnvidia-opencl.so.1         tls
libnvidia-cfg.so      libnvidia-opencl.so.310.19    vdpau
libnvidia-cfg.so.1    libnvidia-tls.so.310.19


Une vérification rapide confirme qu'il y a quelque chose de pourri au royaume des paquets.


~$ for i in /usr/lib64/lib*; do pacman -Qo "$i"; done
error: No package owns /usr/lib64/libcuda.so
error: No package owns /usr/lib64/libcuda.so.1
error: No package owns /usr/lib64/libcuda.so.310.19
error: No package owns /usr/lib64/libGL.la
error: No package owns /usr/lib64/libGL.so
error: No package owns /usr/lib64/libGL.so.1
error: No package owns /usr/lib64/libGL.so.310.19
error: No package owns /usr/lib64/libnvcuvid.so
error: No package owns /usr/lib64/libnvcuvid.so.1
error: No package owns /usr/lib64/libnvcuvid.so.310.19
 (...)
error: No package owns /usr/lib64/libvdpau.so.310.19
error: No package owns /usr/lib64/libvdpau_trace.so

Cette vérification sommaire met en évidence l'installation sauvage du driver Nvidia.

Outre le fait que ce n'est pas propre (et un driver proprio, c'est propre peut-être ? Ipso facto on s'en tape), ceci peut tuer votre Arch, ce qui est déjà plus gênant.

Exagération ? Pas de bol ?

Pas de bol: la présence de /usr/lib64, un reliquat d'Arch où vous l'avez compris ne subsiste que votre installation barbare de Nvidia, va empêcher l'installation du nouveau filesystem Arch (paquet filesystem-2013.01-3).

/usr/lib64 est censé être un lien vers /usr/lib, et non pas un répertoire rempli de fichiers.

Si vous passez outre en forçant la mise à jour , qui est couplée avec un changement de libc (pour que la fête soit complète), vous flinguez votre Arch.

Pour remédier à cela, nous allons faire le ménage, qui passe notamment par la préparation d'un paquet Nvidia format distrib, adapté au kernel customisé.



Préparer un vrai paquet Nvidia

Lancez la commande abs pour mettre à jour la liste des PKGBUILD.

Copiez /var/abs/extra/nvidia/ à un endroit où vous allez préparer le paquet.

Vous allez devoir modifier les fichiers PKGBUILD et nvidia.install.

Vous aurez besoin de votre version de noyau, obtenue avec uname -r


~/abs/nvidia$ uname -r
3.6.0+


nvidia.install

Dans nvidia.install, remplacez la valeur de EXTRAMODULES avec la chaine obtenue avec uname -r

Par exemple:

  • Valeur originale: EXTRAMODULES='extramodules-3.7-ARCH'
  • Valeur après remplacement: EXTRAMODULES='3.6.0+'


PKGBUILD

Remplacer la valeur de _extramodules avec la chaine obtenue par uname -r

Il va également surement falloir éditer les dépendances. Je n'ai laissé que ceci pour depends:


depends=()                                                                  
#makedepends=('linux-headers>=3.7' 'linux-headers<3.8')

C'est à dire rien. Les entêtes sont plus sources d'ennuis qu'autre chose, vu que nous allons utiliser celles de notre kernel (ça peut servir comme indication si votre kernel est vraiment ancien et qu'il est temps de mettre à niveau).

Il y avait bien nvidia-utils, mais nous retrouverions dans la situation dite de la poule et de l'œuf: lequel installer en premier ? (il semble qu'il n'y a pas ou plus de dépendance vers le paquet nvidia lors de l'installation de nvidia-utils. Vous pourriez donc le laisser si vous avez peur d'oublier son installation subséquente.)


makepkg

Et voila, plus qu'à lancer makepkg.

Si vous suivez la doc Arch, la victoire semble à portée de main.

Seulement, la doc Arch est rédigée par d'incurables optimistes vivants dans une sorte de pays de Cocagne, où les plus beaux jambons sont toujours à portée de main. Dans notre monde imparfait, pour rester dans l'analogie, vous vous trouvez au sommet du mat, prêt à vous saisir de la plus belle pièce, quand soudain vous vous mettez à glisser inexorablement tandis que vos bras battent frénétiquement et stupidement l'air.

Adieu veau, vache, jambon et paquet Arch.

Mais ce n'est pas grave, nous avons l'habitude, et ce n'est que partie remise. Voyons voir…


==> Starting build()...
cat: /usr/lib/modules/3.6.0+/version: No such file or directory
==> ERROR: A failure occurred in build().
    Aborting...

Ce couillon de makepkg cherche un fichier nommé version qui n'existe pas.

Voyons voir avec un noyau Arch officiel ce qu'il est censé y trouver…


/usr/lib/modules$ find -name "version"
./extramodules-3.6-ARCH/version
/usr/lib/modules$ cat extramodules-3.6-ARCH/version 
3.6.11-1-ARCH

Ok. Donc uname -r , one more time. Quelque chose m'échappe dans cette façon multiple d'acquérir la même information.

Je pourrais modifier les fichiers de config de makepkg, mais autant passer root et faire (dans /usr/lib/modules) …


/usr/lib/modules# uname -r >$(uname -r)/version

Afin de lui donner ce qu'il désire.

Voila, nous relançons makepkg et cette fois-ci, nous obtenons un beau paquet nommé nvidia-313.18-2-x86_64.pkg.tar.xz .



Installation

Module kernel.

Je vous quitte un instant, le temps de passer sous une console pour installer mon paquet tout frais démoulé.

N'oubliez pas que pour vos paquets hors circuit officiel, il faut utiliser -U et non pas le traditionnel -S.


~# pacman -U /home/vousmême/abs/nvidia/nvidia-313.18-2-x86_64.pkg.tar.xz

Et voilà.

Vous aurez peut-être besoin d'enlever les anciens paquets relatifs à nvidia, selon la façon dont vous massacrâtes votre installation.


La suite de façon classique

Vous pouvez continuer de façon conventionnelle avec les paquets officiels Arch.

Comme nous avons utilisé une base ABS pour le driver kernel, ceux-ci seront à niveau.


~# pacman -S vdpau

~# pacman -S nvidia-utils

ATTENTION ce n'est pas fini! Depuis peu (j'écris ceci en avril 2013), les libs de nvidia-utils sont installées dans /usr/lib/nvidia. Vos programmes ne vont donc plus les trouver.

Résistez à l'envie d'ajouter une entrée dans /etc/ld.so.conf, et installez plutôt le nouveau paquet : nvidia-libgl. Il contient des symlinks vers la libGL ainsi que la libglx.

Il sera peut-être nécessaire de relancer X ensuite.

nvidia-utils n'installe que la partie 64 bits des utilitaires (libGL et compagnie).

Pour la partie 32 bits, il vous faut le repo multilib.

Si ce n'est pas déjà fait, décommentez ou ajoutez les lignes suivantes dans /etc/pacman.conf.


[multilib]
Include = /etc/pacman.d/mirrorlist

Et vous pouvez dès lors procéder avec:


pacman -S lib32-nvidia-utils

À vous les jeux proprios compilés pour la couche d'émulation 32 bits d'Ubuntu. Vous n'avez pas honte ? Mettons que je n'ai rien vu (j'ai intégré ceci dans la doc uniquement par souci d'exhaustivité).



Un peu de nettoyage

Si au cours des installations des paquets le linker (ld) râle à propos de bibliothèques dupliquées, il s'agit des scories laissées par l'installation sauvage des drivers.

Dans ce cas, il faut noter les noms, et passer un coup de pacman -Qo pour trouver quel fichier n'est pas rattaché à un paquet. Pour tous ces fichiers orphelins, une seule solution: rm.

Normalement, vous devriez vous retrouver à effacer l'intégralité de /usr/lib64. À ne pas confondre avec /lib64 qui est aux dernières nouvelles un alias vers /usr/lib.Tout comme /usr/lib64 est un alias vers /usr/lib. (pour faire court, toutes les libs sont maintenant dans /usr/lib).

Attention à ne rien effacer sans vérifier auparavant que le fichier ne vient pas d'un paquet Arch. Il est vrai que tant que vous vous limitez aux fichiers Nvidia, vous ne risquez pas grand chose (à part lire ce blog depuis lynx à votre prochain reboot).


IgnorePKG dans pacman.conf

Pour ne pas avoir à recommencer la manipulation à chaque changement mise à jour globale (pacman -Su), vous pouvez mettre ces paquets en ignore dans pacman.conf.


IgnorePkg   = nvidia nvidia-utils lib32-nvidia-utils 


Vu de loin, cela semble très bien. En effet, un pacman -Su va ignorer toute la partie nvidia, et vous resterez avec vos vieux drivers (de toutes façons, à part avec une carte très récente, il ne faut pas rêver. Au bout d'un an, plus rien n'est ajouté pour votre modèle dans le gros blob nvidia).

Attention cependant si vous compilez un nouveau noyau perso, et qu'entre temps un nouveau nvidia-utils est sorti.

En effet, dans ce cas vous allez réinstaller votre paquet nvidia. Mais le pacman -S nvidia-utils va ramener une version plus récente du driver, et vous allez vous retrouver désynchronisé par rapport à votre désormais obsolète driver kernel.

Vous pouvez tout mettre à niveau en repackageant un nouveau driver nvidia correspondant au niveau de version des nvidia-utils.

Ou encore, vous pouvez réinstaller les anciens paquets (que vous trouverez mis en cache dans /var/cache/pacman/pkg/). Vous pouvez installer ces paquets de la même façon que votre paquet personnel, c'est à dire en utilisant pacman -U en lieu et place de pacman -S.



Le calme est revenu sur l'ensemble de la distrib

Fini la gruikerie.

Là j'avoue, je l'avais un peu cherché quand même.

«Il faut savoir reconnaître ses torts afin de taper plus fort sur ceux qui ne le font pas.» (A. Einstein)

(ou était-ce Socrate ?)

(peut-être Napoléon…)