- Fedora-Fr
- À propos de Fedora-Fr
- Historique
- Statistiques
- Télécharger
- Obtenir Fedora
- Toutes les méthodes de téléchargement
- Support
- Aide sur IRC
- Forums
- Documentation
- Sous-projets
- Plateforme de blog
Dernière news : Assemblée Générale Ordinaire de Borsalinux-fr de 2021
Ghiomino a écrit :D'après la fiche de description du pilote, mon GPU est pris en charge.
Je viens de tilter : essaie avec le akmod-nvidia-340xx, qui devrait fonctionner avec ton GPU. Désolé de ne dire ça que maintenant, je viens juste de m'en rendre compte...
Ce sont les premiers que j'ai essayé, sans succès (nvidia-settings qui n'apparaissait pas du tout). J'ai testé les plus récents avec la GTX 970 (qui est dans la liste de compatibilité) aussi bien sur RPMFusion que Negativo, mais pas mieux ou alors avec nécessité d'en passer par une invite de commande pour éviter l'écran noir. C'est d'ailleurs pour ça que je suis passé sur la GTX 1050 qui m'a permis d'essayer les plus récents sans plus de succès.
Je ne comprends absolument pas ce que j'ai merdé, alors que sur Ubuntu je fais tourner la chose en trois clics. Je ne suis absolument pas pro-Canonical et leur politique tout à fait discutable, mais pour le coup ils facilitent la vie des possesseurs de cartes NVIDIA.
Je sais que NVIDIA est en cause, mais la même machine sous Ubuntu fonctionne sans peine. Un peu rageant non ?
Dans mes investigations, j'en suis venu à analyser toute la chaîne. Vérification du BIOS, du support utilisé pour l'installation et ayant un doute sur ma clef USB, j'en ai changé pour repartir sur une installation dont je suis 100% sûr.
Donc installation, arrivée sur le bureau, désactivation de Wayland, ajout du dépôt Negativo, redémarrage, installation des pilotes redemarrage (sans écran noir) et... Nvidia-settings me dit que je dois lancer nvidia-xconfig en Root. Je redémarre pour voir, la même. Je passe donc sur un terminal pour exécuter la commande qui me demande d'installer les outils, ce que je fais et hop redémarrage... Et ça bloque au lancement (après Started Update UTMP).
J'suis un poil découragé là, je savais que Fedora demandait un peu plus d'investissement qu'une autre distribution, mais je n'arrive tout simplement pas à avoir une machine fonctionnelle, même après une semaine à galérer.
Je suis si mauvais que ça ou juste carrément poisseux ?
Vous aurez remarqué que je n'ai pas encore mis [Résolu] dans le titre et pour cause, une fois arrivé sous GDM, je clique ma session et écran noir, pas de souris rien du tout, mais affichage actif. Si je passe par un lancement de la machine en ligne de commande, je log dans ma session et un
startx
m'amène proprement sur le bureau.
Je me suis dit que peut-être ma session avait besoin de privilèges supérieurs, je l'ai donc intégrée au fichier /etc/sudoers après avoir installé sudo via dnf, mais ça n'a rien changé.
Comment expliquez-vous que GDM n'arrive pas à me lancer le bureau alors que X fonctionne ?
J'ai bien vérifié, Wayland est toujours désactivé via le fichier /etc/gdm/custom.conf, je cherche cependant sur la toile s'il n'existe pas une autre façon de désactiver la chose au cas où le problème viendrait de là.
Suite de mes aventures !
Il semblerait que la GTX 970 (un modèle Hall of Fame de chez Galax / KFA²) ne soit pas copine avec ma configuration et Fedora 27.
Je suis passé sur une GTX 1050 (de chez KFA² aussi, le modèle low-profile) et j'ai relancé une installation suite à deux plantages à l'installation avec la GTX 970.
Arrivé sur le bureau, j'ai activé les dépots RPMFusion et Negativo
# dnf install https://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-$(rpm -E %fedora).noarch.rpm https://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-$(rpm -E %fedora).noarch.rpm
# dnf config-manager --add-repo=https://negativo17.org/repos/fedora-nvidia.repo
Pas de trace des pilotes Negativo (ou d'autre logiciel en rapport avec NVIDIA) dans le gestionnaire de logiciels. J'ai donc redémarré la machine après avoir désactivé Wayland en enlevant # devant "WaylandEnable=false" dans le fichier /etc/gdm/custom.conf
Cette fois, en tapant NVIDIA dans le gestionnaire de logiciels, les pilotes sont là et l'installation se fait. Tout roule et je redémarre la machine pour atterrir sur un écran noir après avoir sélectionné mon compte.
Je relance la machine (à la barbare) et demande à Grub de me connecter en mode texte (en ajoutant 3 à la ligne commençant par "linux" suivi de la combinaison de touches Ctrl + X pour lancer) et je passe en root pour vérifier que les pilotes sont bien là. Un Startx m'amène sur le bureau, je déconnecte le compte root, je passe sur ma session et miracle j'arrive sur le bureau ou ma carte graphique est bien détectée et ou nvidia-config est opérationnel, reconnaissant ma carte et mon moniteur.
Joie ! Il ne me reste qu'à tester la stabilité et les performances de l'ensemble !
En espérant que cela puisse aider les débutants ^^
Ça me rassure, je n'ai pas tout fait de travers :D
J'étais partie d'une installation toute fraîche avec l'ISO netinstall, du coup GNOME/Wayland de base.
On est d'accord, j'ai juste à désactiver Wayland dans GDM pour repasser sur X ?
Bonjour.
Pourquoi ne pas tester la solution donnée ici : https://negativo17.org/nvidia-driver/
J'ai installé les pilotes Nvidia, tout fonctionne, même mieux que sous Nouveau puisque le ventilateur de ma GT730 est enfin géré !
Nvidia-settings ne me détecte pas d'affichage avec les négativo, j'ai réussi à avoir un mieux en performances, mais pas quelque chose de pleinement utilisable.
Je vais tester une réinstallation et partir directement sur les negativo voir si je ne joue tout simplement pas de malchance ;/
Tu as dû désactiver Wayland avec ces pilotes ?
J'y ai songé, mais t'as vu les prix en ce moment ? Même en revendant les deux je n'aurai pas de quoi m'offrir équivalent...
Le jour où je dois changer, c'est certain que je passe chez AMD par contre. Une RX 570 ou 580 me suffirait, mais à 400€ faut pas déconner :o
Vous pensez que passer sur une carte graphique à puce Pascal (GTX 1050) à la place de celle à puce Maxwell (GTX 970 et ses 4Go de VRAM litigieux) que j'ai là pourrais améliorer les choses ?
Au bout d'un moment je vais tenter vu comme ça n'avance pas.
C'est super rageant de perdre autant de temps sur un truc qui se fait facilement ailleurs. Même sur Debian Sid je n'avais pas autant galéré (bon ok avec des pilotes moins récents pour le coup).
Après suppression de :
rd.driver.blacklist=nouveau modprobe.blacklist=nouveau nvidia-drm.modeset=1
Bizarrement ça démarre beaucoup mieux ! Merci nouvo09 !
Me reste maintenant à savoir pourquoi le dépot RPMFusion updates-testing est indisponible.
Avant ça, peux tu poster la ligne de ton fichier /etc/grub2/grub.cfg qui décrit les options de boot ?
C'est celle qui comment par: linux
Ooouuuh la bonne idée ! Merci de t'intéresser à mon cas (qui semble désespéré :D).
Etant en UEFI, le fichier se trouvait dans /boot/efi/EFI/fedora et en voici le contenu (pour la ligne demandée) :
linuxefi /vmlinuz-4.14.15-300.fc27.x86_64 root=/dev/mapper/fedora-root ro rd.lvm.lv=fedora/root rd.lvm.lv=fedora/swap rhgb quiet rd.driver.blacklist=nouveau modprobe.blacklist=nouveau nvidia-drm.modeset=1
initrdefi /initramfs-4.14.15-300.fc27.x86_64.img
Et du coup, je comprends mieux que le démarrage soit chaotique. Puis-je bricoler ça à la main ? D'ailleurs ça me fait penser que lors de l'installation des pilotes proprio à la main, j'avais noté deux fichiers à supprimer et que je ne l'ai pas fait !
Cette fois je suis passé par ce qui semble être la meilleure façon d'installer les pilotes propriétaires sur une machine en Fedora 27, avec un tutoriel de chez "If not true then false" qui détaille la démarche faite intégralement à la main.
Manque de bol, j'ai le droit à un message d'erreur du kernel NVIDIA à la fin et retour sous nouveau (pourtant désinstallé...) automatique. Je ne suis apparemment pas le seul puisque le forum devel-NVIDIA a de nombreux messages parlant du même problème.
Plus embêtant, après avoir suivi à la lettre le tutoriel pour revenir sous nouveau du même site, je me retrouve avec un bureau en 1024x768 et pas de possibilité de modifier l'affichage.
Je pense que mes multiples bidouillages ont joliment abimé le système et qu'il va m'en falloir repasser par la case réinstallation. C'est rageant tant l'installation d'un pilote graphique est bête à faire sous une distro type Ubuntu (trois clics et c'est réglé).
Je me heurte d'ailleurs à un problème que je n'avais jamais rencontré, DNF qui me dit que des paquets sont indisponibles lorsque je demande de les réinstaller (pour rire, ce sont kernel-devel et kernel-headers).
En imaginant que c'est ma GTX 970 qui pose problème (apparemment la VRAM pourrait jouer dans la compilation du pilote), je vais peut-être tester avec une GTX 1050 que j'ai de côté.
Je ne m'avoue cependant pas vaincu !
Je suis cette fois passé par le protocole donné directement sur RPMFusion et j'arrive à jouer (pas avec le plein potentiel de ma machine), mais toujours pas de nvidia-setting fonctionnel. Wayland est du coup désactivé pour éviter d'en passer par une version particulière de mutter.
Les commandes tapées (après ajout des dépots RPMFusion) sont :
dnf install xorg-x11-drv-nvidia akmod-nvidia
dnf update -y
Et j'ai décommenté "WaylandEnable=false" dans /etc/gdm/custom.conf
Je reparts sous nouveau pour essayer d'avoir quelque chose de plus propre !
Salut pépé !
Je débute aussi sous Fedora et j'ai en partie eu les mêmes craintes quant au partitionnement. L'outil est cependant bien foutu et en sélectionnant tes SSD et en passant par une création manuelle des volumes, tu ne devrais pas avoir de problème à faire ce que tu désires. Pour ton /home, ils suffit de monter le volume en tant que tel et spécifier qu'il ne doit pas être formaté.
Pour le coup du GRUB par contre, ça n'est pas mon fort alors je laisse un pro en parler !
Après plusieurs tests, l'ensemble n'est pas pleinement fonctionnel. Lancer un jeu gourmand (Middle Earth: Shadow of Mordor) me vaut une machine figée.
Donc j'ai réussi à avoir un environnement stable, mais je ne peux toujours pas exploiter mon GPU.
Ça va finir chez AMD cette histoire :o
J'en suis à chercher comment faire fonctionner nvidia-settings qui est pourtant installé. Voici le retour d'un terminal lorsque je lance la commande en tant qu'utilisateur et en root :
[guillaume@localhost ~]$ nvidia-settings
ERROR: Unable to find display on any available system
[root@localhost guillaume]# nvidia-settings
No protocol specified
** (nvidia-settings:5120): WARNING **: Could not open X display
ERROR: Unable to find display on any available system
C'est encore à cause de Wayland ? C'est ce que je me dis puisque sous Root il cherche un moniteur sous X. Pourquoi cela fonctionne-t-il sous pilotes Negativo alors ? A moins que ces derniers ne désactivent Wayland sans que cela soit spécifié...
Je seche la... Tu utilises bien Xorg et pas Wayland ?
Au moins tu as une solution de reppli avec negativo
Pas habitué à Wayland, ta question m'a intrigué et j'ai donc cherché une solution de ce côté, ce que j'ai trouvé !
En m'intéressant à la documentation des pilotes proprio NVIDIA sur RPMFusion, il se trouve qu'il est noté qu'il faut une version particulière de Mutter pour obtenir une compatibilité EGLstream sous Wayland, les quelques lignes qui suivent m'ont du coup permis de lancer une session Gnome/Wayland de manière pleinement fonctionnelle, même si nvidia-setting refuse toujours de montrer le bout de son nez.
dnf copr enable mati865/mutter-eglstream
dnf --disablerepo="*" --enablerepo="mati865-mutter-eglstream" reinstall mutter
Maintenant je me pose cependant la question de ce qui va arriver à la prochaine mise à jour de Mutter ? Faudra-t-il que je garde sous le coude ces lignes pour réitérer la chose au besoin ? Je vais réactiver mes autres repositories pour la suite, en espérant que ce bidouillage sur repo copr ne me foute pas trop le bordel sur la machine !
Si ça peut faire avancer le schmilblick, je me suis rendu compte que l'installation des pilotes proprio via RPMFusion ne me donne pas accès à nvidia-settings. Le soft est installé, mais n'apparait pas dans le menu des applications et je ne peux pas le lancer en ligne de commande.
[root@localhost guillaume]# dnf install nvidia-settings
Dernière vérification de l’expiration des métadonnées effectuée il y a 0:32:23 le sam. 27 janv. 2018 20:42:41 CET.
Le paquet nvidia-settings-387.34-1.fc27.x86_64 est déjà installé, ignorer
Dépendances résolues.
Rien à faire.
Terminé !
[root@localhost guillaume]# nvidia-settings
No protocol specified
** (nvidia-settings:3479): WARNING **: Could not open X display
ERROR: Unable to find display on any available system
Et sur mon compte utilisateur :
[guillaume@localhost ~]$ nvidia-settings
ERROR: Unable to find display on any available system
C'est embêtant, parce que mon moniteur est bien là ! (bon, c'est une vieille TV HDReady, mais elle fait le taf !)
A noter que nvidia-settings fonctionne avec les pilotes Negativo.
Lance un akmods en root pourverifier si le pilote a bien été compilé
J'ai testé et en voici la réponse :
[root@localhost guillaume]# akmods
Checking kmods exist for 4.14.14-300.fc27.x86_64 [ OK ]
Et le pilote en question est celui-ci :
[root@localhost guillaume]# dnf info akmod-nvidia
Dernière vérification de l’expiration des métadonnées effectuée il y a 0:26:36 le sam. 27 janv. 2018 20:42:41 CET.
Paquets installés
Nom : akmod-nvidia
Époque : 2
Version : 387.34
Révision : 1.fc27
Architecture : x86_64
Taille : 61 k
Source : nvidia-kmod-387.34-1.fc27.src.rpm
Dépôt : @System
Depuis le dé : rpmfusion-nonfree-updates
Résumé : Akmod package for nvidia kernel module(s)
URL : http://www.nvidia.com/
Licence : Redistributable, no modification permitted
Description : This package provides the akmod package for the nvidia kernel
: modules.
D'après la fiche de description du pilote, mon GPU est pris en charge.
Il se peut aussi qu'un service systemd en soit la cause.
que retourne la commande :systemd-analyze blame
Me revoilà sous pilotes proprios, toujours le même problème de lenteur, mais la définition n'a pas sauté cette fois ! Gnome Shell pompe toujours 30 à 40% sur tous les coeurs de mon CPU.
Voici du coup la réponse à la commande demandée :
[guillaume@localhost ~]$ systemd-analyze blame
4.568s plymouth-quit-wait.service
2.030s NetworkManager-wait-online.service
1.303s lvm2-monitor.service
1.173s systemd-udev-settle.service
734ms fwupd.service
506ms firewalld.service
347ms dev-mapper-fedora\x2droot.device
333ms dracut-initqueue.service
326ms initrd-switch-root.service
307ms sssd.service
285ms akmods.service
192ms libvirtd.service
164ms udisks2.service
136ms chronyd.service
136ms auditd.service
125ms dracut-pre-pivot.service
110ms user@1000.service
100ms user@42.service
96ms packagekit.service
96ms lvm2-pvscan@8:33.service
96ms gssproxy.service
96ms systemd-vconsole-setup.service
94ms lvm2-pvscan@8:3.service
86ms systemd-journal-flush.service
79ms ModemManager.service
78ms abrtd.service
78ms systemd-udevd.service
78ms avahi-daemon.service
76ms rtkit-daemon.service
73ms systemd-udev-trigger.service
67ms upower.service
62ms dracut-cmdline.service
47ms initrd-parse-etc.service
47ms systemd-tmpfiles-setup-dev.service
42ms polkit.service
41ms systemd-tmpfiles-setup.service
40ms cups.service
36ms NetworkManager.service
33ms var-lib-nfs-rpc_pipefs.mount
33ms fedora-readonly.service
28ms fedora-import-state.service
28ms systemd-fsck@dev-disk-by\x2duuid-6d4fe513\x2deae1\x2d4740\x2d8c
28ms systemd-binfmt.service
25ms gdm.service
23ms systemd-fsck@dev-disk-by\x2duuid-21C4\x2d1573.service
23ms geoclue.service
19ms colord.service
18ms realmd.service
17ms proc-sys-fs-binfmt_misc.mount
17ms boot-efi.mount
17ms systemd-sysctl.service
16ms systemd-journald.service
16ms systemd-fsck-root.service
16ms dracut-pre-udev.service
15ms accounts-daemon.service
15ms systemd-fsck@dev-mapper-fedora\x2dhome.service
15ms plymouth-start.service
14ms plymouth-read-write.service
14ms systemd-logind.service
14ms home.mount
14ms dev-mapper-fedora\x2dswap.swap
13ms sys-kernel-debug.mount
13ms wpa_supplicant.service
13ms kmod-static-nodes.service
12ms plymouth-switch-root.service
11ms dev-hugepages.mount
10ms dev-mqueue.mount
9ms systemd-update-utmp-runlevel.service
9ms systemd-update-utmp.service
9ms systemd-remount-fs.service
8ms switcheroo-control.service
8ms sysroot.mount
7ms boot.mount
7ms systemd-user-sessions.service
7ms nfs-config.service
6ms rpc-statd-notify.service
6ms initrd-cleanup.service
6ms tmp.mount
4ms sys-fs-fuse-connections.mount
4ms systemd-random-seed.service
3ms initrd-udevadm-cleanup-db.service
1ms dracut-shutdown.service
1ms sys-kernel-config.mount
J'ajoute qu'à l'extinction de la machine (pour le reboot après installation des pilotes), j'ai vu une ligne parlant de "Kernel" mais trop rapidement pour savoir ce qui allait derrière. C'est quelque chose que je peux retrouver grâce à une commande du type journalctl ? J'ai testé, mais j'avoue ne pas avoir le niveau pour comprendre la moitié de ce qui s'affiche.
Il se peut aussi qu'un service systemd en soit la cause.
que retourne la commande :systemd-analyze blame
Je viens de faire une tentative de retour sous akmod-nvidia RPMFusion et plantage au démarrage. Je repasse sur Nouveau pour la soirée, mais je ne manquerai pas de réitérer l'expérience dès demain ! Merci à toi :)
Je teste d'ailleurs cette commande que je découvre, ça me permettra de voir demain sous pilotes proprio ce qui change :
[guillaume@localhost ~]$ systemd-analyze blame
3.903s plymouth-quit-wait.service
1.962s NetworkManager-wait-online.service
1.543s dracut-initqueue.service
1.040s lvm2-monitor.service
911ms systemd-udev-settle.service
738ms fwupd.service
492ms firewalld.service
362ms dev-mapper-fedora\x2droot.device
335ms initrd-switch-root.service
296ms sssd.service
199ms libvirtd.service
171ms udisks2.service
126ms dracut-pre-pivot.service
120ms ModemManager.service
100ms lvm2-pvscan@8:33.service
100ms lvm2-pvscan@8:3.service
98ms systemd-vconsole-setup.service
97ms switcheroo-control.service
96ms gssproxy.service
90ms rtkit-daemon.service
89ms user@42.service
87ms avahi-daemon.service
85ms packagekit.service
84ms abrtd.service
84ms systemd-journal-flush.service
77ms user@1000.service
75ms systemd-udev-trigger.service
73ms systemd-udevd.service
68ms upower.service
65ms chronyd.service
58ms dracut-cmdline.service
46ms systemd-tmpfiles-setup-dev.service
45ms initrd-parse-etc.service
42ms systemd-tmpfiles-setup.service
42ms polkit.service
37ms systemd-binfmt.service
35ms auditd.service
35ms NetworkManager.service
32ms var-lib-nfs-rpc_pipefs.mount
30ms fedora-readonly.service
28ms fedora-import-state.service
28ms systemd-fsck@dev-disk-by\x2duuid-21C4\x2d1573.service
26ms systemd-fsck@dev-disk-by\x2duuid-6d4fe513\x2deae1\x2d4740\x2d8c
22ms colord.service
22ms cups.service
21ms gdm.service
20ms systemd-logind.service
20ms accounts-daemon.service
18ms proc-sys-fs-binfmt_misc.mount
17ms geoclue.service
16ms systemd-fsck-root.service
16ms systemd-sysctl.service
16ms boot-efi.mount
16ms systemd-remount-fs.service
16ms systemd-journald.service
15ms dracut-pre-udev.service
15ms home.mount
15ms plymouth-read-write.service
15ms systemd-fsck@dev-mapper-fedora\x2dhome.service
15ms wpa_supplicant.service
14ms plymouth-start.service
13ms dev-mqueue.mount
12ms plymouth-switch-root.service
11ms kmod-static-nodes.service
10ms boot.mount
10ms dev-mapper-fedora\x2dswap.swap
9ms nfs-config.service
8ms systemd-update-utmp-runlevel.service
8ms sysroot.mount
8ms sys-kernel-debug.mount
6ms dev-hugepages.mount
6ms initrd-cleanup.service
6ms rpc-statd-notify.service
6ms sys-fs-fuse-connections.mount
5ms systemd-user-sessions.service
5ms systemd-update-utmp.service
4ms systemd-random-seed.service
3ms tmp.mount
3ms initrd-udevadm-cleanup-db.service
2ms dracut-shutdown.service
1ms sys-kernel-config.mount
Je pense que là il y a un petit problème quelque part.
KDE et gnome shell sont assez gourmand en ressource, mais prendre 30-40 % en ressource cpu me semble excessif.
Perso je suis avec un core I3, carte nvidia et driver propriétaire et l'affichage du bureau ne me prend que 1 à 2 % d'utilisation cpu.
Sous Nouveau, je n'ai qu'une charge de 1 à 4% pour gnome-shell. Je confirme donc que les 30 à 40% sont exagérés ! :D
As-tu essayé avec un autre environnement de bureau type KDE ?
J'aime beaucoup Gnome 3 et toutes les modifications qu'il permet, du coup non je n'ai pas utilisé d'autre environnement.
Je sais, j'en demande beaucoup !
Si cela peut jouer dans la résolution de la chose, je me suis rendu compte que lorsque les pilotes NVIDIA RPMFusion sont installés, le moniteur système m'affiche une consommation de 30 à 40% du CPU par gnome-shell. Tous les 6 coeurs et 12 threads de mon petit Ryzen qui moulinent ensemble juste pour afficher le bureau !