Bon ben je viens de regarder.
Je n'ai ni akmod-nvidia ni kmod-nvidia d'installé.
(Et j'ai bien une carte nvidia.)
Je veux bien tenter de réparer en installant un des deux mais lequel ?
yaumegui wrote:Bon ben je viens de regarder.
Je n'ai ni akmod-nvidia ni kmod-nvidia d'installé.
(Et j'ai bien une carte nvidia.)
Je veux bien tenter de réparer en installant un des deux mais lequel ?
Le pilote proprio nvidia n'est pas indispensable. Si tu ne l'as pas ( pas de kmod-nvidia ) tu fonctionnes avec le pilote nouveau ( c'est son nom ).
Tu n'as pas d'autres akmod installé ( comme akmod-wl par ex ) ?
Qu'a donné ton fichier /var/log/yum.log ?
Qu'a donne ton fichier /var/log/yum .log ?
Tu peux aussi booter sur l'ancien kernel et supprimer le nouveau kernel et le réinstaller.
@chepioq : Je n'ai pas percuté en lisant ton message, mais il est normal que la ligne "conflicts shutdown.target" apparaisse : elle indique simplement qu'avant que la phase d'extinction du système ne soit entamée, le service devra être arrêté/déchargé.

La piste que je donnais était au cas où il y aurait eu un conflit lié au moment où le service est lancé.

Après avoir activé le service créé par le nouveau fichier avec la commande "systemctl enable", supprimé ce qui le concernait sous /etc/rc.d/ et redémarrer mon système avec les 3 noyaux qui sont encore installés dessus, j'ai bien pu vérifier que l'erreur avec le service akmods était encore là.
La seule différence ? Elle est logiquement rapportée différemment, passant de : 
May 22 04:24:59 station systemd[1]: akmods.service: control process exited, code=exited status=128
May 22 04:24:59 station systemd[1]: Unit akmods.service entered failed state.
à : 
May 23 12:48:49 station kernel: [   59.130160] systemd[1]: akmods.service: main process exited, code=exited, status=128
May 23 12:48:49 station kernel: [   59.132284] systemd[1]: Unit akmods.service entered failed state.
J'essaierais de réinstaller l'akmod-nvidia plus tard pour vérifier si je constate le même souci que Fifi en conservant la gestion native avec systemd.

En remontant dans mes logs au moment où j'avais installé l'akmod-nvidia (avant de le désinstaller pour revenir à nouveau) j'ai remarqué que tout juste 5 minutes après (grosso-modo le temps de finir ce que je devais être en train de faire et de rebooter) l'erreur est présente... et je me souviens n'avoir eu qu'un souci de stabilité à l'utilisation, rien à l'installation ou au redémarrage après.

En fouillant un peu pour voir à quoi correspondait le code de retour qui est rapporté, on trouve dans le script akmods : 
finally()
{
    # remove tmpfiles
    remove_tmpdir
    # remove lockfile
    rm -f /var/cache/akmods/.lockfile
    exit ${1:-128}
}
trap "finally" ABRT EXIT HUP INT QUIT
la fonction n'étant appelée qu'à un autre endroit, en fin de script avec 0 en paramètre.
Le script semble être interrompu par un autre processus...
@ CanalGuada :
Eh ben, tu vas au fond des choses, toi ! Ça dépasse de beaucoup mes compétences. :-P
Fifi wrote:@ CanalGuada :
Eh ben, tu vas au fond des choses, toi ! Ça dépasse de beaucoup mes compétences. :-P
Et les miennes aussi...
Voilà l'extrait de mon /var/log/yum.log du jour de l'installation du kernel et suivants :
May 17 22:52:03 Updated: glibc-common-2.13.90-12.i686
May 17 22:52:08 Updated: glibc-2.13.90-12.i686
May 17 22:52:08 Updated: 12:dhcp-libs-4.2.1-8.P1.fc15.i686
May 17 22:52:08 Updated: 12:dhcp-common-4.2.1-8.P1.fc15.i686
May 17 22:52:09 Updated: gstreamer-tools-0.10.34-1.fc15.i686
May 17 22:52:10 Updated: gstreamer-0.10.34-1.fc15.i686
May 17 22:52:10 Updated: grep-2.8-3.fc15.i686
May 17 22:52:11 Updated: libdvbpsi-0.2.0-1.fc15.i686
May 17 22:52:11 Updated: 12:dhclient-4.2.1-8.P1.fc15.i686
May 17 22:52:15 Updated: vlc-core-1.1.9-2.fc15.i686
May 17 22:52:21 Updated: vlc-1.1.9-2.fc15.i686
May 17 22:52:22 Updated: gnome-dvb-daemon-0.2.0-1.fc15.i686
May 17 22:52:23 Updated: rsyslog-5.7.9-3.fc15.i686
May 17 22:52:24 Updated: ibus-anthy-1.2.6-1.fc15.i686
May 17 22:52:24 Updated: libisofs-1.0.8-1.fc15.i686
May 17 22:52:25 Updated: cifs-utils-4.9-2.fc15.i686
May 17 22:52:31 Installed: kernel-2.6.38.6-27.fc15.i686
May 18 19:58:08 Installed: gtkpod-1.0.0-3.fc15.i686
May 19 16:40:58 Updated: selinux-policy-3.9.16-24.fc15.noarch
May 19 16:41:53 Updated: selinux-policy-targeted-3.9.16-24.fc15.noarch
May 19 16:41:55 Updated: filesystem-2.4.41-1.fc15.i686
May 19 16:42:02 Updated: glibc-2.13.90-13.i686
May 19 16:42:13 Updated: glibc-common-2.13.90-13.i686
May 19 16:42:15 Updated: 12:dhcp-libs-4.2.1-9.P1.fc15.i686
May 19 16:42:15 Updated: 12:dhcp-common-4.2.1-9.P1.fc15.i686
May 19 16:42:16 Updated: authconfig-6.1.14-2.fc15.i686
May 19 16:42:17 Updated: authconfig-gtk-6.1.14-2.fc15.i686
May 19 16:42:17 Updated: 12:dhclient-4.2.1-9.P1.fc15.i686
May 19 16:42:20 Updated: sendmail-8.14.5-1.fc15.i686
May 20 13:01:02 Updated: hplip-common-3.11.5-2.fc15.i686
May 20 13:01:03 Updated: hplip-libs-3.11.5-2.fc15.i686
May 20 13:01:03 Updated: libsane-hpaio-3.11.5-2.fc15.i686
May 20 13:01:04 Updated: dash-0.5.6-4.fc15.i686
May 23 12:58:18 Updated: gnome-keyring-3.0.2-1.fc15.i686
May 23 12:58:19 Updated: python-smbc-1.0.11-1.fc15.i686
May 23 12:58:19 Updated: gnome-keyring-pam-3.0.2-1.fc15.i686
May 23 12:58:22 Updated: gnome-packagekit-3.0.0-5.fc15.i686
May 23 12:58:23 Updated: libgdata-0.8.1-1.fc15.i686
J'ai, depuis, un autre problème bizarre.
Ma machine redémarre quand je lui demande de s'éteindre...

Enfin, je dois avouer que la conversation me dépasse complètement.
Ça me fait un drôle d'effet d'avoir initié tout ça...
Bon ben j'ai un peu honte, j'hésite même à passer le sujet en [resolu], toujours est-il que, la tentation fut trop grande, avec la sortie officielle de ce jour, j'ai donc ré-installé.

Pas taper ! Le vilain monsieur il a gardé des mauvais réflexes, c'est mal...

Ça marche, inutile de le préciser.

J'espère juste que ce sujet (dont les réponses m'ont été pour le moins obscures je dois bien l'avouer) servira à quelqu'un.

En vous remerciant tous.

PS : je passe en [resolu] ou pas ?
@yaumegui : Je suis aussi sur une architecture i686, mais les versions de paquets que tu as indiquées ne correspondent pas à celles que j'ai encore aujourd'hui, avec des mises à jour quotidiennes depuis l'installation de la version alpha.
Je n'ai pas vérifié pour l'ensemble mais tu avais quelques paquets qui provenaient apparemment du dépôt Rawhide.

Si l'installation de la version officielle a résolu ton souci, je pense que tu peux passer le sujet en résolu. Et je te rassure : personne ne t'en voudras d'avoir des déboires avec une version bêta puis d'avoir installé la version stable 🙂


Pour revenir toutefois à certains détails concernant l'installation du pilote propriétaire, tout en conservant la gestion du script de démarrage akmods avec systemd mis en place précédemment, elle s'est déroulée chez moi sans souci majeur à l'aide du paquet akmod-nvidia, le kmod-nvidia ayant bien été construit au redémarrage.
Je me suis juste retrouvé comme Fifi avec nouveau qui n'était pas correctement blacklisté, malgré la présence des options pour le kernel et du fichier blacklist-nouveau.conf, tant que l'initrd n'a pas été reconstruit avec dracut.


Pour corriger le message d'erreur concernant le service akmods, j'ai modifié 2 lignes du script /usr/sbin/akmods que fournit le paquet akmods-0.3.6-3.fc12.noarch.

La ligne 108 de la façon suivante : 
trap "finally" ABRT HUP INT QUIT
Toute sortie de script, programmée par une commande exit ou pas, et quel que soit le traitement ayant été effectué, donnait lieu, en incluant le signal EXIT, à un appel supplémentaire systématique de la fonction finally fournissant ainsi à chaque fois le même code de retour correspondant à une erreur.

Et la ligne 178 de cette manière : 
        echo_success; echo; exit 0
En effet, s'il n'y a pas de kmod à construire et installer, il n'était pas non plus cohérent qu'un code d'erreur soit quand même renvoyé.

Si un développeur un peu plus expérimenté que moi pouvait lire le message et vérifier que je ne suis pas passé à côté de quelque chose...


@Fifi et chepioq : Pour peu que l'on soit curieux et que l'on dispose de temps, notamment pour apprendre de sa propre expérience, c'est assez aisé de finir par comprendre et mettre en oeuvre certains mécanismes sous Linux...
Même si je ne suis que tout jeune fédoriste (moins de 3 mois), pas développeur ou administrateur système de profession, du temps j'en ai eu pas mal depuis ma première expérience avec le manchot :-D
CanalGuada wrote:Je me suis juste retrouvé comme Fifi avec nouveau qui n'est pas correctement blacklisté, malgré la présence des options pour le kernel et du fichier blacklist-nouveau.conf, tant que l'initrd n'est pas reconstruit avec dracut.
Aaaaah, ouf, je ne suis pas le seul !
@Fifi et chepioq : Pour peu que l'on soit curieux et que l'on dispose de temps, notamment pour apprendre de sa propre expérience, c'est assez aisé de finir par comprendre et mettre en oeuvre certains mécanismes sous Linux...
Même si je ne suis que tout jeune fédoriste (moins de 3 mois), pas développeur ou administrateur système de profession, du temps j'en ai eu pas mal depuis ma première expérience avec le manchot big_smile
On voit ça ! 😉
Mais, perso, j'en suis encore loin !