- 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 : Fedora 34 n'est plus maintenu
Bonjour à tous et tout d'abord désolé de coller du propriétaire NVIDIA sur une Fedora, mais je n'ai pas de carte de chez AMD sous la main et j'ai besoin de la puissance de calcul de la carte, ce que Nouveau ne m'apporte pas correctement.
Nouveau sur Fedora, mais motivé à y rester après des années à utiliser Ubuntu par facilité ou Debian Sid par masochisme, je me suis lancé dans l'installation sous Fedora 27 de ma nouvelle machine dont voici la configuration :
Carte mère : ASRock AB350M Pro4 (UEFI inside)
Processeur : Ryzen 5 1600
Carte graphique : GTX 970
Pour le reste, de la DDR4 en quantité et des SSD+HDD.
En bon petit novice, j'ai bien pris garde d'avoir la documentation en main et j'ai utilisé la page dédiée aux pilotes propriétaires NVIDIA pour installer ces derniers. Je parts d'ailleurs d'une installation toute fraiche.
J'ai tout d'abord ajouté les dépots RPMFusion, puis suivi la démarche pour les GeForce récentes.
Un petit reboot et retour à l'écran de choix du compte utilisateur.
Ici, premier couac, je rentre et la définition choisie est supérieure à celle que peut accepter mon moniteur. Du 1920x1080 sur un engin taillé pour le 1366x768, certainement une erreur d'interprétation du 1080i disponible et rien de bien grave puisque le moniteur affiche tout de même le bureau (un zoom sur le centre) et je peux donc modifier la chose.
Fait plus grave, tout est excessivement lent. Lancer un terminal me fige la souris bien 10 secondes (pointeur tournant) et toutes les applications réagissent de même. Une fois lancées, je n'ai cependant plus de problème (comme par exemple avec Firefox que j'utilise sur la machine pour écrire ce texte).
J'ai farfouillé pour trouver ce qui pouvait bloquer. J'ai désactivé Wayland sur GDM (comme conseillé ici), sans succès. Je suis retourné dans la documentation pour jeter un oeil aux erreurs connues, mais je sèche. Nouveau n'est pas chargé en même temps, donc pas de conflit. Mon BIOS ne me permet pas d'activer l'IRQ ou de désactiver Plug&Play pour le VGA, xorg-x11-drv-nvidia est bien à la même version que akmod-nvidia et les autres options sont hors de mon domaine de compétence, raison pour laquelle je viens faire appel à la communauté.
J'ai aussi lu que l'UEFI posait problème dans certains cas, est-ce que c'est ce qui m'arrive ? Si c'est le cas, je vais donc devoir suivre ce guide, mais vais-je garder la même souplesse d'utilisation qu'avec akmod qui permet d'automatiquement recompiler à chaque changement de noyau ? Je sais qu'il faut aimer mettre les mains dans le cambouis pour profiter du monde GNU/Linux, mais après quelques temps en Debian Sid, j'ai envie d'un peu de stabilité !
A noter que lors d'une précédente tentative, j'avais réussi à avoir des pilotes fonctionnels, mais les paquets venaient d'un dépôt privé (Negativo) et je préfèrerai utiliser quelque chose de plus sûr.
Merci de m'avoir lu et désolé du dérangement.
Dernière modification par Ghiomino (26/01/2018 18:00:33)
Hors ligne
Hello,
et bienvenu parmi nous ! Concernant l'UEFI, ça date du noyau 4.10 et on est au 4.14. J'imagine que le sujet à été résolu depuis. tente de désactiver l'UEFI sans toucher au pilote pour voir ?
Il n'y a pas de différence de comportement entre Wayland et Xorg donc ? Et les lenteurs viennent bien de l'installation du akmod-nvidia ? si tu vires *nvidia* et que tu rebootes, le système tourne sans problème ?
Asus VivoBook S 15 Fedora 34 x86_64 KDE
Hors ligne
Hello,
et bienvenu parmi nous ! Concernant l'UEFI, ça date du noyau 4.10 et on est au 4.14. J'imagine que le sujet à été résolu depuis. tente de désactiver l'UEFI sans toucher au pilote pour voir ?Il n'y a pas de différence de comportement entre Wayland et Xorg donc ? Et les lenteurs viennent bien de l'installation du akmod-nvidia ? si tu vires *nvidia* et que tu rebootes, le système tourne sans problème ?
Salut Edouard et merci pour l'accueil et la réponse !
Là je suis repassé sous Nouveau en supprimant tout ce qui était NVIDIA propriétaire et tout roule. En propriétaire, j'avais un système lent de base et si je modifiais Wayland, plus moyen de me connecter (freeze sur l'écran de fond gris de la page de gestion des comptes).
Tu me proposes de désactiver l'UEFI sans toucher au pilote, comment faire ? Un bricolage dans GRUB en modifiant le boot ?
Hors ligne
En effet, Wayland n'est pas encore tout à fait au point...
Qu'est ce qui justifie l'installation du pilote proprio ? Peux tu détailler ?
Pour l'UEFI, tu désactives ça dans le BIOS. Après je viens de me rendre compte que ça risque de ne plus booter... je me demande si ça n'a pas déjà été abordé dans le forum. Tu dois pouvoir t'en sortir en bootant sur un liveUSB et en réinstallant le grub depuis le liveUSB sur la partition /boot de ton disque dur. mais à vérifier.
Asus VivoBook S 15 Fedora 34 x86_64 KDE
Hors ligne
Je suis joueur et c'est ce qui me lie aux pilotes propriétaires (j'ai abandonné Windows il y a longtemps, mais j'aime toujours jouer !).
Si je renonce à l'UEFI, ça veut donc dire qu'il va falloir partir sur une réinstallation. C'est un peu dommage avec ce genre de matos...
Hors ligne
> Je suis joueur et c'est ce qui me lie aux pilotes propriétaires
perso j'ai un petit SSD sur lequel j'ai un windows d'installé, et je joue avec ce seul disque dur. ça évite les dual boot et les emm... en général.
> Si je renonce à l'UEFI, ça veut donc dire qu'il va falloir partir sur une réinstallation.
Je suis convaincu que tu peux juste réinstaller le grub à partir d'un liveUSB. cherche dans le forum, je pense que ça a été déjà abordé par nouvo
Asus VivoBook S 15 Fedora 34 x86_64 KDE
Hors ligne
> Je suis joueur et c'est ce qui me lie aux pilotes propriétaires
perso j'ai un petit SSD sur lequel j'ai un windows d'installé, et je joue avec ce seul disque dur. ça évite les dual boot et les emm... en général.
J'aime autant que faire ce peut éviter d'avoir à passer par Windows. Mes jeux fonctionnent sous Wine, pourquoi m'embêter ? :D
> Si je renonce à l'UEFI, ça veut donc dire qu'il va falloir partir sur une réinstallation.
Je suis convaincu que tu peux juste réinstaller le grub à partir d'un liveUSB. cherche dans le forum, je pense que ça a été déjà abordé par nouvo
Je vais regarder, merci ! Ça reste cependant un moyen détourné de résoudre le problème et ça a un quelque chose de frustrant :p
Hors ligne
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 !
Hors ligne
As-tu essayé avec un autre environnement de bureau type KDE ?
Asus VivoBook S 15 Fedora 34 x86_64 KDE
Hors ligne
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 !
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 KDE ne me prend que 1 à 2 % d'utilisation cpu.
Dernière modification par chepioq (26/01/2018 19:02:55)
Tout est dans tout... et réciproquement...
C'est quoi un chalumeau??? C'est un dromaludaire à deux bosses...
Quand le sage montre la lune l'imbécile regarde le doigt...
Hors ligne
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 !
Hors ligne
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
Dernière modification par Ghiomino (26/01/2018 19:05:26)
Hors ligne
Il se peut aussi qu'un service systemd en soit la cause.
que retourne la commande :
systemd-analyze blame
Dernière modification par chepioq (26/01/2018 20:20:08)
Tout est dans tout... et réciproquement...
C'est quoi un chalumeau??? C'est un dromaludaire à deux bosses...
Quand le sage montre la lune l'imbécile regarde le doigt...
Hors ligne
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
Hors ligne
Lance un akmods en root pourverifier si le pilote a bien été compilé
Asus VivoBook S 15 Fedora 34 x86_64 KDE
Hors ligne
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.
Hors ligne
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.
Hors ligne
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.
Dernière modification par Ghiomino (27/01/2018 22:20:39)
Hors ligne
Je seche la... Tu utilises bien Xorg et pas Wayland ?
Au moins tu as une solution de repli avec negativo
Dernière modification par Edouard_le_homard (28/01/2018 18:50:42)
Asus VivoBook S 15 Fedora 34 x86_64 KDE
Hors ligne
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 !
Hors ligne
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é...
Hors ligne
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
Hors ligne
Oui l'attitude de nvidia est assez frustrante...
Asus VivoBook S 15 Fedora 34 x86_64 KDE
Hors ligne
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 !
Dernière modification par Ghiomino (29/01/2018 12:59:25)
Hors ligne
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é.
Hors ligne