--- layout: page title: Foire Aux Questions LFS use-site-title: true ---
La FAQ est divisée en trois documents. La FAQ générale propose des liens vers toutes les questions et les réponses. La FAQ LFS est une sélection des questions les plus fréquemment posées concernant LFS et la FAQ BLFS est une sélection des questions les plus fréquemment posées spécifiques à BLFS.
Depuis LFS-5.0, publiée le 5 novembre 2003, LFS utilise Grub plutôt que Lilo. Grub a été choisi parce qu'il n'a pas besoin d'être réinstallé après une mise à jour du noyau et a une très bonne console de secours.
Si votre installation actuelle utilise LILO ou si vous souhaitez l'utiliser malgré tout, vous pouvez, mais soyez conscients que vous devrez aussi installer BIN86 et, pour les dernières versions de LILO, NASM. Cependant, ne prêchez pas cela sur les listes de diffusion de LFS, car nous avons déjà eu des discussions enflammées à ce propos.
Marc Heerdink l'a sans doute mieux dit dans un post sur lfs-dev :
Le problème c'est que la FAQ est un document dynamique. La FAQ pour une version du livre n'est publiée qu'après le livre, car la FAQ est mise à jour pour refléter les question posées à propos de la version actuelle du livre. Un lien c'est mieux, car vous aurez toujours la dernière information à jour à portée de main.
Ça a bien été discuté dans le fil qui commence par http://linuxfromscratch.org/pipermail/lfs-dev/2002-February/023030.html.
La version de binutils que vous trouverez sur ftp.gnu.org est généralement appelée le binutils de la « FSF ». Un hacker émérite, H. J. Lu, publie aussi un binutils en dehors du dépôt CVS principal et ces versions sont appelées les binutils « HJL » et peuvent souvent être trouvées sar ftp.kernel.org. Des débats éclatent souvent à propos de quelle version utiliser à cause du fait que la plupart des distributions connues utilisent plutôt les version HJL bien qu'elles sont souvent marquées « beta ».
Voici notre interprétation sur les différences entre les deux :
Vous remarquerez dans les arguments ci-dessus des mots comme « habituellement » et « parfois ». Cela montre que la situation peut différer en fonction du moment auquel on se réfère. Par exemple, de temps en temps il y a une nouvelle fonctionnalité dans gcc ou glibc qui requièrent un support de binutils. Pendant ces périodes, vous entendrez souvent les développeurs dire « vous devez utiliser la dernière version HJL de binutils x.y.z.a.b ».
La seule manière de choisir correctement la version la plus appropriée à utiliser est de :
Le vrai problème c'est que les paquets du cœur de la chaîne d'outils sont tous très liés entre eux et doivent être testés pour s'assurer qu'ils fonctionnent ensemble. Vous devez en gros construire une distribution complète et la tester sous toutes les coutures avant d'être satisfait.
Si vous suivez les listes de diffusion des paquet du cœur de la chaîne d'outils suffisamment longtemps, vous comprendrez que les développeurs ne se soucient pas vraiment qu'une version particulière du « Paquet A » fonctionne avec une version particulière du « Paquet B ». En d'autres termes, la coordination des publications entre les projets n'est pas la priorité. En réalité, cela signifie que Alan Cox a raison lorsqu'il dit que vous ne pouvez pas simplement aller sur ftp.gnu.org et récupérer les dernière version de tout ce qui s'y trouve et vous attendre à ce que ça marche.
La gestion des paquets — au-delà de ce qui est fournit par des archives et des makefiles — est en dehors de la portée du livre. Si rien d'autre ne vous convainc, le nombre de « solutions » différentes devrait vous aider à en comprendre la raison.
Voici quelques possibilités :
Si vous avez quelque chose à rajouter à la liste, merci d'envoyer son id, URL, et d'autres informations, au mainteneur de la FAQ ou à une liste de diffusion appropriée pour que ça soit ajouté.
La gestion de l'énergie est une fonctionnalité du noyau, vous devez
l'activer dans le noyau. Dans le noyau 2.4, vous devez active les options
pour Power Management Support
dans General
Setup
. Pour les vieilles machines, vous voudrez sans doute les
options APM, les nouvelles machines requièrent souvent ACPI. Assurez-vous
que soit APM soit ACPI soit activé dans le noyau, mais
jamais les deux en même temps — c'est connu pour poser
des problèmes comme par exemple aucun ne fait d'effet. Essayez aussi de
désactiver SMP si vous n'avez qu'un processeur ; il est connu pour
empêcher l'extinction propre. Assurez-vous de lire l'aide de chaque option.
Après avoir redémarré dans le nouveau noyau vous devriez être capable
d'éteindre votre machine avec la commande shutdown -h now
ou
poweroff
(lisez aussi man shutdown
et man
halt
). Si vous compilez APM ou ACPI en tant que modules, assurez-vous
qu'ils soient chargés avant d'essayer d'éteindre la machine. Certaines
machines requièrent que APM ou ACPI soit compilé dans le noyau car ils
doivent être initialisés au démarrage.
La plupart des distributions relativement récentes devraient fonctionner. N'utilisez pas Fedora Core 4 car sa version de GCC ne fonction pas avec la versions stable actuelle de LFS. Assurez-vous d'avoir installé ou mis à jour les paquets de développement. (Recherchez ceux qui commencent par « gcc », « glibc » ou « libstdc++ » ou qui finissent par « -dev »). Si vous souhaitez utiliser LFS comme système principal et souhaitez l'installer sans d'abord installer une distribution, essayez Knoppix.
En plus de la documentation du noyau sur /usr/src/linux/Documentation ou là où vous avez décompressé les sources du noyau et de l'aide dans l'outil de configuration du noyau (make menuconfig), voyez le Module-HOWTO sur http://www.tldp.org/HOWTO/Module-HOWTO/.
Réponse courte : non.
Répons longue : sans doute, mais seulement pour quelqu'un qui travaille sur le paquet que vous essayez de compiler. Généralement, tout ira bien à moins que make ne quitte en erreur.
Voici un exemple :
sk ~/tmp $ cat > Makefile
main:
gcc main.c
sk ~/tmp $ cat > main.c
void main() { exit(0); }
sk ~/tmp $ make
gcc main.c
main.c: In function `main':
main.c:1: warning: return type of `main' is not `int'
sk ~/tmp $ ######## ça a fonctionné ########
sk ~/tmp $
sk ~/tmp $ cat > main.c
int main() { exxit(0) }
sk ~/tmp $ make
gcc main.c
main.c: In function `main':
main.c:1: parse error before `}'
make: *** [main] Error 1
sk ~/tmp $ ######## ça a échoué ########
sk ~/tmp $
Gerard a décrit comment créer une installation LFS de 5 Mo dans un courriel sur lfs-support et il y a des liens vers plusieurs ressources dans un post de Cor Lem et une réponse.
Pour des informations sur la construction de LFS pour une vaste catégorie de systèmes, regardez Cross LFS.
Pour les systèmes Alpha, Kelledin maintient une liste de correctifs pour la construction sur la la plateforme Alpha sur http://skarpsey.dyndns.org/alpha-lfs/alpha.html.
Il est souvent utile de compiler LFS pour une machine sur une autre machine. Disons que vous utilisez ce véloce Athlon 1 GHz pour construire et installer sur un vieux 486. Bien que ça ne soit pas techniquement de la compilation croisée, les binaires compilés sur l'Athlon ne peuvent pas être lancés sur le 486 car les binaires compilés sur les nouveaux processeurs utilisent des fonctionnalités que les vieux processeurs n'ont pas.
Le livre LFS spécifique à la compilation croisée est le livre Cross-LFS. Une autre source d'information serait l'astuce sur la compilation croisée.
Cela a à voir avec les caractères en fin de ligne.
Il y en a deux qui sont utilisés :
Unix, DOS et MacOS utilisent chacun une combinaison différent pour terminer les lignes des fichiers textes :
Pour convertir du format DOS à Unix, utilisez
cp <fileid> <fileid>.dos &&
cat <fileid>.dos | tr -d '\r' > <fileid>
Ou dans vim
, vous pouvez convertir un fichier avec :set
ff={unix, dos, mac}
. Les autres conversions demanderont sans doute
sed ou une utilisation différente de tr et sont laissé en exercice au
lecteur.
Oui. Vous pouvez télécharger le fichier LFS-BOOK-x.y-wget-list sur
http://www.linuxfromscratch.org/lfs/downloads/stable. Pour télécharger
tous les fichiers, utilisez la version de wget
de votre
distribution hôte et lancez :
wget --input-file=LFS-BOOK-x.y-wget-list
Les correctifs de GNU ne marchent pas en général. Vous pouvez soit télécharger l'archive complète et essayer de nouveau, soit essayer la solution proposée par Gerard Beekmans :
Le problème est que les scripts marqués exécutables sont corrigés aussi et ils perdent leur bit exécutable, donc vous ne pouvez plus les exécuter jusqu'à ce que vous lanciez « chmod +x » dessus (ou quelque chose de similaire comme chmod 755) avant d'installer Glibc. Essayez chmod +x glibc-2.2.5/scripts/* (je ne suis pas 100% sûr des chemins mais ça devrait être évident à trouver en lançant « ls » dans le répertoire glibc-2.2.5).
Si vous obtenez des erreurs et que vous initialisez CFLAGS ou changez les paramètres d'optimisation du compilateur, cela pourrait être le problème.
Si vous demandez sur la liste et qu'ils ne trouvent pas tout de suite, ils vous suggéreront sans doute d'essayer sans optimisation. Donc si vous réessayez seulement sans demander, vous aurez un coup d'avance sur eux :)
Il est important de noter qu'optimiser binutils, gcc ou glibc peut provoquer des échecs à la compilation ou au lancement d'autres paquets ou les faire se comporter de manière étrange et mystérieuse. Aussi, une optimisation qui fonctionne pour quelqu'un d'autre peut ne pas fonctionner pour vous. Les drapeaux qui marchaient peuvent mystérieusement arrêter de fonctionner. Même de petits changements innocents dans le matériel peut faire la différence.
(Si vous ne savez pas ce que sont les drapeaux d'optimisation, ne vous en faîtes pas, vous n'avez vraiment pas besoin de savoir.)
Vous avez sur-optimisé gcc.
Oui. En général on ne peut pas compter sur make clean
ou
make dist-clean
pour nettoyer les sources. Surtout quand vous
avez modifié les sources à la main ou appliqué un correctif, vous devriez
essayer de nouveau avec un paquet fraîchement décompressé. La seule
exception à cette règle est le noyau linux, qui requière que ses sources
soient présentes lorsque des modules tiers, comme ceux des pilotes NVidia,
sont requis.
Est-ce que /dev/null ressemble à ça :
$ ls -l /dev/null
crw-rw-rw- 1 root root 1, 3 Aug 3 2000 /dev/null
Si non, il devrait. Regardez les pages de manuel de chmod(1), chown(1) et mknod(1) et /usr/src/linux/Documentation/devices.txt si vous avez besoin d'aide pour corriger ça.
Si ça semble juste, le problème est probablement vos options de montage. Regardez la réponse à « ./configure: bad interpreter: Permission denied », au dessus.
La réponse longue se trouve sur http://www.bitwizard.nl/sig11/.
La répons courte est que si redémarrer make avance un peu à chaque fois, vous avez un problème matériel. (Si make ou quoi que ce soit que vous lanciez, échoue au même endroit à chaque fois, ce n'est pas matériel).
En supposant que vous n'êtes pas overclocké, le problème matériel le plus probable est une mauvaise mémoire que vous pouvez vérifier avec Memtest86 de http://www.memtest86.com/. Si ça n'est pas ça, regardez la répons longue.
Des exemples de cette erreur sont :
/usr/bin/env: /tools/bin/bash: No such file or directory
gcc: No such file or directory
Cela signifie généralement une coquille dans l'installation de GCC Pass 2. Pour les anciennes versions de LFS, la cause principale été d'oublier d'appliquer le correctif à specs.
Ce qui se passe, c'est que le chemin du chargeur de lien dynamique inclus
dans l'exécutable pointe toujours sur /lib/ld-linux.so.2 et lorsqu'on lance
le binaire dans le chroot où /lib/ld-linux.so.2 n'existe pas encore, le
message d'erreur peu explicite No such file or directory
apparaît.
Vous pouvez tester cela avec readelf -l {binary} | grep
interpreter
. Sa sortie devrait être Requesting program
interpreter: /tools/lib/ld-linux.so.2
.
Vous avez oublié de cd
dans le répertoire extrait du paquet
après l'avoir extrait.
Vous obtenez probablement ça en construisant binutils dans le chapitre 5 du livre LFS. Le problème est probablement vos options de montage. Vous avez sans doute une ligne dans /etc/fstab qui ressemble à :
/dev/hda10 /mnt/lfs ext2 user 1 2
« user » est un drapeau de montage, et ce n'est pas le problème. Pour citer la page de manuel de mount :
user: Permet à une utilisateur ordinaire de monter le système de fichiers. Cette option implique les options noexec, nosuid et nodev (à moins d'être écrasé par les options suivantes, comme dans la ligne d'options user,exec,dev,suid).Donc changez la ligne dans /etc/fstab ainsi :
/dev/hda10 /mnt/lfs ext2 defaults 1 2
Les symptômes typiques ressemblent à ceci :
sk ~/tmp-0.0 $ ./configure
creating cache ./config.cache
checking host system type...
configure: error: can not guess host type; you must specify
one
sk ~/tmp-0.0 $
Le problème est généralement que le script ne peut pas lancer le compilateur. Généralement c'est juste un lien symbolique /usr/bin/cc manquant. Vous pouvez le modifier ainsi :
cd /usr/bin && ln -s gcc cc
Si ça ne marche pas, vérifiez le fichier config.log créé par configure. Les erreurs sont enregistrées là et peuvent indiquer le problème.
Si vous obtenez une erreur de configure comme ça :
checking whether we are using GNU C... no
configure: error: GNU libc must be compiled using GNU CC
Cela pourrait signifier que egrep ne fonctionne pas. Comme egrep est un script shell qui appelle grep, cela signifie qu'il y a un problème avec grep.
Pour tester si grep fonctionne avant de réinstaller le paquet grep dans le chapitre 6, lancez la commande suivante depuis l'extérieur du chroot :
file $LFS/bin/grep
Si ça n'indique pas statically linked
, vous avez un problème et
devez réinstaller le paquet grep conformément aux instructions du chapitre
5.
Pour tester si egrep fonctionne après avoir réinstallé le paquet grep dans le chapitre 6, lancez la commande suivante depuis l'intérieur du chroot :
egrep root /etc/passwd
Si cela n'affiche pas la ligne de root du fichier /etc/passwd, de nouveau, vous avez un problème. (Ce test fonctionne aussi si vous rencontrez un problème après avoir redémarré dans votre nouveau système LFS).
Si vous lancez
expect -c "spawn ls"
et obtenez cette erreur :
The system has no more ptys.
Ask your system administrator to create more.
alors votre distribution Linux n'est soit pas configurée pour utiliser les PTY Unix98 soit pour utiliser le système de fichiers /dev/pts.
La solution peut demander de recompiler votre noyau. Tout d'abord allez dans le répertoire des sources de votre noyau et regardez le fichier .config. Si vous ne trouvez pas le fichier .config et que vous tournez sur un noyau précompilé installé avec rpm, apt-get ou ce que votre distribution utilise, alors vous devrez trouver du support auprès de la FAQ, des listes de diffusion ou les canaux IRC de votre distribution.
Si vous avez un fichier .config, cherchez dedans les deux option suivantes :
CONFIG_UNIX98_PTYS=y
CONFIG_DEVPTS_FS=y
Si l'une des deux a « n » au lieu de « y », alors changez-la et recompilez le noyau.
Si elles sont toutes les deux à « y », alors vous n'aurez probablement pas besoin de recompiler le noyau.
Ensuite, nous devons nous assurer que le système utilise bien les PTY Unix98 et le système de fichiers /dev/pts.
Tout d'abord, cherchez un périphérique nommé /dev/ptmx. S'il n'existe pas, créez-le avec :
mknod /dev/ptmx c 5 2
Ensuite, qu'il ait existé ou que vous veniez de le créer, lancez :
chmod 666 /dev/ptmx
Puis, assurez-vous qu'il y a bien un répertoire nommé /dev/pts. Les permissions devraient être 755. Créez-le ou chmodez-le si besoin.
L'étape finale consiste à ajouter la ligne suivante à /etc/fstab :
devpts /dev/pts devpts gid=5,mode=620 0 0
REMARQUE : Cherchez le groupe tty dans /etc/group et notez le numéro d'id du groupe. Changez l'option gid=5 pour correspondre au numéro d'id du groupe tty. L'id du groupe de 5 n'est qu'un exemple et peut être différent sur votre système.
Maintenant que tout est configuré, vous avez deux options.
1. Montez /dev/pts et testez-le en relançant la commande expect ci-dessus.
2. Redémarrez l'ordinateur et testez-le en relançant la commande expect ci-dessus.
Si la compilation de GCC dans le chapitre 5 échoue avec
Error: Unknown pseudo-op: `.hidden'
Essayez la solution donnée dans les archives de lfs-support et ses réponses.
Si la construction de glibc échoue avec une erreur comme ceci :
'BEGIN { subdirs = ""; inhibit = "" }; \
^# { next }; \
^[^-] { subdirs = subdirs " " $0 }; \
^- { inhibit = inhibit " " substr($0, 2) }; \
END { printf "sysdep-subdirs =%s\n", subdirs; \
printf "sysdep-inhibit-subdirs =%s\n", inhibit; \
print "sysd-dirs-done = t" }' \
/dev/null linuxthreads/sysdeps/pthread/Subdirs
sysdeps/unix/inet/Subdirs sysdeps/unix/Subdirs >
/usr/src/glibc-build/sysd-dirs-tmp
/bin/sh: line 1: BEGIN { subdirs = ""; inhibit = "" };
^# { next };
^[^-] { subdirs = subdirs " " $0 }; ^- { inhibit =
inhibit " " substr($0, 2) }; END
alors gawk échoue. La clef est le BEGIN et le END dans la sortie. La raison probable est qu'il est lié incorrectement. Cela peut être corrigé en le recompilant en tant qu'utilisateur lfs, en suivant les instructions du chapitre 5.
Cela indique en général que vous compilez LFS sur une partition Reiser4. Malheureusement, il n'y a aucune solution actuellement connue, autre que d'utiliser un autre type de système de fichier.
Ncurses au chapitre six se termine par :
checking how to run the C++ preprocessor... /lib/cpp
configure: error: C++ preprocessor "/lib/cpp" fails sanity check
Le problème est que vous n'avez pas de compilateur c++. Dans le chapitre cinq, gcc a été construit sans le compilateur C++. Avant de construire ncurses, gcc est reconstruit avec le compilateur C++. Probablement que vous avez oublié d'extraire l'archive de g++ ou n'avez pas spécifié « c++ » dans l'option de configure --enable-languages, à la deuxième construction de gcc. Il y a plus de détails dans l'archive de la liste.
Il y a plusieurs raisons pour expliquer pourquoi le noyau n'arrive pas à monter le système de fichiers racine.
/boot/grub/menu.lst
?Lorsque vous voyez dans votre journal système, cette ligne :
init: Id "1" respawning too fast: disabled for 5 minutes
Cela signifie que vous avez une erreur dans la ligne /etc/inittab qui commence avec l'id indiqué (« 1 » dans l'exemple).
char-major-10-135
se rapporte au périphérique de caractère,
majeur 10, mineur 135, qui est /dev/rtc. Il fournit l'accès à l'horloge du
BIOS, ou RTC, l'Horloge Temps Réel. Voir
/usr/src/linux/Documentation/rtc.txt pour plus d'information.
L'erreur provient du fait que quelque chose, probablement hwclock, essaye d'utiliser /dev/rtc sans que vous ayez configuré le noyau pour le supporter. Soit vous supprimez /dev/rtc pour que hwclock n'essaye plus de l'utiliser, soit vous activez le support RTC dans votre noyau. Il se trouve dans le make menuconfig dans la section « Character devices » -> « Enhanced Real time Clock Support ».
Voir la question "modprobe: Can't locate module char-major-10-135"
L'erreur complète ressemble à ceci :
eth0:unknown interface:No such device [failed]
Setting up default gateway...
SIOCADDRT:No such device [failed]
eth0 est un périphérique virtuel sans entrée dans /dev. Il se réfère à la première carte réseau détectée par votre système. La raison pour laquelle le noyau ne peut pas trouver le périphérique est que vous avez oublié d'ajouter le support pour votre carte réseau dans le noyau. Le noyau détecte la carte réseau mais n'a pas de pilote pour elle. Le script de démarrage de LFS essaye d'activer le réseau mais échoue à cause de cela.
recompilez votre noyau avec le bon pilote, soit en dur soit en tant que
module. Si vous compilez le pilote réseau en tant que module, ajoutez-le
aussi à /etc/modules.conf pour affecter la carte réseau à eth0 ; par
exemple : alias eth0 8139too
. Si vous ne savez pas quelle
carte réseau vous avez, vous pouvez utiliser dmesg
, /proc/pci
ou lspci
pour la trouver.
Court résumé : C'est un problème matériel (généralement). Du bruit temporaire sur la ligne persuade le PIC que quelque chose est arrivé ; cela peut faire lever une fausse interruption, qui se trouve être l'IRQ7 avec la conception du 8259 d'Intel. Le problème pourrait aussi être causé par (ou plutôt causé par) un pilote de périphérique qui ne masque pas proprement ses interruptions avant de les servir, ce qui pourrait bien être le cas lorsque les IRQ7 arrivent par paquets, ou plus souvent que « plusieurs » par jour. (Source et informations supplémentaires)
Puisque le message lui-même est sans conséquence, il est suffisant d'ajuster
le niveau d'enregistrement par défaut de klogd (l'option -c) dans le script
de démarrage de syslogd. Voir man klogd
pour les détails. Vous
pouvez aussi essayer de recompiler le noyau et désactiver CONFIG_LOCAL_APIC.
Parce que les variables d'environnement LANG et LC_ALL ne sont pas initialisées. Pour corriger cela, initialisez-les dans les fichiers ~/.bash_profile et ~/.bashrc pour chaque utilisateur ou dans /etc/profile, qui s'occupe de tous les utilisateurs en ajoutant des lignes comme :
export LANG=en_US
export LC_ALL=POSIX
Ces lignes peuvent être ajoutées au fichier /etc/profile avec la commande suivante :
echo -e 'export LANG=en_US\nexport LC_ALL=POSIX' >>
/etc/profile
Si vous n'utilisez pas l'anglais américain, vous devrez changer les « en_US » et éventuellement les valeurs des diverses variables LC_*. Lancez la commande locale liste plusieurs (toutes ?) les variables LC_*.