17-Encore des problèmes de clavier et de souris – MàJ de juin 2010

Là encore cela faisait 2 mois que je n'avais pas fait de mise à jour.

Le premier package concerné fût portage avec le passage à la version 2.1.8.3.

1 - "sys-fs/udev-149 is not a valid atom"

Ensuite je lance mon classique :

# emerge --update --deep world

et j'ai un « sys-fs/udev-149 is not a valid atom » qui bloque ma mise à jour, comprends pas ?

Un reboot plus tard, cette erreur n'apparaît plus, par contre j'ai :

• games-simulation/corewars-0.9.13-11 qui est masqué ==> j'ajoute au fichier /etc/portage/package.unmask, la ligne suivante :

  games-simulation/corewars

Et cela permet de le « démasquer » localement et donc de permettre son installation.

• mount-cifs bloque la mise à jour de Samba net-fs/mount-cifs ("net-fs/mount-cifs" is blocking net-fs/samba-3.4.6)==> je le supprime (pour l'instant) avec

  # emerge -C mount-cifs

Cette fois la mise à jour se déroule jusqu'au bout (170 packets !), mais lorsque je redémarre mon micro j'ai de nouveau le touchpad et le clavier qui ne fonctionnent plus.

2 - Je n'ai plus ni clavier, ni touchpad, problème de drivers ?

Comme indiqué en 12-Les passages à Xorg1.5 puis à Xorg1.6 plantent clavier et touchpad il faut toujours penser à jeter un œil sur les log, et voici ce que j'ai trouvé :

# vi /var/log/portage/elog/summary.log
...
>>> Messages generated by process 14919 on 2010-06-21 02:04:02 CEST for package x11-base/xorg-server-1.7.6 :
...
emerge portage-utils;
qlist -I -C x11-drivers/

J'exécute la dernière commande et une fois terminée, c'est mon Xorg (serveur graphique) qui ne démarre plus !!

3 - Xorg ne démarre pas, problème avec le module evdev ?

Là encore un regard sur les log, permet de cerner le problème.

# vi /var/log/Xorg.0.log
...
(II) Module evdev:
vendor= « X.Org Foundation »
	evdev modulecompiled for 1.6.5, module version =2.3.2
...
(EE) Failed to load
module « evdev » (module requirement mismatch, 0)

Je désinstalle xorg-server afin de le réinstaller.

Lors de la réinstall de xorg-server, j'ai une alerte sur le fait que compiler avec gcc 3.3.5 peut générer des erreurs, alors que j'ai gcc 4.4 ?!

Une vrai pelote de laine ! Mais là je fais une erreur, je désinstalle gcc et … sa recompil « failed tu run configure » à cause d'un « C compiler cannot create executables »

Le build.log se trouve sous /var/tmp/portage/sys-devel/gcc-4.4.3-r2/temp/build.log et le ebuild environnement sous /var/tmp/portage/sys-devel/gcc-4.4.3-r2/temp/environment

4 - Aie ! le compilateur ne compile plus ou « C compiler cannot create executables »

Sous Gentoo, c'est catastrophique puisque tous les paquets sont compilés que ce soit de nouvelles applications ou des mises à jour. Donc problème à résoudre absolument !

Et c'est reparti pour une visite des log. Le build.log me dit d'aller voir config.log qui me dit :

PATH:/usr/i686-pc-linux-gnu/gcc-bin/4.3.4
...
gcc-config: error: could not run/locate 'i686-pc-linux-gnu-gcc'
...

Sauf que 4.3.4 n'existe pas (je crois que c'est celle-là que j'ai désinstallée, j'avoue qu'entre 4.3.4 et 4.4.3 je ne sais plus), mais j'ai la 4.1.1 et la 4.4.3.

Après quelques recherches (et notamment ce lien "change-host" sur gentoo qui m'a bien aidé) je trouve un ls -al /etc/env.d/gcc curieux puisqu'il me donne (je n'ai pas reproduit les droits, les propriétaires la taille et la date) :

# ls -al /etc/env.d/gcc/
config-i686-pc-linux-gnu-4.4.3
i686-pc-linux-gnu-4.4.3
.NATIVE → i686-pc-linux-gnu-4.3.4

Je change le lien en .NATIVE → i686-pc-linux-gnu-4.4.3 et les compilations peuvent reprendre. Ouf !

D'autres liens utiles :

• Guide de mise à jour gcc sur Gentoo.org

• Migration de gcc sur Gentoo Québec

• Installing gcc de gcc.gnu.org (en anglais)

5 - Retour à mon xorg-server qui ne démarre pas

Je recompile donc mon xorg-server, puis mes drivers (emerge portage-utils; qlist -I -C x11-drivers/ )

Mais mon Xorg ne démarre toujours pas avec les mêmes erreurs que précédemment :

# vi /var/log/Xorg.0.log
...
(II) Module evdev: vendor= « X.Org Foundation »
	evdev modulecompiled for 1.6.5, module version =2.3.2
...
(EE) Failed to load
module « evdev » (module requirement mismatch, 0)
...
(EE) config/hal : NewInputDevice

Donc, je suis revenu dans le même état que celui d'avant la désinstallation de gcc (qui je le rappelle est une erreur à ne pas reproduire).

6 - Refaire le process de mise à jour

Bon jusqu'à présent, j'ai fait un peu du grand n'importe quoi. L'erreur au chargement du module « evdev » vient certainement de l'erreur initiale« sys-fs/udev-149 is not a valid atom ». Pour repartir sur une base plus propre je refais le process de mise à jour :

# emerge –sync
# emerge -u –deep world

J'en ai 18 nouvelles dont glibc-2.11.1. Cette fois c'est à la compilation de xulrunner (utilisé par Mozilla 1.9.2) que cela plante, avec ce message :

* ERROR:net-libs/xulrunner-1.9.2.4 failed.
* emake failed
* Call stack:
*              ebuild.sh, line 
	 54:  Called src_compile
*             environment, line 7287:  Called	_eapi2_src_compile
*              ebuild.sh, line  646:  Called die
* The specific snippet of code:
*              emake || die "emake failed"
*  The die message:
*   emake failed
*
* If you need support, post the output of
	'emerge –info =net-libs/xulrunner-1.9.2.4
* The complete build log is located at
	'/var/tmp/portage/net-libs/xulrunner-1.9.2.4/temp/build.log'.
* The ebuild environment file is located at
	'/var/tmp/portage/net-libs/xulrunner-1.9.2.4/temp/environment'.

Une recherche sur Google avec « xulrunner "emake failed" » donne :

• ce thread sur gentoo-quebec qui préconise de mettre la ligne MAKEOPTS= en commentaire (donc en la commençant avec le dièse #) afin d'éviter la compilation en parallèle (cf bugs-gentoo), mais cela ne change rien.

• Une autre préconisation est de mettre cette version en masked avec :

  # echo"=net-libs/xulrunner-1.9.2.4" >>/etc/portage/package.mask
  # emerge -av xulrunner

  Je n'ai pas testé car je pense que le problème vient de ma suppression un peu (très) sauvage de mon gcc.

7 - Et si la clé de mon problème venait de la résolution de « unable to open libstdc++.so.6 ». Où l'on reparle de la màj de gcc.

En fait lorsque je regarde mes différents build.log, je trouve systématiquement un « unable to open libstdc++.so.6 » car absente (ce que l'on vérifie aisément en regardant ce que l'on a sous /usr/lib/ moi j'avais libstdc++.so.5).

Sur cette page il est donné quelques exemples symptomatiques d'un gcc broken, et je retrouve les miens.

Il est notamment dit de vérifier la bonne configuration de son gcc par un :

# config-gcc -l

Malheureusement pour moi la réponse est :

* gcc-config: Active gcc
profile is invalid!
 [1]
i686-pc-linux-gnu-4.4.3

Pour y remédier :

# config-gcc 1
* Switching
native-compiler to i686-pc-linux-gnu-4.4.3
>>> Regenerating /etc/ld.so.cache
 * If you intend to use the gcc from the new profile in an already
 * running shell, please remember to do:
 *   # source /etc/profile

et suivre ce qui est dit :

# source /etc/profile

Ensuite, je n'ai pas retenté de suite un emerge (forcément long) de mes paquets à problème comme xulrunner ou xorg-server, mais j'ai suivi le début de cette page de gentoo sur changement de CHOST (même si je ne l'ai pas changé), en faisant :

# emerge -av binutils gcc glibc

Le guide de màj de gcc sur le site de Gentoo peut également être instructif. On y apprend que selon le type de changement de versions, la bascule est automatique ou pas. Ainsi considérons une version de gcc x.y.z.

• si z change, il s'agit d'une modification mineure, et le système bascule automatiquement

• si y change (et à fortiori x), la modification est majeure, et le système ne bascule pas automatiquement.

J'ai du être dans ce dernier cas, puisque j'ai supprimé la 4.3.4 alors que la dernière version compilée était la 4.4.3.

Il est également suggéré de mettre tous les paquets à niveau avec la nouvelle chaîne de compilation, par un :

# emerge -e system
# emerge -e world

Sur mon système, pas tout jeune, donc avec plein d'applications, je n'ose même pas imaginer le temps que cela prendrait. Heureusement que pour un système régulièrement mis à jour, ce n'est pas absolument nécessaire. Les 2 commandes suivantes peuvent suffire :

# emerge –oneshot -va libtool
# revdep-rebuild --package-names libstdc++

Pour les vérifications que tout est correct :

# gcc-config -l
 [1]
i686-pc-linux-gnu-4.4.3 *
# gcc-config -c
i686-pc-linux-gnu-4.4.3
# binutils-config -l
 [1]
i686-pc-linux-gnu-2.20.1 *
# binutils-config -c
i686-pc-linux-gnu-2.20.1

On peut également suivre toutes les vérifications données sur la page de gentoo sur changement de CHOST (déjà citée).

Bon cette fois côté gcc tout à l'air OK et la libstdc++.so.6 ne doit plus poser de problème.

Comme je pense que tout est correct, je relance une màj :

# emerge -u –deep world
# emerge –depclean
# revdep-rebuild

Le xulrunner est passé (le problème de la libstdc++.so.6 n'existe donc plus), des màj de lib ont été faites, je fais un :

# emerge xorg-server

pour être sûr de mon Xorg, et un startx lance mon interface graphique, Yesss !, malheureusement je n'ai toujours pas mon clavier et mon touchpad, Bouhhh !.

8 - Retour à la case : plus de clavier ni de touchpad

Un tour sur le /var/log/Xorg.0.log, montre que j'ai toujours un :

(II) Module evdev:
vendor="X.Org Foundation"
     compiled for 1.6.5, module version = 2.3.2
     Module class: X.Org
XInput Driver
     ABI Class: X.Org
XInput Driver, version 4.0
(EE) module ABI major version (4) doesn't match the server's version (7)

Une recherche sur google avec comme mots clefs : evdev "compiled for 1.6.5" "module version = 2.3.2" me donne cette page sur le forum.gentoo.org qui nous dit que le module evdev est compilé pour la version 1.6.5 de xorg.server alors que ce dernier est à la version 1.7.6. Il nous dit de recompiler evdev (en fait xf86-input-evdev), mais cela ne suffit pas car si j'ai le clavier (mais en anglais !) mon synaptics ne fonctionne pas. Non, en fait, il faut lancer la commande indiquée à la fin de la compilation de xorg-server :

# emerge portage-utils; qlist -I -C x11-drivers/

ou celle-ci :

# emerge -1a $(qlist -I -C x11-drivers/)

Ça y est cette fois tout refonctionne !

Que retenir de cet article ? L'erreur est normale, mais un peu plus de méthode aurait certainement évité tous ces détours.

De plus, cet article balaie un bon nombre d'erreurs liées à Xorg et à gcc, 2 piliers de cette distribution Gentoo.

Tout fonctionne ?, ... non pas tout à fait. Voir article suivant.