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.

Améliorations fréquemment demandées

Pendant la lecture et la construction de LFS

Erreurs de compilation usuelles

Erreurs spécifiques à certains paquets

Problèmes de configuration et de démarrage

Améliorations fréquemment demandées

Pourquoi ne pas utiliser LILO plutôt que GRUB ?

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.

Pourquoi ne pas inclure la FAQ dans le livre ?

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.

Pourquoi vim est dans le livre ?

Ça a bien été discuté dans le fil qui commence par http://linuxfromscratch.org/pipermail/lfs-dev/2002-February/023030.html.

Pourquoi est-ce que la version HJL de Binutils n'est pas dans le livre ?

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 :

HJL :

  • Pour les OS linux seulement
  • Marqué comme "beta"
  • Suit de très près le HEAD du CVS
  • Contient habituellement les dernières corrections de bogues subtiles
  • Contient habituellement les dernières corrections de bogues pour les architectures non x86
  • Habituellement une nouvelle version chaque fois qu'un bogue significatif qui affecte Linux est corrigé
  • Théoriquement moins stable à cause du code plus récent

FSF :

  • Supporte plus d'OS (pas seulement Linux)
  • Le code provient de la branche stable du CVS
  • Parfois pas tout à fait à jours par rapport aux subtilités des versions ultra-récentes du noyau, de gcc et de la glibc
  • Inclus souvent des fonctionnalités récupérée depuis le HEAD du CVS après un période de test
  • Théoriquement plus stable

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 :

  • Rester informés des problèmes sur les listes de diffusion des paquets du cœur de la chaîne d'outils
  • Avoir une large dose de prouesse technique et de talent en programmation pour comprendre tous les problèmes
  • Tester comme un fou en lançant les suites de tests
  • Tester comme un fou en construisant des systèmes complets

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.

Pourquoi n'y a-t'il pas de gestionnaire de paquets dans le livre ?

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 :

  • Aucun gestionnaire de paquet n'est vraiment nécessaire. À moins que vous ne souhaitiez vérifier le placement des fichiers des paquets minutieusement, tout paquet suffisamment gros pour qu'on ait envie de le supprimer pour faire de la place sur le disque peut être installé dans /opt comme décrit par le FHS (peut-être dans /opt/foo-x.x avec un lien depuis /opt/foo) et les nouvelles versions peuvent généralement être réinstallées par dessus l'ancienne, bien que les mises à jour majeures et les bibliothèques soient mieux traitées en reconstruisant le système depuis le début.
  • RPM, le gestionnaire de paquet de Redhat, est utilisé par un certain nombre de distributions. Il est disponibles sur http://www.rpm.org/ et il y a une astuce RPM pour vous aider à l'installer.
  • Il y a plusieurs implémentations d'une gestion de paquets par les liens symboliques :
  • Le gestionnaire de paquets de NetBSD, pkgsrc, est disponible sur d'autres systèmes, y compris Linux. Il se trouve sur ftp://ftp.netbsd.org/pub/pkgsrc/stable/.
  • À l'origine basé sur un script écrit par notre Gerard Beekmans, install-log enregistre une liste de fichiers installés par un paquet à l'installation. Il est disponible sur http://install-log.sourceforge.net/.
  • Gerard a depuis fait des modifications à son script. Il est disponible sur http://linuxfromscratch.org/~gerard/log-install.
  • CheckInstall essaye d'enregistrer les appels systèmes effectués par « make install ». Il est disponible sur http://asic-linux.com.mx/~izto/checkinstall/.
  • pkgutils, utilisé par la distribution CRUX, est disponible sur http://www.fukt.bsnet.se/~per/pkgutils/.
  • Il y a quelques astuces disponibles pour les gestionnaires de paquets.

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é.

Comment provoquer l'arrêt électrique de la machine à la sortie du système ?

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.

Haut de la page.

Pendant la lecture et la construction de LFS

Quelle distribution devrais-je utiliser, pour démarrer ?

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.

Comment compiler un noyau ou configurer un module ?

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/.

Est-ce que c'est mal, les avertissements de compilation de Gcc ?

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 $

Comment puis-je procéder à cette toute petite installation dont parle le livre ?

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.

Existe-t'il des informations sur la façon de construire LFS sur d'autres architectures ?

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.

Comment faire une compilation croisée avec LFS ?

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.

Qu'est qu'un fichier texte au format DOS ?

Cela a à voir avec les caractères en fin de ligne.

Il y en a deux qui sont utilisés :

  • Saut de Ligne : (LF) Octal : 012 Décimal :10 Hexa :0A Échappement à la C :'\n'. Déplace d'une ligne vers le bas.
  • Retour Charriot: (CR) Octal :015 Décimal :13 Hexa :0D Échappement à la C:'\r'. Déplace le curseur vers la marge à gauche.

Unix, DOS et MacOS utilisent chacun une combinaison différent pour terminer les lignes des fichiers textes :

  • Unix : LF seulement. C'est pour cela que lorsqu'un text au format Unix est envoyé à une imprimante directement, il sort ainsi :
      comme
        des marches
          d'escaliers.
  • DOS : CRLF (les deux). C'est pourquoi en faisant « cat -v » sur un fichier DOS vous verrez un « ^M » (contrôle M est le retour charriot) à la fin de chaque liggne. Et c'est pourquoi les scripts ne fonctionnent pas lorsqu'ils sont écrits avec le bloc-notes de Microsoft. Le noyau cherche « /bin/sh^M » qui n'existe pas. Il y a bien un « /bin/sh » mais rien avec un « ^M » à la fin.
  • MacOS : CR seulement. Les imprimantes impriment sans doute les lignes par dessus les autres et les outils Unix pensent que le fichier ne fait qu'une ligne avec des « ^M » partout dedans.

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.

Y a-t-il moyen de télécharger tous les fichiers actuels d'un coup ?

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

Haut de la page.

Erreurs de compilation usuelles

J'ai utilisé un patch provenant de GNU pour faire des mises à jour. C'est bon ?

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).

Utilisation des flags d'optimisation (paramétrage des CFLAGS)

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.)

Pourquoi est-ce que configure se fige sur « checking for signed size_t type... » ?

Vous avez sur-optimisé gcc.

Je n'ai pas effacé l'arborescence des sources après mon dernier essai. Faut-il le faire ?

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.

J'obtiens le message « /dev/null: Permission denied »

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.

signal 11 (internal error: Segmentation fault)

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.

No such file or directory

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.

bash: ./configure: No such file or directory

Vous avez oublié de cd dans le répertoire extrait du paquet après l'avoir extrait.

./configure: bad interpreter: Permission denied

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
configure n'arrive pas à déterminer le type de mon hôte.

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.

checking whether we are using GNU C... no

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).

The system has no more ptys. Ask your system administrator to create more.

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.

Haut de la page.

Erreurs spécifiques à certains paquets

GCC: Error: Unknown pseudo-op: `.hidden'

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.

Glibc sort en erreur et évoque BEGIN et END.

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.

La compilation de Glibc sort en erreur à cause de l'absence de l'entête de fichier nss.h.

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 : le préprocesseur C++ "/lib/cpp" échoue lors de la vérification de conformité

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.

Haut de la page.

Problèmes de configuration et de démarrage

Kernel panic: VFS: unable to mount root fs

Il y a plusieurs raisons pour expliquer pourquoi le noyau n'arrive pas à monter le système de fichiers racine.

  • Avez-vous spécifié la bonne partition dans /boot/grub/menu.lst ?
  • Le support pour votre disque dur est-il activé dans le noyau ? Pour SCSI cela signifie le support pour l'adaptateur SCSI spécifique.
  • Le support pour le disque dur est-il compilé dans le noyau, pas seulement en tant que module ? (Les modules sont stockés sur le système de fichiers. Si un pilote requis pour accéder au système de fichier est stocké en tant que module sur ce même système de fichier, eh bien… vous voyez… ;))
  • Le support pour le système de fichier est-il compilé dans le noyau ? De nouveau, pas en tant que module. Le support pour ext2 est activé par défaut, mais les autres comme ext3, reiser, jfs et xfs ne le sont pas.
init: Id "1" respawning too fast: disabled for 5 minutes

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).

modprobe: Can't locate module char-major-10-135

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 ».

modprobe: Can't locate module /dev/rtc

Voir la question "modprobe: Can't locate module char-major-10-135"

eth0:unknown interface:No such device [failed]

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.

spurious 8259A interrupt: IRQ14

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.

Pourquoi est-ce que less (et par conséquent man) affiche <AD> au lieu des tirets ?

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_*.