Merci.

Excellent article !

A+

Salut,

@zorglub844 : Oui, j'avais remarqué que c'étaient des initramfs. Par contre, je pense que si je veux gérer avec des initrd, il faudra que je gère ça tout seul et que je les recontruise à chaque mise à jour de nouyau, non ? D'un autre côté, si l'avenir est l'utilisation d'initramfs, j'augmenterai la taille de mon boot. C'est juste que j'aime comprendre ce qui se passe sur mon PC.

@loiseau : Ok, je vais me documenter un peu. Si je trouve des informations intéressantes, je les publierai sur ce fil.

Merci pour les infos.

A+

Bonjour,

Depuis une dizaine de jours, je n'arrivais pas à mettre à jour les paquets relatifs au noyau à cause d'un problème de place sur la partition de /boot.
J'ai une partition /boot d'environ 92 Mo partagée entre deux distributions, une F11 et une F12 (je fonctionne avec le couple FedoraN/FedoraN-1 depuis F9 et cette configuration ne m'a causé aucun souci jusqu'à présent).

Voici le message que j'avais lors d'un "yum update"

[root@mymachine ~]# yum update
Loaded plugins: presto, refresh-packagekit
Setting up Update Process
Resolving Dependencies
--> Running transaction check
---> Package kernel.x86_64 0:2.6.31.6-166.fc12 set to be installed
---> Package kernel-firmware.noarch 0:2.6.31.6-166.fc12 set to be updated
---> Package kernel-headers.x86_64 0:2.6.31.6-166.fc12 set to be updated
---> Package kmod-nvidia.x86_64 0:190.42-1.fc12.8 set to be updated
--> Processing Dependency: kmod-nvidia-2.6.31.6-166.fc12.x86_64 >= 190.42-1.fc12.8 for package: kmod-nvidia-190.42-1.fc12.8.x86_64
--> Running transaction check
---> Package kmod-nvidia-2.6.31.6-166.fc12.x86_64.x86_64 0:190.42-1.fc12.8 set to be updated
--> Finished Dependency Resolution

Dependencies Resolved

=============================================================================================================================
 Package                                     Arch          Version                    Repository                        Size
=============================================================================================================================
Installing:
 kernel                                      x86_64        2.6.31.6-166.fc12          updates                           20 M
Updating:
 kernel-firmware                             noarch        2.6.31.6-166.fc12          updates                          905 k
 kernel-headers                              x86_64        2.6.31.6-166.fc12          updates                          744 k
 kmod-nvidia                                 x86_64        190.42-1.fc12.8            rpmfusion-nonfree-updates         29 k
Installing for dependencies:
 kmod-nvidia-2.6.31.6-166.fc12.x86_64        x86_64        190.42-1.fc12.8            rpmfusion-nonfree-updates        2.2 M

Transaction Summary
=============================================================================================================================
Install       2 Package(s)
Upgrade       3 Package(s)

Total size: 24 M
Is this ok [y/N]: y
Downloading Packages:
Running rpm_check_debug
Running Transaction Test
Finished Transaction Test


Transaction Check Error:
  installing package kernel-2.6.31.6-166.fc12.x86_64 needs 5MB on the /boot filesystem

Error Summary
-------------
Disk Requirements:
  At least 5MB needed on the /boot filesystem.

J'ai réglé temporairement le problème en déplaçant les images des noyaux F11 sur une autre partition, en faisant mon "yum update" et en replaçant les images là où elles étaient à l'origine, une fois la mise à jour terminée.
Je pense que ce problème se répètera lors de la prochaine mise à jour du noyau, mais je verrai ça à ce moment-là.

Ma réflexion se porte plutôt sur les fichiers images (initramfs) des noyaux de f12. En effet, ces fichiers ont une taille d'environ 12 Mo là où ceux de f11 (initrd) font environ 3,5 Mo, ce qui fait un rapport de plus de 3 entre les deux. Je suppose que si la taille de ces fichiers étaient restée dans le même ordre d'idée, j'aurai pu attendre que mes petits-enfants installent à leur tour linux avant de voir ce problème :-D.
Quelqu'un sait-il pourquoi il y a une telle différence de taille entre ces fichiers qui, de mon point de vue profane, semblent faire la même chose ?

Merci pour votre aide.

A+

Après mise à jour de fedora, le "problème" subsiste.
J'ai lu quelque part sur le net que ça pourrait être lié à la nouvelle version de Xorg. Si c'est bien le cas, je suppose qu'une prochaine mise à jour de Xorg résoudra le problème.

Patience, donc...

Bonjour,

J'utilise WOW sous Fedora depuis que wine et nvidia me le permettent et cela fonctionne plutôt bien.
Depuis l'installation de fedora 11, j'ai un comportement non habituel mais qui n'empêche pas de jouer : lorsque j'appuie sur une touche de déplacement et que je la maintiens, mon personnage commence à avancer normalement puis, au bout d'une demi-seconde, il se met à "glisser" avec le pied gauche en avant. En fait, j'ai l'impression que c'est comme si le clavier n'envoyait plus le signal d'appui continu mais envoyait une succession d'appuis sur la touche, comme le fait la fonction de répétition du clavier. Si j'appuie sur une autre touche tout en maintenant la première et que je relâche cette autre touche, ça désactive la répétition et mon personnage se met à avancer normalement.

Est-ce que d'autres utilisateurs de WOW ont eu le même "souci" et, si oui, l'ont-ils résolu ?

Merci.
A+

Hello tout le monde.

Même problème ici sur mon Asus F9SG.
Jusqu'au noyau 2.6.27.15-170.2.24.fc10, le démarrage se passait normalement. Depuis le 2.6.27.19-170.2.35.fc10, lors du démarrage de udev, l'écran se met à la luminosité minimum sans possibilité de la modifier jusqu'à l'écran de login. Ensuite, avec les touche adéquates (Fn+F5 pour baisser l'éclairage d'un cran, puis Fn+F6 pour augmenter l'éclairage d'un cran sur mon portable) la luminosité revient au maximum (j'étais à la luminosité maximum lors de l'extinction de l'ordinateur).
Je pense qu'il faudrait se pencher sur l'exécution d'udev et voir s'il y a une action sur la luminosité pendant son lancement.
Note 1 : Lors d'un retour de mise en veille, l'écran est à nouveau en luminosité minimum et il faut à nouveau baisser d'un cran puis remettre la luminosité à fond.
Note 2 : Redémarrer avec le noyau 2.6.27.15-170.2.24.fc10 laisse la luminosité correcte pendant tout le boot (fonctionnemnt normal).

Question : Y a-t-il un moyen de savoir ce que fait udev ?

Merci
A+

Merci pmarion.

Je regarde ça et je vous tiens au courant.

A+

Personne n'a d'idée sur la question ?

A+

Bonjour,

Quelqu'un sait-il comment changer le greeter de GDM sous F10 pour en mettre un qui corresponde plus à ce que je cherche ?
En fait, les anciens greeter me conviennent plus que les récents. Je préfère ceux où les deux champs login/mdp existent et où l'on passe du champ login à mdp en appuyant une (seule) fois sur TAB.

Est-ce possible ?

A+

Bonjour,

plumachau wrote:j'ai des Kernel Panics

Avant d'aller sur des problèmes IPV6, il faudrait peut-être voir d'où viennent tes "Kernel Panics".
Peux-tu être plus précis (quand, comment, ce qu'il se passe ensuite) ?

Merci

Salut,

As-tu une carte nvidia ?

Si c'est le cas, je te renvoies vers un autre post où j'ai posé, je crois, le même problème que celui de ton écran noir et où j'en donne ma compréhension.

Si ton problème de départ est celui du son, je pense que le plus simple serait d'essayer de régler ce problème de son.

Sinon, si tu souhaites utiliser un des anciens noyau, essaie de désinstaller le dernier noyau et de réinstaller l'avant-dernier kmod-nvidia (kmod-nvidia-180.22-1.fc10.i686), en téléchargeant le rpm sur le site de rpm-fusion par exemple.

En espérant ne pas avoir été trop hors sujet.

A+

@pmarion

Voici les résultats des commandes, légèrement adaptées :

$ find /lib/modules/ -name nvidia.ko -exec ls -l {} \;
-rw-r--r-- 1 root root 7559700 2008-11-22 22:43 /lib/modules/2.6.27.5-117.fc10.i686/extra/nvidia/nvidia.ko
-rw-r--r-- 1 root root 7855624 2009-01-09 04:24 /lib/modules/2.6.27.9-159.fc10.i686/extra/nvidia/nvidia.ko
-rw-r--r-- 1 root root 7862428 2009-01-27 10:04 /lib/modules/2.6.27.12-170.2.5.fc10.i686/extra/nvidia/nvidia.ko

$ ls -l /boot/vmlinuz*fc10*
-rwxr-xr-x 1 root root 2570960 2008-11-18 18:30 /boot/vmlinuz-2.6.27.5-117.fc10.i686
-rwxr-xr-x 1 root root 2575088 2009-01-21 08:21 /boot/vmlinuz-2.6.27.9-159.fc10.i686
-rwxr-xr-x 1 root root 2575568 2009-01-21 08:21 /boot/vmlinuz-2.6.27.12-170.2.5.fc10.i686

Et voici mon interprétation :
Les noyaux et les modules sont bien là. J'ai réussi à booter sur le noyau 2.6.27.12-170.2.5 et le kmod-nvidia est fonctionnel.
Par contre, si je boote sur les deux autres noyaux, le kmod-nvidia de chaque noyau (qui est installé, comme on peut le voir) ne fonctionne plus.

Je pense que l'explication peut venir de la commande suivante (j'ai rajouté les ">" et "<" à la main):

$ yum list installed kmod-nvidia\*
Loaded plugins: refresh-packagekit
Installed Packages
kmod-nvidia.i686                              >180.25-1.fc10<   installed
kmod-nvidia-2.6.27.5-117.fc10.i686.i686        177.82-1.fc10.4  installed
kmod-nvidia-2.6.27.9-159.fc10.i686.i686        180.22-1.fc10    installed
kmod-nvidia-2.6.27.12-170.2.5.fc10.i686.i686  >180.25-1.fc10<   installed

Il doit y avoir une sorte de lien entre le noyau et le kmod-nvidia du noyau (qui doit contenir le fichier nvidia.ko) via le kmod-nvidia "général" (qui contiendrait le driver en soi). C'est une impression purement subjective de ma part. En regardant le contenu exact des paquets, on pourrait préciser un peu plus les choses.
Je pense que si je forçais la désinstallation du paquet kmod-nvidia-180.25-1.fc10.i686 et que je forçais l'installation du paquet kmod-nvidia-180.22-1.fc10.i686, j'aurais l'accélération nvidia sur le noyau 2.6.27.9-159 mais plus sur le noyau 2.6.27.12-170.2.5.

En tous cas, merci pour ta suggestion de commandes, cela me permet de poser le problème et de trouver (je crois) une certaine logique.

Bonne journée à tous.

Bonjour,

As-tu utilisé le même support (DVD) pour faire les différentes installations ? Si oui, essaie de réinstaller une des machines avec un LiveCD par exemple pour voir.

A+

Même problème ici.

Plus précisément : Le bluetooth fonctionne, mais les assistants permettant de le gérer ne fonctionne plus correctement. Par exemple, impossible d'associer un nouvel appareil via l'applet bluetooth car l'assistant ne détecte rien. Par contre, envoyer un fichier avec

$ bluetooth-sendto --dest 00:12:34:56:78:90 monfichier.jar

fonctionne correctement. Aussi, entrer

obex://[00:12:34:56:78:90]/

dans nautilus fait apparaître une demande de PIN sur mon téléphone. Une fois le PIN entré, un message d'erreur apparaît sur le PC disant "Connection refusée".

La mise à jour responsable de ce problème doit dater de la semaine dernière car je pense qu'avant l'association fonctionnait. J'arrivais encore à naviguer à travers le contenu de mon téléphone.
J'ai vu des chose sur le net qui incrimine bluez 4, mais je ne pense pas que ça soit lié car la version de base de la fedora 10 était la 4.17 (et on en est à la 4.19).
J'ai voulu tester un retour à bluez 4.17 mais je ne sais pas comment désinstaller bluez-libs 4.19 sans désinstaller 19 autres packages et je ne connais pas non plus les inter-dépendances de packages entre bluez, bluez-libs et le reste de la distribution. Si quelqu'un a des infos là-dessus, je suis preneur.

Merci d'avance pour votre aide.

A+

Salut,

J'ai déjà eu ce problème.
Voir mon post et la solution proposée ici.

A+

Salut,

Alors, mon observation peut être un peu simpliste mais d'un autre côté qui ne tente rien n'a rien ; l'option -f n'est-elle pas censée se trouver avant le point de montage ? Peut-être as-tu déjà essayé ? Dans ce cas, on aura définitivement écarté cette possibilité.

A+

Bonjour,

Avant de sortir l'artillerie lourde, j'ai essayé la manip de Sven. Pas de changement pour moi.

Donc, aux grands maux, les grands remèdes :

1- Désinstallation du driver synaptics actuel.

# yum remove xorg-x11-drv-synaptics

2- Exclusion de tous les paquets aparentés à synaptics des mises à jour de yum.

exclude=*synaptics*

ligne à ajouter aux configurations de dépôt suivantes :
- /etc/yum.repos.d/fedora.repo => [fedora]
- /etc/yum.repos.d/fedora-updates.repo => [updates]
- /etc/yum.repos.d/fedora-updates-newkey.repo => [updates-newkey]

3- Installation manuelle du driver synaptics de ATrpms téléchargé par le biais de rpm.pbone.net (lien ftp direct - en espérant que ce ne soit pas contraire à la charte du forum).

# rpm -ivh synaptics-0.14.6-8.fc9.i386.rpm

Résultat, mon touchpad fonctionne à nouveau correctement.

A+