Pour résoudre un souci sur mon ordi, je m’installe un 2.6.29 via apt-get.
Je démarre sans souci. Je dois alors réinstaller les pilotes NVIDIA. Et là, c’est le drame (!)
Perso, j’utilise le .run du constructeur.
A l’install, il m’est indiqué qu’un chemin est incorrect. J’ai oublié le PATH entier, mais le fichier incriminé est “kernel.h”. Je vais dans le dossier indiqué, est effectivement, point de kernel.h
Lorsque je me rend dans le dossier équivalent pour un 2.6.26, j’y trouve un grand nombre de fichiers, qui donc n’existent pas pour le 2.6.29
Avec un 2.6.26, ça s’installait très bien.
Ce que je voudrais comprendre, c’est d’où vient le problème ? Pourquoi les fichiers recherchés par le .run n’existent pas ? Est-ce un souci du noyau ou du .run ?
J’ai également essayé la méthode de debianhadic (voir T&A) mais idem, ça ne fonctionne pas.
Pour le moment il y a deux solutions, soit tu downgrade avec l’ancienne version des pilotes nvidia (ceux de Lenny je crois) et ça marche, soit tu prends le noyau 2.6.29 de sidux qui devrait fonctionner.
Le .run de toute façon est à éviter.
N’ayant vu de réponse concrète à cette question posée maintes fois, je la réitère : pourquoi il faut éviter le .run ?
Perso, je l’ai utilisé et j’ai pas eu de souci. Ferais-je partie des exceptions ?
Pour l’utilisation du 2.6.29 de sidux, je suis pas chaud. Donc j’opterai pour ta seconde option, mais je l’ai pas bien comprise
Que veux tu dire ? Perso, j’ai déjà downgradé 2.6.29 -> 2.6.26 et remis les pilotes nvidia. Est-ce ce que tu proposes ?
la reponse a été donné maintes et maintes fois
le run n’est pas un programme debian et le systeme de paquetage de debian n’est pas informé de son utilisation.
sans aller jusqu’a utiliser le noyau sidux ,tu peux utiliser le script sidux d’installation du pilote nvidia: sgfxi
sur lenny quand il n’y avait pas encore le paquet pour nvidia c’est ce que j’utilisais et ça fonctionnait très bien
[quote=“debianhadic”]Non tu gardes le 2.6.29, mais tu installes via aptitude les anciennes versions :
[code]
m-a prepare
aptitude install nvidia-kernel-source=180.29-1
m-a a-i -i nvidia-kernel-source=180.29-1
[/code][/quote]
Salut
Lorsque tu parles des anciennes versions, ce n’est pas plutôt la version 173.14.09-5 au lieu de la 180.29-1 ?
Lorsque je tape m-a a-i -i nvidia-kernel-source=180.29-1 (ou 173.14.09-5) j’obtiens un beau message qui me demande qu’est-ce que nvidia-kernel-source=180.29-1 ? Alors qu’est-ce qui ne fonctionne pas ici ?
[quote=“martin_mtl”][quote=“debianhadic”]Non tu gardes le 2.6.29, mais tu installes via aptitude les anciennes versions :
[code]
m-a prepare
aptitude install nvidia-kernel-source=180.29-1
m-a a-i -i nvidia-kernel-source=180.29-1
[/code][/quote]
Salut
Lorsque tu parles des anciennes versions, ce n’est pas plutôt la version 173.14.09-5 au lieu de la 180.29-1 ?
Lorsque je tape m-a a-i -i nvidia-kernel-source=180.29-1 (ou 173.14.09-5) j’obtiens un beau message qui me demande qu’est-ce que nvidia-kernel-source=180.29-1 ? Alors qu’est-ce qui ne fonctionne pas ici ?[/quote]
j’ai le même souci. Les 180.29-1 sont les plus récents semble-t-il, contrairement aux 173*. Le message d’erreur avec module assistant vient du fait qu’il ne reconnait pas la syntaxe utilisée j’imagine (lui précisant quel version prendre, lui il croit que on veut installer le module "nvidia-kernel-source=180.29-1 ".). Cependant, je ne sais pas comment lui préciser laquelle utiliser…
Bon, j’ai plus ou moins les mêmes erreurs que tout le monde :
m-a a-i -i nvidia-kernel-source
...
make[3]: entrant dans le répertoire « /usr/src/linux-headers-2.6.29-1-686-bigmem »
/usr/src/linux-headers-2.6.29-1-common/arch/x86/Makefile:41: /usr/src/linux-headers-2.6.29-1-common/arch/x86/Makefile_32.cpu: Aucun fichier ou répertoire de ce type
make[5]: *** Pas de règle pour fabriquer la cible « /usr/src/linux-headers-2.6.29-1-common/arch/x86/Makefile_32.cpu ». Arrêt.
make[4]: *** [sub-make] Erreur 2
make[3]: *** [all] Erreur 2
make[3]: quittant le répertoire « /usr/src/linux-headers-2.6.29-1-686-bigmem »
NVIDIA: left KBUILD.
nvidia.ko failed to build!
make[2]: *** [module] Erreur 1
make[2]: quittant le répertoire « /usr/src/modules/nvidia-kernel »
make[1]: *** [build-stamp] Erreur 2
make[1]: quittant le répertoire « /usr/src/modules/nvidia-kernel »
make: *** [kdist_image] Erreur 2
BUILD FAILED!
See /var/cache/modass/nvidia-kernel-source.buildlog.2.6.29-1-686-bigmem.1238673127 for details.
La construction a échoué. Appuyez sur Entrée pour continuer...
Effectivement, dans /usr/src/linux-headers-2.6.29-1-common/arch/x86/ il n’y a pas de Makefile_32.cpu
ls /usr/src/linux-headers-2.6.29-1-common/arch/x86
include Makefile
J’ai l’impression qu’il manque pas mal de choses dans les paquets du 2.6.29 (cf mon premier message)…
J’ai eu le même problème pour compiler le module de virtualbox et j’ai laissé l’astuce utilisée dans un autre fils qui consiste à copier le fichier manquant depuis celui de linux-headers-2.6.26
la reponse a été donné maintes et maintes fois
le run n’est pas un programme debian et le systeme de paquetage de debian n’est pas informé de son utilisation.
sans aller jusqu’a utiliser le noyau sidux ,tu peux utiliser le script sidux d’installation du pilote nvidia: sgfxi
sur lenny quand il n’y avait pas encore le paquet pour nvidia c’est ce que j’utilisais et ça fonctionnait très bien[/quote]
J’ai cherche sur Google, j’ai regarde ce fil, ce fil, ce fil, ce fil, ce fil, ce fil, ce fil, ce fil.
Bref, les seules explications claires concernant le “pourquoi il ne faut pas utiliser le .run” que j’ai trouve sont celle que je viens de citer en debut de post et :
Sinon j’ai surtout trouve des :
[quote]le .run de Nvidia c’est le mal[/quote] sans plus d’explications.
Donc considerant que la seule raison qui puisse poser probleme avec le .run a priori est un eventuel probleme de mise a jour, et que le noyau que j’utilise est un noyau 2.6.29 que j’ai compile avec les patchs debian et temps reel d’Ingo Molnar, et pour lequel il n’y aura donc pas de mise a jour, l’usage du .run pose t-il vraiment un probleme dans mon cas?
En fait, sauf erreur de ma part, je peux utiliser module-assistant pour les noyaux generique Debian pour lesquels il y a des mises a jour et le .run pour les noyaux temps reels compiles par mes soins si module-assistant refuse de fonctionner avec, non?
Sinon, apres m’etre fait remonte les bretelles a tres juste titre par Sebiseb sur un autre fil (sans compter qu’il faut aussi que je fasse attention a mon penchant pour l’humour ironique qui passe mal sur le net surtout sans smileys, encore desole), je me suis un peu penche sur sgfxi. Or, a moins que je n’ai rien compris du tout, j’ai l’impression que ce script installe les drivers nvidia a partir… du .run, non? Entous cas il les telecharge. Donc si le .run, quoi qu’il arrive n’est pas bon, en quoi sgfxi est-il mieux?
Merci de vos eclaircicements.
edit : En continuant mes recherches je viens de tomber la dessus :
Evidement, je n’avais pas pense a la mise a jour de X… qui elle pourrait tres bien concerner mon noyau… mais ceci dit mes questions restent toujours valables.
[quote]j’ai l’impression que ce script installe les drivers nvidia a partir… du .run, non? Entous cas il les telecharge. Donc si le .run, quoi qu’il arrive n’est pas bon, en quoi sgfxi est-il mieux?
[/quote]
quelque soit la methode , même module-assistant, le pilote est toujours issu de chez nvidia puisque le code est fermé. Je ne sais pas ce que fait exactement sgfxi , peut-être n’est-il pas mieux.
mais pour moi il est simple: en cas de plantage suite a une maj il suffit juste de refaire# sgfxi
[quote=“misaine”][quote]j’ai l’impression que ce script installe les drivers nvidia a partir… du .run, non? Entous cas il les telecharge. Donc si le .run, quoi qu’il arrive n’est pas bon, en quoi sgfxi est-il mieux?
[/quote]
quelque soit la methode , même module-assistant, le pilote est toujours issu de chez nvidia puisque le code est fermé. Je ne sais pas ce que fait exactement sgfxi , peut-être n’est-il pas mieux.
mais pour moi il est simple: en cas de plantage suite a une maj il suffit juste de refaire# sgfxi
edit il ne fonctionne pas avec le 2.6.29[/quote]
Je viens de l’essayer, il fonctionne avec mon noyau 2.6.29 temps reel sur ma Debian de test squeeze/sid.
C’est simple, l’utilisation du .run comme de tout programme installé suite à une compilation sans utiliser checkinstall, ne renseigne pas le système sur son existence, donc celui-ci ne peut pas gérer les dépendances qui pourraient entrer en conflit avec ces programmes, hors la stabilité de ton système est à ce prix, d’autre distribution Linux ne gère pas les dépendances à ce point, mais Debian a gagné ses lettre de noblesse grâce à sa stabilité.
il ne fonctionne pas avec le 2.6.29