Bonjour,
Ce matin (07/03/2008) j'ai exécuté la mise à jour proposée contenant en particulier le kernel 2.6.24.3-12.fc8.
Le redémarrage se bloque sur INIT: Sending processes the TERM signal. Bon reset et ca repart.
Mais surprise :
- ca boote sur l'ancien kernel (2.6.23.15-137). le paramètre "default" de grub.conf est passé à 1 au lieu du 0 initial.
- je reboote et force sur le dernier kernel et la ndiswrapper est inconnu
j'en déduis que cette mise à jour c'est mal passée mais je ne sais pas trop comment procéder pour revenir proprement à l'état antérieur.

un peu d'aide ne serait pas de trop :idea:
ndiswrapper est à quelle version ?
Peux-tu faire sous root un
cat /var/log/yum.log
ou
tail -n 40 /var/log/yum.log
Pour voir ce qui a été vraiment mis à jour.

Si tu as une carte graphique nvidia c'est kmod-ndiswrapper dont tu veux parler, alors le kmod-ndiswrapper et autres dépendances sont disponibles depuis ce matin 11 heures.
Je viens juste de m'apercevoir de la disponibilité d'une nouvelle version de ndiswrapper, dont acte je l'ai installé.
Après reboot sur le nouveau kernel c'est OK.

Pour info,
log de la premiere maj 
Mar 07 09:18:33 Updated: setroubleshoot-plugins - 2.0.4-4.fc8.noarch
Mar 07 09:18:51 Updated: tzdata - 2007k-2.fc8.noarch
Mar 07 09:18:56 Updated: audit-libs - 1.6.8-2.fc8.i386
Mar 07 09:18:59 Updated: krb5-libs - 1.6.2-13.fc8.i386
Mar 07 09:19:00 Updated: libtirpc - 0.1.7-15.fc8.i386
Mar 07 09:19:01 Updated: taglib - 1.5-1.fc8.i386
Mar 07 09:20:39 Updated: evolution - 2.12.3-3.fc8.i386
Mar 07 09:20:50 Updated: audit - 1.6.8-2.fc8.i386
Mar 07 09:20:53 Updated: audit-libs-python - 1.6.8-2.fc8.i386
Mar 07 09:20:57 Updated: krb5-workstation - 1.6.2-13.fc8.i386
Mar 07 09:22:10 Installed: kernel - 2.6.24.3-12.fc8.i686
Mar 07 09:22:11 Updated: synaptics - 0.14.6-2.fc8.i386
log de la seconde, qui semble-t-il rectifie le mande du module ndiswrapper. 
Mar 07 11:17:12 Updated: kmod-ndiswrapper - 1.52-2.lvn8.1.i686
Mar 07 11:17:36 Installed: kmod-ndiswrapper-2.6.24.3-12.fc8 - 1.52-2.lvn8.1.i686
Par contre je voudrais bien savoir pourquoi et par qui le paramètre "default" de grub.conf a été positionné à 1, ce qui fait que je rebootais toujours sur l'ancien kernel 2.6.23.15-137.
Peux-tu aussi me dire quel est le sens de obsoletes = 1 dans yum.conf.

Merci
Pour le 'default' de grub.conf, je n'ai pas de réponse et même je trouve cela étrange.
Pour le 'obsoletes' de yum.conf
man yum.conf
Bonjour,

quand il y a des mises à jours de noyau et qu'on a des pilotes particuliers de cartes graphiques, il est conseillé d'attendre le lendemain pour faire la mise à jour. En général tout est à jour à ce moment-là (la preuve, ce matin à 11 heures c'était bon).

Pour le changement de "default" c'est normal. Le grub.conf ou le menu.lst (chez moi c'est le deuxième), sont modifiés pour prendre en compte le dernier noyau et le précédent. La modification est faite de telle façon que le boot se fasse sur le noyau le plus récent. En général ça convient à la majorité des gens (sinon pourquoi mettre à jour ?). Pour les autres, un petit tour dans le fichier, on remet son défaut préféré et ça roule.
Je crois que la question pour grub est de savoir pourquoi il bootait sur l'avant dernier et on pas le dernier noyau.
pmarion wrote:Je crois que la question pour grub est de savoir pourquoi il bootait sur l'avant dernier et on pas le dernier noyau.
:-? oups, j'ai mal lu, désolé.

Bon ben allez-y, c'est ma tournée :pint:
pmarion wrote:Je crois que la question pour grub est de savoir pourquoi il bootait sur l'avant dernier et on pas le dernier noyau.
Peut-être un programmeur intelligent a-t-il pensé qu'il ne convenait pas de mettre par défaut le noyau le plus récent s'il n'arrivait pas à booter ?
nouvo09 wrote:Peut-être un programmeur intelligent a-t-il pensé qu'il ne convenait pas de mettre par défaut le noyau le plus récent s'il n'arrivait pas à booter ?
Le problème des mises à jour kmod-nvidia non synchrones avec le kernel, est que le boot se déroule normalement, mais que l'interface graphique ne peut pas fonctionner. Le boot se déroule bien, mais on est obligé de repasser avec un vieux xorg.conf de type 'vesa' que toute personne prudente grade au chaud dans son /etc/X11.
Mais s'il y a un programmeur intelligent pour détecter cela et passer en vesa automatiquement ou rebooter sur l'ancien noyau, alors je suis preneur de la solution.
Même soucis que Tokamak avec la même mise à jour !

Ce matin, mise à jour du PC portable, il reste bloquer au même endroit. Du coup, redémarrage volontaire sur l'ancien noyaux (j'ai pas testé s'il repartait de lui même sur l'ancien)

Même mise à jour sur le PC fixe, là ça boot. Par contre, je retrouve un problème déjà rencontré par le passé: plus de connections wifi avec le nouveau kernel !
Je décide donc de faire comme les précédentes fois où ça s'est produit: reboot sur l'ancien noyaux, et on attend sagement une nouvelle mise à jour qui corrigera tout ça.. Mais cette fois ci, toujours pas de wifi de retour sous le précédent noyaux ! gurgl !
Après un rapide check, je découvre qu'il m'a renommé mon profil réseau en wlan0.bak, et m' a pondu un nouveau wlan0 où toutes les valeurs sont par défaut. Plus d'IP fixe, plus de clef wap, etc, ...
Bref, je l'efface et renomme le .bak en wlan0: marche toujours pô ! raaaaaaah Dans le .bak, il a bien sauvegarder tous mes paramètres perso, sauf la clef wap ?!?!? Ben quoi, qu'est ce qu'elle a ma clef wap, il ne l'aime pas ?
Une fois remise, ça remarche . Ouufffff !

Conclusion: la prochaine fois que je vois une mise à jour du kernel, j'attendrai le surlendemain pour la faire !
Même chose pour moi. Depuis ce matin je bataille pour essayer de refaire fonctionner ma FC8 avec le nouveau kernel. J'ai du connecter ma machine par cable ethernet et récupéré la mise à jour lvna kmod ndiswrapper qui est maintenant disponible, mais depuis plus moyen de booter, ni sur le nouveau ni sur l'ancien kernel. Grub me dit uncompressing kernel et après le système repart pour un nouveau cycle de reboot.
J'avoue que je n'ai pas trop envie de me plonger dans le débugage de grub et de l'image ... mais ais-je le choix?
Je viens de passer à cette nouvelle version du kernel sur mon laptop... Aucun problème au redémarrage... J'ai l'impression que le WiFi ne fonctionne toujours pas mais d'un côté, c'est pas nouveau :hammer: J'y arriverai :pint:
Ouf ça y est c'est reparti avec les bonnes vielles erreur au démarrage:
Mar 7 14:40:12 localhost kernel: usb 4-1: new full speed USB device using uhci_hcd and address 2
Mar 7 14:40:12 localhost kernel: usb 4-1: device descriptor read/64, error -71
Mar 7 14:40:12 localhost kernel: usb 4-1: device descriptor read/64, error -71
Mar 7 14:40:12 localhost kernel: usb 4-1: new full speed USB device using uhci_hcd and address 3
Mar 7 14:40:12 localhost kernel: usb 4-1: device descriptor read/64, error -71
Mar 7 14:40:12 localhost kernel: usb 4-1: device descriptor read/64, error -71
Mar 7 14:40:12 localhost kernel: usb 4-1: new full speed USB device using uhci_hcd and address 4
avant le blocage pendant plusieurs minutes sur le démarrage de Udev
ce qui est je pense la cause du remplissage du log avec le message suivant:
usb 1-4: reset high speed USB device using ehci_hcd and address 3
mais après j'ai pu récupérer le wifi 🙂
3 mois plus tard
Merci pour l'info Herrib, je pense que ça me sera utile tôt ou tard.

J'ai fait migré le PC portable cité plus haut vers FC9 (install complète, et propre, pas part upgrade), ça s'est passé au poil. Et devinez où ça a coincé ? Le wifi ! Mais rien d'insurmontable cette fois ci, en vingt minutes, c'était réglé. Ouf !!!