Ports, dépanner
De Diablotins.org.
| Trousse de secours
|
| ||
| Et oui, parfois il arrive qu'un port ne fonctionne plus ! Les raisons peuvent être multiples ; ce qui suit n'est qu'un guide de premier secours.
Ayez du flair et dans la majorité des cas, le problème sera vite résolu. |
Sommaire |
Avant toutes choses
Pas de panique, ce sera pire.©
À vérifier chez vous
Vérifiez que votre arbre des ports est à jour, et reconstruisez le fichier d'index des ports.
En fonction de vos options, l'index peut ne plus correspondre à l'index standard, celui récupéré par:
cd /usr/ports && make fetchindex
Ceci parce que les options peuvent changer les dépendances.
Si vous utilisez ports-mgmt/portupgrade, soyez sûr d'avoir exécuté:
portsdb -Uu
et de ne pas avoir de problème de dépendances; consultez:
pkgdb -F
ou, pour ports-mgmt/portmaster:
portmaster --check-depends
Et bien sûr vous avez lu /usr/ports/UPDATING, non ?
À vérifier chez les autres
- Faites une recherche sur les listes du projet FreeBSD (ports@) et dans les «problem report» du projet. Le problème est peut être déjà connu.
- Regardez les journaux des machines de «build» du projet; ce sont des machines qui compilent en permanence les ports.
Aide toi, le ciel t'aidera !
Si les recherches n'ont rien donné, il ne vous reste plus qu'à mettre la main à la pâte. Même si vous ne trouvez pas - ça arrive -, cela vous permettra d'être plus précis, lorsque vous demanderez un coup de main.
Ça compile pô
Là encore on a plusieurs cas.
Problème de dépendance
Le port utilise un autre port mais a oublié de l'indiquer dans le Makefile du port, c'est un bug qu'il faut signaler.
Cela peut se voir à plusieurs niveaux : le
./configure
du port plante et dit qu'il manque quelque chose ou la compilation échoue parce qu'il manque un fichier include.
Si vous arrivez à déterminer le fichier manquant, l'astuce suivante permet souvent de trouver le port qui installe ce fichier :
find /usr/ports -name 'pkg-plist' -exec fgrep -H fichier_a_trouver {} \;
Cette commande examine tous les fichiers pkg-plist de l'arbre des ports à la recherche de 'fichier_a_trouver'. Cette méthode n'est pas fiable à 100% parce que la liste peut être générée dynamiquement, mais ça donne en général de bons résultats.
Par exemple vous avez un port qui ne compile pas parce qu'il ne trouve pas le fichier d'include “iconv.h”
find /usr/ports/ -name 'pkg-plist' -exec fgrep -H iconv.h {} \;
/usr/ports/converters/iconv/pkg-plist:include/biconv.h
/usr/ports/converters/libiconv/pkg-plist:include/iconv.h
[...]
À vue de nez, le port converters/libiconv est un bon candidat.
Voir aussi pkg_info(1) avec l'option -W, mais qui ne recherche que dans les ports installés.
$ pkg_info -W smbclient /usr/local/bin/smbclient was installed by package samba34-smbclient-3.4.5
Problème de liens (link)
Le programme compile mais ne trouve pas les bibliothèques nécessaires. Là encore, l'astuce de la recherche dans le pkg-plist rend service.
Autres problèmes de compilation
Aïe ! N'utilisez pas d'optimisations de compilation de la mort qui tuent, restez sur un CFLAGS en -O ou -O2, pas plus. Si le port a plusieurs options, essayez avec celles définies par défaut.
Au pire essayez de reconstruire le port et toutes ces dépendances:
portupgrade -Rf le_port
Si vous avez des notions de programmation, regardez les sources !
Il faut aussi savoir que des problèmes de compilations aléatoires (ça plante mais pas toujours au même endroit) sont souvent symptomatiques de problèmes matériels. Vérifiez alors la mémoire avant tout (ça m'est arrivé...).
Problème à l'exécution
problème de PERL
C'est un problème récurrent suite à une mise à jour du langage, libperl.so a disparu !
/libexec/ld-elf.so.1: Shared object "libperl.so" not found, required by "..."
Réinstaller le ou les logiciels qui le demande est généralement inutile, mais un
/usr/local/bin/perl-after-upgrade -f
suffit souvent à réparer le système.
Problème de bibliothèque
Le programme ne trouve pas une bibliothèque, il ne se lance pas.
Vous avez une erreur au lancement du programme (si c'est un programme graphique, lancez le dans un terminal genre xterm), l'astuce de la recherche dans la “pkg-plist” est utile ici aussi et il suffit d'installer le port manquant.
La commande ldd(1) et le port sysutils/libchk sont très utiles pour vérifier les liens et diagnostiquer les problèmes.
Autre cas plus rare, le programme émet une erreur comme quoi il ne trouve pas un symbole dans une bibliothèque : cela signifie qu'il n'est pas lié à la bonne bibliothèque ou qu'il y a un bug dans la bibliothèque...
Utilisez sysutils/libchk; si la bibliothèque est la bonne il n'y a plus qu'à appeler du secours.
Autres problèmes à l'exécution
Ça peut venir d'à peut prêt tout et n'importe quoi...
Si vous avez mis à jour le système de base vers une nouvelle version, il est recommandé de recompiler les ports. Principalement les commandes de bas niveaux proches du système, par exemple sysutils/cdrtools-devel.
Mais le programme peut avoir des bugs qui ne sont pas spécifiques à FreeBSD, là encore si vous avez des notions de programmation, essayez de déboguer le programme.
Parfois un
portupgrade -Rf
peut remettre les choses d'aplomb...
À l'aide
N'hésitez pas à demander de l'aide. Il y a de bonnes ressources sur FreeBSD. Et même un « chez moi ça marche © » peut faire avancer le bidule !
- Mailing liste sur les ports : http://lists.freebsd.org/mailman/listinfo/freebsd-ports
- Usenet : fr.comp.os.bsd
Soyez précis, plus vous donnerez d'informations et plus le problème sera facilement résolu.
Pour finir, les problèmes délicats sont -heureusement- plutôt rares.
Base corrompue
Vous mettiez à jour vos ports, mais:
- Une coupure de courant ?
- Votre petit(e) dernie(è)r(e) a appuyé sur le bouton rouge ( parce que c'est rouge ) de la multi-prises ?
- Vous étiez en train de faire mumuse avec la version bêta du pilote Nvidia ?
Et voilà un paquet de
pkg_info: corrupted record (pkgdep line without argument), ignoring
qui apparaissent...
Cherchez les responsables:
egrep '(pkgdep$|pkgdep $)' /var/db/pkg/*/+CONTENTS
ou
grep "^@pkgdep" /var/db/pkg/*/+CONTENTS | awk '{ if (NF != 2) { print $1 } }' | cut -d':' -f1
Et reinstallez les:
portmaster leport
ou
portupgrade -f leport
Exemples
Le monde est une bombe
Vous mettez régulièrement le monde de votre FreeBSD à jour.
Or en ce samedi pluvieux d'une froide journée de novembre,
le make installworld fut fatal à votre KDE.
La couche principale de KDE étant kdelibs:
portupgrade -f kdelibs
Et là, tout se passe bien, jusqu'aux liens avec les bibliothèques utilisées par kdelibs.
Patatra, kdelibs ne compile plus.
Premier réflexe, publier un appel au vaste monde:
«scours KDE marche pû »
sur les sites idoines [1] [2].
Seulement, KDE est plus qu'utile à ma station: il est nécessaire.
Regardant de plus près, le lien incriminé est celui de arts.
Sans perdre une seconde, je le recompile, lui et tout ce qui en dépend.
portupgrade -fr arts
Après quelques heures de compilation, tout est rentré dans l'ordre. J'ai enfin pu lire mes messages dont celui-ci:
The ctype fix for UTF-8 locale unfortunately introduced some new symbols to libc. Therefore, binaries built on system with that fix can not be used on older system. For that sake, the fix is back-out for 6-STABLE. If you see undefined symbols '__mb_sb_limit', please rebuild the affected binary. Everything will be fine then. Binaries built between 20071025 and 20071030 will be affected by this.
Owned.
Konqueror SIGSEGV
Si j'installe le port misc/konq-plugins-4.2.0, konqueror crash avec un SIGSEGV. Si je le dé-installe ça remarche !
Hmmmm...
Voyons voir le fichier core:
$ gdb -c konqueror.core /usr/local/kde4/bin/konqueror GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc.
Core was generated by `konqueror'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/local/kde4/lib/libkdeinit4_konqueror.so...(no debugging symbols found)...done. ... #0 0x2ec881f5 in QMutexPool::get () from /usr/local/lib/libqt-mt.so.3 [New Thread 0x2bc0e500 (LWP 100181)] [New Thread 0x2a3a8e00 (LWP 100180)] [New Thread 0x2a301100 (LWP 100147)] (gdb) bt #0 0x2ec881f5 in QMutexPool::get () from /usr/local/lib/libqt-mt.so.3 #1 0x2e9c109a in QMetaObjectCleanUp::QMetaObjectCleanUp () from /usr/local/lib/libqt-mt.so.3 #2 0x2ed3469a in __static_initialization_and_destruction_0 () from /usr/local/lib/libqt-mt.so.3 #3 0x2ed34a35 in __do_global_ctors_aux () from /usr/local/lib/libqt-mt.so.3 #4 0x2e8de741 in _init () from /usr/local/lib/libqt-mt.so.3 #5 0x2b924100 in ?? () #6 0x28070734 in ?? () from /libexec/ld-elf.so.1 #7 0xbfbfd178 in ?? () #8 0x2804e50c in dlsym () from /libexec/ld-elf.so.1 #9 0x2804ee9e in dlopen () from /libexec/ld-elf.so.1 #10 0x28fd3064 in QLibraryPrivate::load_sys () from /usr/local/lib/qt4/libQtCore.so.4 #11 0x28fce934 in QLibraryPrivate::load () from /usr/local/lib/qt4/libQtCore.so.4 #12 0x28fce97e in QLibrary::load () from /usr/local/lib/qt4/libQtCore.so.4 #13 0x28d8ff15 in KLibLoader::library () from /usr/local/kde4/lib/libkdecore.so.7 #14 0x2826ee73 in KParts::Plugin::loadPlugin () from /usr/local/kde4/lib/libkparts.so.5
libqt-mt.so.3 est une bibliothèque de qt3, normalement konqueror ne devrait utiliser que qt4. Qui est le fautif ?
Comme j'ai conservé la compilation de misc/konq-plugins-4.2.0, il est plus rapide d'aller y voir là bas. (Nb: le chemin /usr/pkg/usr est spécifique à ma machine, si vous n'avez pas changé le workdir des ports ce sera dans /usr/ports/...)
$ cd /usr/pkg/usr/ports/misc/konq-plugins-kde4/work/konq-plugins-4.2.0/lib
$ ldd ./*
./adblock.so:
libkparts.so.5 => /usr/local/kde4/lib/libkparts.so.5 (0x2819e000)
...
./akregatorkonqfeedicon.so:
libkonq.so.6 => /usr/local/lib/libkonq.so.6 (0x28300000)
...
libqt-mt.so.3 => /usr/local/lib/libqt-mt.so.3 (0x2b300000)
Bon c'est le plugin akregatorkonqfeedicon.so qui est mal linké. Maintenant il ne reste plus qu'à savoir pourquoi. Je vais signaler ça sur la mailing liste kde-freebsd@ de ce pas.
Et voilà la réponse :
The problem is that konq-plugins pickups libkonq from kdebase3. I'll surely fix it for upcoming kde-4.2.1. Or maybe sooner if I'll have time.
Merci Max !
