Ecran noir après installation drivers proprio nvidia

Support Debian
#1

Bonjour,

je me demandais s’il était possible d’installer le driver Nvidia de Squeeze mais tout en étant en Wheezy?

Vous allez sûrement vous demander pourquoi je voudrais installer une version plus ancienne du driver nvidia, et bien c’est que j’ai un problème avec les versions récentes du driver: mon laptop (msi gx701) démarre parfaitement, le système se lance sans aucuns soucis mais après quelques minutes l’écran devient noir et je ne peux absolument rien faire, même les tty ne sont plus accessible.
Le plus étonnant c’est que j’ai ce problème aussi bien sous linux que sous windows! Est-ce lié au laptop? Est-ce lié à la carte graphique (GeForce 9600M GT)? Aucune idée, j’ai beau avoir cherchez sur le net, je n’ai rien trouvé qui puisse m’aider.

Donc voilà comme je sais que le driver 195.x fonctionne parfaitement sous windows, je me demandais s’il était possible de l’installez sous debian wheezy et comment?

#2

Il faut faire du “pinning”. C’est à dire, rajouter le dépôts squeeze et donner un priorité plus importante au(x) paquet(s) qui installe(nt) le driver version squeeze.
Je ne sais pas si ça peut marcher au niveau des conflits de versions.

Commence par rajouter cette ligne à ton fichier [mono]/etc/apt/sources.list[/mono]

Rajoutes ou crée le fichier [mono]/etc/apt/preferences[/mono] avec:

Package: nom_du_paquet Pin: release o=Debian,a=squeeze Pin-priority: 1001
Remplaces nom_du_paquet par le ou les paquets qui t’interesses. Normalement, un seul paquet suffit, celui qui entrainera les dépendances. Si tu veux forcer l’installation de plusieurs paquets, tu peux un entrée pour chacun d’eux ou utiliser une syntaxe du genre nvidia-driver-* (je connais pas le nom des paquets nvidia).
Je ne sais pas si le mot “squeeze” fonctionne essaie peut etre oldstable sinon.
Le nombre 1001 impose que l’installation de cette version sera absolument prioritaire sur les autres versions même plus récentes.

Ensuite # aptitude update $ apt-cache policy nom_du_paquet
pour voir si le fichier preferences a bien été pris en compte.

Soit prudent avec le pinning (d’où le apt-cache). Pour le plus d’infos, fais des recherches avec pinning debian. C’est très utile si tu dois mélanger les versions de manière propre.

#3

[quote]Donc voilà comme je sais que le driver 195.x fonctionne parfaitement sous windows, je me demandais s’il était possible de l’installez sous debian wheezy et comment?
Message[/quote]

sinon sgfxi installe le driver de ton choix

#4

Ce serait marrant de voir si nouveau présente le même problème… Bien noté que je n’ai aucune idée de comment passer de driver privateur à driver libre, et inversement.

(…es-tu sûr que ta carte graphique n’est pas en train de lâcher ?
Tester le pinning des drivers de squeeze devrait permettre d’arbitrer)

#5

[quote=“bobo38”]Ce serait marrant de voir si nouveau présente le même problème… Bien noté que je n’ai aucune idée de comment passer de driver privateur à driver libre, et inversement.

(…es-tu sûr que ta carte graphique n’est pas en train de lâcher ?
Tester le pinning des drivers de squeeze devrait permettre d’arbitrer)[/quote]

Je préfère recommander pour un simple test la méthode de marcastro qui travail tout de même de façon propre.

Maintenant pour passer d’un driver proprio à un driver libre il faut impérativement nettoyer tous ce qui à été installé et réinstallé le driver nouveau.

#6

sgfxi, OK je ne connaissais pas… Ça pas l’air mal sur le papier.

#7

Bon j’ai des nouvelles intéressantes mais qui remettent en cause ma question première !

En fait, je n’ai plus aucune envie d’installer le driver nvidia de squeeze (à savoir le 195.x) sur ma wheezy. Aucun intérêt !

En effet,

Premièrement : le driver “nouveau” fonctionne parfaitement ! (Est-il aussi puissant que le driver proprio? Pourrais-je utilisé steam sans le driver proprio?)

Deuxièmement : après de longues heures de recherches sur le net, j’ai cru comprendre qu’il y avait beaucoup de problèmes avec les derniers pilotes de chez nvidia pour les cartes comme la mienne (9600M GT, pas toute jeune quand même…) notamment avec certains laptops et/ou écrans. Donc je ne suis pas le seul (loin de là!) à avoir mon écran qui devient noir quelques secondes après avoir démarrer normalement, suite à l’installation des derniers pilotes nvidia. Et ce, que ce soit sous linux ou windaube!

J’ai donc fait un test : j’ai installé les derniers pilotes proprio nvidia de manière officielle et j’ai redémarrer.
Tout démarre parfaitement, les modules sont chargé, x se lance, j’arrive sur mon beau bureau mate, mais après une 30ne de seconde : écran noir, plus rien. Je redémarre mais cette fois ci, je branche un 2nd écran à la connectique vga de mon laptop, et là : aucun soucis, tout marche comme sur des roulettes et mes écrans ne deviennent pas noir. (J’écris ce poste actuellement dans cette configuration ^^). Si je redémarre et que je débranche mon deuxième écran, re écran noir au bout de 30s.
Je ne comprend donc pas bien à quoi est due ce bug! Il devrait y avoir moyen de configurer pour que cela fonctionne normalement?
Qu’est-ce que vous en pensez ?

#8

ta méthode officielle c’est le .run de chez nvidia?

#9

Heu non, j’ai installer les paquets debian.

Bref peu importe, c’est quand même dingue que tout fonctionne normalement quand un 2eme écran est branché mais pas seulement avec celui de mon laptop, non?!

Y’a vraiment personne qui y voit quelque chose et pourrait m’aider ?

#10

quels paquets debian?il faut être un peu plus verbeux dans les infos que tu fournis,nous on ne peut pas deviner.

#11

Bien si tu penses que cela peut changer quelque-chose au problème :
j’ai fait mon feignant et j’ai utiliser sgfxi avec l’option -d.
Mon sources.list ne contenant que les paquets pour wheezy, j’ai donc le pilote 304.88

Ce qui pourrait être intéressant c’est que je vous livre le contenu de Xorg.0.log après m’être connecté (sans mon 2ème écran bien sur…) mais je vois vraiment pas comment faire étant donné qu’au bout de 30s mon écran devient noir et que je n’est pas accès aux tty.

Une idée?

#12

Au choix, dans les méthodes lourdes :
— dual-boot : « un boot » pour faire crasher le merdier, « l’autre boot » pour récupérer le log
— LiveCD/LiveUSB pour lequel ça ne crache pas, tu récupères le log sur le disque dur et tu l’envoies
— démonte le disque dur et branche le sur un autre bécane

Sinon, il y a peut-être une incrémentation du fichier “Xorg.0.log” en “Xorg.1.log” (aucune idée à froid de la localisation du log de xorg, mais tu as l’air de t’y connaître). La dernière fois que j’ai regardé les logs sur ma Debian, j’avais beaucoup de versions différentes… Dans ce cas, au redémarrage avec 2ème écran tu pourrais accéder au “Xorg.1.log”, sans trop te prendre la tête.

#13

Si tu penses que l’erreur sera inscrite dans les logs, et que tu veux le récupérer après perte de l’écran, un bête [mono]sleep 1m && ce_que_tu_veux_faire[/mono] pourrait marcher.

Je chercherais à la fois dans Xorg.0.log et dans dmesg…

#14

Merci Zbf, je ne connaissais pas cette commande.
Est-tu sûr pour les && par contre ? Parce-que sur la page wikipedia de sleep il est indiqué qu’elle s’utilise comme suit :

#15

Les 2 fonctionnent.

[mono]commande1; commande2[/mono] fait que commande2 sera éxécutée dans tous les cas
[mono]commande1 && commande2[/mono] fait que commande2 ne sera éxécutée que si commande1 s’est déroulée sans pépin. Ca correspond au “ET” logique.

Et vu qu’on a rarement vu la commande [mono]sleep[/mono] provoquer un pépin, les 2 sont équivalentes dans le cas présent.

Par contre, il est vrai que si tu comptes enchaîner plusieurs commandes après ton sleep, l’opérateur [mono];[/mono] peut être plus approprié.

#16

[mono]/var/log/Xorg.0.log.old[/mono]