Bonjour
Aujourd'hui il y a une mise à jour du kernel 4.6.5-300.fc24
J'utilise akmods-nvidia 367.35 mais avec ce kernel impossible de construire le kmod-nvidia qui va bien.
Dans /var/cache/akmods/nvidia/.last.log j'ai 
2016/08/09 07:46:54 akmods: Building RPM using the command '/sbin/akmodsbuild --target x86_64 --kernels 4.6.5-300.fc24.x86_64 /usr/src/akmods/nvidia-kmod.latest'

Session terminée, l'interpréteur est en train d'être tué… … tué.
J'ai lancé la commande indiqué en console, mais cela ne fonctionne pas, je vois qu'il y a des processus cc1 qui me prennent 100% du cpu, et quand j'arrête la commande j'ai ceci : 
[dominique@host-192-168-1-2 ~]$ /sbin/akmodsbuild --target x86_64 --kernels 4.6.5-300.fc24.x86_64 /usr/src/akmods/nvidia-kmod.latest
* Rebuilding /usr/src/akmods/nvidia-kmod.latest for kernel(s) 4.6.5-300.fc24.x86_64: prep build ^C/sbin/akmodsbuild: ligne 116 : kill: (13997) - No such process
/sbin/akmodsbuild : ligne 113 : 13995 Termine 1               /usr/bin/time --format='%x' --output="${tmpdir}/.jobexit" rpmbuild --define "_topdir     ${tmpdir}/" --define "_buildtree  ${tmpdir}/BUILD" --define "_specdir    ${tmpdir}/SPECS" --define "_sourcedir  ${tmpdir}/SOURCES" --define "_srcrpmdir  ${tmpdir}/SRPMS" --define "_rpmdir     ${tmpdir}/RPMS" --define "_smp_mflags -j${numberofjobs}" --define "kernels     ${kernels}" --target ${target} --rebuild "${source_rpm}" 2>&1
     13996 Terminated              | tee -a "${logfile}" > "${tmpdir}/.joblog"
tail: impossible d'ouvrir '/tmp/akmodsbuild.XOenTRKg/.jobexit' en lecture: No such file or directory
/sbin/akmodsbuild: ligne 221: ((: != 0  : erreur de syntaxe : opérande attendue (le symbole erroné est "!= 0 ")
Successfull; /sbin/akmodsbuild: ligne 152: /tmp/akmodsbuild.XOenTRKg/logfile: No such file or directory
/sbin/akmodsbuild: ligne 237 : cd: /tmp/akmodsbuild.XOenTRKg/RPMS/x86_64: No such file or directory
mv: impossible d'évaluer '/tmp/akmodsbuild.XOenTRKg/RPMS/x86_64/*': No such file or directory

/sbin/akmodsbuild: ligne 152: /tmp/akmodsbuild.XOenTRKg/logfile: No such file or directory
Failed to move /tmp/akmodsbuild.XOenTRKg/RPMS/x86_64/* to /home/dominique
/sbin/akmodsbuild: ligne 152: /tmp/akmodsbuild.XOenTRKg/logfile: No such file or directory
[dominique@host-192-168-1-2 ~]$
Quelqu'un a une idée ?
Je précise que pour le kernel précédent je n'ai eu aucun soucis.
J'ai eu le même souci sur l'Asus de ma F. (qui tournait avec l'akmod) hier. Et rien n'y a fait pour faire tourner la GeForce GT710 (Nouveau ne passant pas, ce fut bien galère...).

Voici la seule solution que j'ai trouvé (pas super pratique sur le long terme, mais dans l'urgence...) :
http://doc.fedora-fr.org/wiki/Carte_graphique_NVIDIA_:_installation_des_pilotes#Utiliser_le_pilote_propri.C3.A9taire_fourni_par_NVIDIA

Soit la procédure suivante :
- désinstallation complète d'akmod-nvidia : 
dnf remove "nvidia-settings" "nvidia-xconfig" "*kmod-nvidia" "xorg*nvidia*"
- vérification des dépendances : 
dnf install kernel-devel kernel-headers gcc dkms
- puis installation manuelle (après télécharchement depuis le site de Nvidia : http://www.nvidia.fr/Download/index.aspx?lang=fr ),
- reboot.

Et tout fonctionne parfaitement.
Cela correspond à installer les drivers nvidia avec le .run, ce que je ne veux surtout pas faire.
Pour le moment je démarre sur l'avant-dernier kernel , je verrais plus tard si ce bogue peut-être résolu.
chepioq wrote:Cela correspond à installer les drivers nvidia avec le .run, ce que je ne veux surtout pas faire.
Pour le moment je démarre sur l'avant-dernier kernel , je verrais plus tard si ce bogue peut-être résolu.
Ca m'est déjà arrivé dans le passé avec certains kernels, il faut désinstaller celui qui pose problème, continuer avec le précédent et attendre un nouveau.

Pour F24, je n'ai pas encore fait de dnf upgrade aujourd'hui et donc pas essayé ce kernel qui te pose problème : 4.6.5-300.fc24
Tu utilise la version RPMfusion ou la negativo17 ?
J'utilise la version du dépôt rpmfusion.
Tu penses que celle de negativo17 fonctionnera mieux ?
Bon en définitive la version de rpmfusion fonctionne, l'akmod m'a bien construit le kmod qui va bien.
Ce qui m'a induit en erreur c'est que cela prend beaucoup plus de temps qu'avec l'avant dernier kernel : plus de trois minutes au lieu de 30 secondes.
Je pensai donc qu'il y avait un problème et j'arrêtai avant la fin de la construction.
Problème résolu.
chepioq wrote:Bon en définitive la version de rpmfusion fonctionne, l'akmod m'a bien construit le kmod qui va bien.
Ce qui m'a induit en erreur c'est que cela prend beaucoup plus de temps qu'avec l'avant dernier kernel : plus de trois minutes au lieu de 30 secondes.
Je pensai donc qu'il y avait un problème et j'arrêtai avant la fin de la construction.
Problème résolu.
Bon à savoir, merci chepioq. Je vais passer au niveau kernel et donnerai le retour.
Voilà, après mise à jour de Fedora avec dnf upgrade et installation du nouveau kernel 4.6.5-300, l'akmod a bien fait son boulot et m'a généré le kmod-nvidia correspondant au kernel.
C'est vrai, qu'apparemment, il a fallu un peu plus de temps que d'habitude pour rebooter et arriver sur ma session.

EDIT : Difficile à dire combien de temps en plus, car, perso, c'est la 1ère fois que j'update le kernel de F24 : 
$ rpm -qa kernel*
kernel-headers-4.6.5-300.fc24.x86_64
kernel-tools-libs-4.6.5-300.fc24.x86_64
kernel-modules-4.6.4-301.fc24.x86_64
kernel-4.6.4-301.fc24.x86_64
kernel-tools-4.6.5-300.fc24.x86_64
kernel-devel-4.6.5-300.fc24.x86_64
kernel-devel-4.6.4-301.fc24.x86_64
kernel-modules-extra-4.6.4-301.fc24.x86_64
kernel-modules-4.6.5-300.fc24.x86_64
kernel-modules-extra-4.6.5-300.fc24.x86_64
kernel-4.6.5-300.fc24.x86_64
kernel-core-4.6.4-301.fc24.x86_64
kernel-core-4.6.5-300.fc24.x86_64
et que je ne me souviens plus si sous F23 ça prenait moins de temps à compiler le kmod.
Voilà mes systemd-analyze time:
Avec le kernel 4.6.4-301 : 
# systemd-analyze time
Startup finished in 1.754s (kernel) + 3.911s (initrd) + 3.879s (userspace) = 9.545s
Lors du reboot avec le dernier kernel 4.6.5-300 et compilation du kmod : 
# systemd-analyze time
Startup finished in 1.744s (kernel) + 3.736s (initrd) + 55.650s (userspace) = 1min1.130ss
Nouveau reboot avec le dernier kernel : 
# systemd-analyze time
Startup finished in 1.762s (kernel) + 3.720s (initrd) + 3.297s (userspace) = 8.780s
Donc la compilation du kmod t'a pris environ 47 secondes, je n'ai pas eu le reflex de faire un systemd-analyze time, mais cela m'a semblé beaucoup plus long, peut-être pas 3 minutes mais bien 150 secondes.
Mais nous n'avons pas la même configuration matériel ni logiciel, c'est donc difficile de comparer.
Effectivement, j'ai un SSD, c'est bcp plus rapide. Et j'ai désactivé quelques services dont je n'ai pas besoin.

EDIT : 
# systemd-analyze blame
          3.143s plymouth-start.service
           771ms firewalld.service
           617ms dnf-makecache.service
           480ms akmods.service
           474ms accounts-daemon.service
           390ms dev-sda2.device
           311ms WD500\x2d3.mount
           292ms upower.service
           291ms lm_sensors.service
           284ms gssproxy.service
           283ms WD500\x2d4.mount
           280ms rsyslog.service
           279ms akmods-shutdown.service
           276ms cups.service
           252ms jexec.service
           162ms chronyd.service
           154ms user@1000.service
           151ms systemd-journal-flush.service
           142ms udisks2.service
           139ms systemd-vconsole-setup.service
           132ms rtkit-daemon.service
           131ms livesys.service
           117ms avahi-daemon.service
           114ms systemd-udev-trigger.service
           106ms systemd-logind.service
           104ms proc-fs-nfsd.mount
            86ms polkit.service
            85ms systemd-udevd.service
            66ms systemd-fsck@dev-disk-by\x2duuid-1f60902c\x2d9eab\x2d4e77\x2db0d1\x2db8a63a82288e.service
            64ms systemd-tmpfiles-setup.service
            63ms NetworkManager.service
            61ms systemd-tmpfiles-setup-dev.service
            55ms colord.service
            52ms plymouth-quit.service
            50ms fedora-import-state.service
            48ms fedora-readonly.service
            45ms proc-sys-fs-binfmt_misc.mount
            42ms plymouth-quit-wait.service
            39ms systemd-tmpfiles-clean.service
            38ms systemd-journald.service
            36ms blk-availability.service
            34ms rpc-statd-notify.service
            32ms auditd.service
            31ms dev-hugepages.mount
            31ms kmod-static-nodes.service
            30ms systemd-user-sessions.service
            28ms rc-local.service
            28ms systemd-remount-fs.service
            27ms tmp.mount
            23ms home.mount
            22ms sys-kernel-debug.mount
            22ms nfs-config.service
            21ms dev-disk-by\x2duuid-321712b7\x2da0c4\x2d4d8c\x2da093\x2d39a192d74959.swap
            20ms livesys-late.service
            19ms systemd-fsck-root.service
            15ms systemd-sysctl.service
            13ms systemd-update-utmp-runlevel.service
            13ms plymouth-read-write.service
            10ms var-lib-nfs-rpc_pipefs.mount
             6ms systemd-random-seed.service
             6ms systemd-update-utmp.service
             6ms dev-mqueue.mount
             5ms sys-fs-fuse-connections.mount
             5ms dracut-shutdown.service
             3ms sys-kernel-config.mount
lines 41-65/65 (END)
J'ai aussi un ssd, et j'ai moins de service que toi :
[dominique@host-192-168-1-2 ~]$ systemd-analyze blame
           484ms dev-sda5.device
           452ms akmods.service
           275ms accounts-daemon.service
           191ms rsyslog.service
           189ms netcf-transaction.service
           173ms systemd-backlight@backlight:acpi_video0.service
           168ms systemd-rfkill.service
           153ms systemd-journal-flush.service
           121ms systemd-vconsole-setup.service
            82ms auditd.service
            76ms upower.service
            71ms systemd-udev-trigger.service
            65ms systemd-binfmt.service
            63ms systemd-logind.service
            61ms avahi-daemon.service
            59ms NetworkManager.service
            59ms udisks2.service
            58ms systemd-udevd.service
            52ms systemd-fsck@dev-disk-by\x2duuid-d6ac0272\x2d538f\x2d4270\x2db1
            44ms user@1000.service
            42ms rtkit-daemon.service
            39ms polkit.service
            37ms lm_sensors.service
            36ms chronyd.service
            34ms systemd-fsck@dev-disk-by\x2duuid-22c530ab\x2db83f\x2d4d9b\x2d9c
            31ms systemd-tmpfiles-setup-dev.service
            27ms proc-sys-fs-binfmt_misc.mount
            25ms systemd-journald.service
            22ms systemd-tmpfiles-clean.service
            22ms systemd-sysctl.service
            20ms systemd-remount-fs.service
            20ms colord.service
            19ms systemd-fsck-root.service
            16ms sys-kernel-debug.mount
            16ms systemd-tmpfiles-setup.service
            13ms systemd-update-utmp.service
            13ms home.mount
            12ms boot.mount
            12ms wpa_supplicant.service
            12ms dev-disk-by\x2duuid-b70abe30\x2d94cc\x2d4886\x2da85b\x2dc1418d7
            10ms tmp.mount
             9ms dev-hugepages.mount
             9ms rpc-statd-notify.service
             8ms ecbd.service
             8ms dev-mqueue.mount
             5ms kmod-static-nodes.service
             4ms blk-availability.service
             4ms systemd-random-seed.service
             3ms systemd-update-utmp-runlevel.service
             3ms systemd-user-sessions.service
             3ms sys-fs-fuse-connections.mount
             3ms sys-kernel-config.mount
             1ms dracut-shutdown.service

[dominique@host-192-168-1-2 ~]$ systemd-analyze time
Startup finished in 1.307s (kernel) + 872ms (initrd) + 1.641s (userspace) = 3.821s
Dans l'ensemble, les mêmes services que les miens démarrent 2 x plus vite chez toi que chez moi ! Et je devrais encore faire le ménage dans certains services inutiles ...
Mon SSD ne serait pas optimisé ? C'est un SSD Crucial : 
smartctl -a /dev/sda
smartctl 6.5 2016-05-07 r4318 [x86_64-linux-4.6.5-300.fc24.x86_64] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family:     Crucial/Micron MX100/MX200/M5x0/M600 Client SSDs
Device Model:     Crucial_CT250MX200SSD1
Serial Number:    15010E68AFB5
LU WWN Device Id: 5 00a075 10e68afb5
Firmware Version: MU01
User Capacity:    250.059.350.016 bytes [250 GB]
Sector Sizes:     512 bytes logical, 4096 bytes physical
Rotation Rate:    Solid State Device
Form Factor:      2.5 inches
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   ACS-3 T13/2161-D revision 4
SATA Version is:  SATA 3.2, 6.0 Gb/s (current: 3.0 Gb/s)
Local Time is:    Thu Aug 11 13:07:59 2016 CEST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
Mais il est sur un port sata3 et non sata6, ce qui doit probablement expliquer qu'il est plus lent que le tien...

Ce qui me semble quand même bizarre c'est que chez moi il y a un akmods-shutdown.service et pas chez toi !

Bref, pas d'explication que la compil du kmod prenne autant de temps chez toi !
Je ne pense pas être sur un port sata6, vu que mon portable est âgé de 4 ans. 
# smartctl -a /dev/sda
smartctl 6.5 2016-05-07 r4318 [x86_64-linux-4.6.5-300.fc24.x86_64] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family:     Samsung based SSDs
Device Model:     Samsung SSD 840 PRO Series
Serial Number:    S12RNEAD322927E
LU WWN Device Id: 5 002538 550260a8c
Firmware Version: DXM04B0Q
User Capacity:    256 060 514 304 bytes [256 GB]
Sector Size:      512 bytes logical/physical
Rotation Rate:    Solid State Device
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   ACS-2, ATA8-ACS T13/1699-D revision 4c
SATA Version is:  SATA 3.1, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is:    Thu Aug 11 16:24:41 2016 CEST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
Mon ssd est un samsung 840 pro qui déjà deux ans d'age.

J'ai désactivé akmods-shutdown.service parce que cela prenait beaucoup de temps lors de l'extinction ou le redémarrage de mon ordi.

J'ai supprimé aussi plymouth, qui prend beaucoup de temps au démarrage et à l'extinction, juste pour avoir le logo fedora qui s'affiche (cela ne me semble pas nécessaire).
J'ai aussi désactivé firewalld.service, vu que j'ai un pare-feu efficace sur mon routeur.
Il y a un nouveau kernel dans updates-testing le 4.6.6-300
Pour tester je l'ai installé et regardé combien de temps prenait la construction et l'installation du kmod correspondant.
Résultat plus de deux minutes.
Franchement je ne comprends pas pourquoi, si quelqu'un a une vague idée, elle est la bienvenue.

Si je regarde dans /var/cache/akmods/akmods.log je vois ceci : 
2016/08/12 07:57:42 akmods: Checking kmods exist for 4.6.6-300.fc24.x86_64
2016/08/12 07:57:43 akmods: Building and installing nvidia-kmod
2016/08/12 07:57:43 akmods: Building RPM using the command '/sbin/akmodsbuild --target x86_64 --kernels 4.6.6-300.fc24.x86_64 /usr/src/akmods/nvidia-kmod.latest'
2016/08/12 07:59:53 akmods: Installing newly built rpms
2016/08/12 07:59:53 akmods: DNF detected
2016/08/12 08:00:03 akmods: Successful.
2016/08/12 08:00:46 akmods: Checking kmods exist for 4.6.6-300.fc24.x86_64
Je vois donc bien que la construction prend 2 minutes et 10 secondes, l'installation du kmod ne prenant que 10 secondes.
En étudiant d'un peu plus près /var/cache/akmods/akmods.log je m'aperçois que ce problème a commencé avec les kernels 4.6.xx, avec le dernier kernel en 4.5 pas de soucis : 
2016/07/02 17:39:12 akmods: Building RPM using the command '/sbin/akmodsbuild --target x86_64 --kernels 4.5.7-300.fc24.x86_64 /usr/src/akmods/nvidia-kmod.latest'
2016/07/02 17:39:39 akmods: Installing newly built rpms
La construction du kmod n'a demandé que 27 secondes

Tandis qu'avec le premier kernel en 4.6 
2016/07/15 07:28:07 akmods: Building RPM using the command '/sbin/akmodsbuild --target x86_64 --kernels 4.6.4-301.fc24.x86_64 /usr/src/akmods/nvidia-kmod.latest'
2016/07/15 07:30:16 akmods: Installing newly built rpms
La même construction demande 2 minutes et 9 secondes.
Et c'est la même chose pour tous les autres kernels en 4.6.

Je penche donc pour un bogue du kernel.
Chez moi : 
2016/08/11 11:10:18 akmods: Checking kmods exist for 4.6.5-300.fc24.x86_64
2016/08/11 11:10:18 akmods: Building and installing nvidia-340xx-kmod
2016/08/11 11:10:18 akmods: Building RPM using the command '/sbin/akmodsbuild --target x86_64 --kernels 4.6.5-300.fc24.x86_64 /usr/src/akmods/nvidia-340xx-kmod.latest'
2016/08/11 11:11:13 akmods: Checking kmods exist for 4.6.5-300.fc24.x86_64
2016/08/11 11:11:13 akmods: Building and installing nvidia-340xx-kmod
2016/08/11 11:11:13 akmods: Building RPM using the command '/sbin/akmodsbuild --target x86_64 --kernels 4.6.5-300.fc24.x86_64 /usr/src/akmods/nvidia-340xx-kmod.latest'
2016/08/11 11:11:57 akmods: Installing newly built rpms
2016/08/11 11:11:57 akmods: DNF detected
2016/08/11 11:12:07 akmods: Successful.
Donc chez toi pas de soucis avec le kernel 4.6.xx
Par contre je vois que tu utilises le driver 340xx, alors que chez moi c'est le 367.35.
Cela vient peut-être de là.(problème avec kernel 4.6. et driver 367.35)
chepioq wrote:Donc chez toi pas de soucis avec le kernel 4.6.xx
Par contre je vois que tu utilises le driver 340xx, alors que chez moi c'est le 367.35.
Cela vient peut-être de là.(problème avec kernel 4.6. et driver 367.35)
Oui, j'ai une carte graphique Nvidia GTX 260 : 
01:00.0 VGA compatible controller: NVIDIA Corporation GT200 [GeForce GTX 260] (rev a1)
Il faudrait voir si d'autres utilisateurs ont eu ce même problème avec un autre akmod, akmod-wl par exemple.