néanmoins, le problème est là, et la doc était pas spécifiée, il était peut être pas évident que ce soit la doc de fedora-fr (même si pour moi si), il met de la bonne volonté à répondre, ainsi, tâchons d'essayer de voir ce qui cloche.

Zugallak wrote:néanmoins, le problème est là, et la doc était pas spécifiée, il était peut être pas évident que ce soit la doc de fedora-fr (même si pour moi si), il met de la bonne volonté à répondre, ainsi, tâchons d'essayer de voir ce qui cloche.

Oui, tu as raison, je me suis un peu emporté sur ce coup là ! :hammer:
Pour moi aussi , c'était évident que c'était la doc de fedora-fr ...
Attendons de voir ce que Ruxob va répondre.

Bonjour,
une fois démarré en init3 et que ta as la console, logue toi en root et supprime ton xorg.conf avec cette commande: rm -rf /etc/X11/xorg.conf
enfin qu'en pensent Fifi et Zugallak?

jcdoudou wrote:Bonjour,
une fois démarré en init3 et que ta as la console, logue toi en root et supprime ton xorg.conf avec cette commande: rm -rf /etc/X11/xorg.conf
enfin qu'en pensent Fifi et Zugallak?

Il est préférable de conseiller un mv plutôt qu'un rm -rf sur un simple fichier.

D'ailleurs pourquoi recursive ? Et aussi pourquoi forcer ? Il est préférable (en root) de faire un rm -i /etc/X11/xorg.conf. Pour éviter toute erreur de frappe et de supprimer violemment un dossier !

oui tu as raison, c'est pour cela que je demandais d'autres avis.

Peu importe le driver qu'il installera (.run, kmod, akmod), je crois qu'il aurait mieux fait de lire la doc avant ne serait ce qu'à titre d'info, notre amis saurait qu'il faut blacklister nouveau :-P

Hum me semble que j'avais eu des soucis à une époque en voulant tester kmod et akmod et que j'avais en plus du rdblacklist=nouveau dans grub dû ajouter un blacklist à l'arrache.
Bon là je tourne avec le .run pas de soucis sauf le fameux rdblacklist=nouveau dans grub
(ha et ouais à chaque MAJ du kernel, même si ça peut booter le mieux est de reinstaller).
J'ai découvert les joies de twinview aujourd'hui au passage, un nouvel écran étant arrivé :pint:

bien sûr on précisera que la solution du .run doit être à utiliser qu'en dernier recourt, vu que c'est déconseillé à la base.

madko wrote:bien sûr on précisera que la solution du .run doit être à utiliser qu'en dernier recourt, vu que c'est déconseillé à la base.

+1

madko wrote:bien sûr on précisera que la solution du .run doit être à utiliser qu'en dernier recourt, vu que c'est déconseillé à la base.

J'aurais du le préciser en effet.
Enfin en dernier recourt, pas nécessairement, dans mon cas c'est systématique, mais faut savoir s'en sortir en cas de soucis c'est vrai.

nothanks wrote: J'aurais du le préciser en effet.
Enfin en dernier recourt, pas nécessairement, dans mon cas c'est systématique, mais faut savoir s'en sortir en cas de soucis c'est vrai.

Il faudrait retrouver les messages de kwizart qui donne les problèmes du .run avec Fedora mais si ma mémoire défaille pas trop ça vient de certains fichiers qui peuevnt être en conflit avec la distribution... Donc le rpm est fait spécialement pour corriger ces conflits (pas pour faire joli). C'est la seule différence avec le .run mais bon un système installé avec le .run semble ne pas pouvoir, la plupart du temps, installer le akmod...

nothanks wrote:Hum de mémoire faut désinstaller le .run via ... le .run

Sauf que, comme dit juste au dessus, le .run entre en conflit avec des fichiers systèmes donc en le désinstallant il supprime le fichier système...

nothanks wrote: et me semble que c'est "nouveau" que j'avais re-activé avant de repasser au kmod (akmod je crois n'étais pas dispo pour le kernel visé). Je garanti pas c'est assez flou est ça date d'un an je crois.

Le akmod se recompile tout seul à chaque changement de noyau et cela fait au moins 2 ans qu'il fonctionne sans trop de soucis. Le kmod n'arrive pas forcément avec le changement de noyau mais si on installe juste le akmod cela suffit.
Il est vrai qu'à un moment nouveau entrait trop en conflit avec les pilotes propriétaires nvidia mais depuis, le blacklist est beaucoup plus efficace (et fonctionnel) donc plus de soucis.

Au final, privilégier la solution du .run c'est à ses risques et périls mais on a un pakageur (kwizart) qui se ***** le c** pour nous sortir un paquet propre sans conflit et qui ne détruit pas le système et qui fonctionne parfaitement (j'ai personnellement que des nvidia... voir signature) alors pourquoi s'en priver. Et s'il ne fonctionne pas j'en suis sur qu'il sera ravi (enfin faut pas abuser) d'avoir un bug report chez rpmfusion pour corriger le problème chez les possesseurs de telle ou telle carte.

Oui pardon, je voulais dire que le kmod n'était pas encore dispo pour le kernel visé (j'en fini par me mélanger les pinceaux).
Et vraiment je loue le travail des packageur et j'ai bien précisé que je sais ce que je risque, mais moi non plus je n'ai pas de soucis et je suis même assez kamikaze pour mettre du beta parfois.

Ha oui, le seul truc, à chaque changement de kernel, il faut reinstaller, ce qui va très vite au passage.

MarbolanGos wrote:Au final, privilégier la solution du .run c'est à ses risques et périls mais on a un pakageur (kwizart) qui se ***** le c** pour nous sortir un paquet propre sans conflit et qui ne détruit pas le système et qui fonctionne parfaitement (j'ai personnellement que des nvidia... voir signature) alors pourquoi s'en priver

Tout à fait !!!