Copyright © 1999–2005 Gerard Beekmans
Copyright (c) 1999–2005, Gerard Beekmans
All rights reserved.
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
Redistributions in any form must retain the above copyright notice, this list of conditions and the following disclaimer
Neither the name of « Linux From Scratch » nor the names of its contributors may be used to endorse or promote products derived from this material without specific prior written permission
Any material derived from Linux From Scratch must contain a reference to the « Linux From Scratch » project
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS « AS IS » AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Mes aventures dans Linux ont commencé en 1998 lorsque j'ai téléchargé et installé ma première distribution. Après avoir travaillé dessus un bon moment, j'ai découvert des problèmes que j'aurais vraiment aimé voir améliorer. Par exemple, je n'aimais pas l'arrangement des scripts de démarrage ou la façon dont les programmes étaient configurés par défaut. J'ai essayé un certain nombre d'autres distributions pour corriger ces problèmes, cependant chacune avait ses avantages et ses inconvénients. Finalement, j'ai réalisé que si je voulais avoir une pleine satisfaction de mon système Linux, je devais le construire à partir de rien.
Qu'est-ce que cela signifie ? Je me suis résolu à ne pas utiliser de paquets déjà compilés, quels qu'ils soient, et à ne pas utiliser de CD-ROM ou de disques d'amorçage qui installeraient des outils de base. J'utiliserais mon système Linux actuel pour développer mon propre système personnalisé. Ce système Linux « parfait » aurait alors la force des autres systèmes sans avoir leurs faiblesses. Au début, l'idée était un peu écrasante mais j'ai conservé l'idée qu'un système pourrait être construit en se conformant à mes besoins et désirs plutôt qu'à un standard qui ne correspondrait pas à ce que je cherchais.
Après avoir passé quelques problèmes comme des dépendances circulaires et erreurs à la compilation, j'ai créé un système Linux personnalisé entièrement opérationnel et convenant à des besoins individuels. Ce processus m'a aussi permis de créer des systèmes Linux compacts et précis, bien plus rapides et prenant moins de place que des systèmes d'exploitation traditionnels. J'ai appelé ce système LFS, soit « Linux From Scratch » (Linux à partir de rien).
Lorsque j'ai partagé mes objectifs et mes expériences avec d'autres membres de la communauté Linux, il est devenu apparent qu'il y avait un sérieux intérêt dans les idées que j'avais mises en avant lors de mes aventures Linux. De tels systèmes LFS personnalisés rencontraient non seulement les spécifications et pré-requis des utilisateurs mais servaient aussi comme opportunité idéale d'apprentissage pour les programmeurs et les administrateurs système, afin d'améliorer leurs connaissances sous Linux. De cet intérêt est né le projet « Linux From Scratch ».
Le livre « Linux From Scratch » fournit aux lecteurs la base et les instructions pour concevoir et créer des systèmes Linux personnalisés. Ce livre met en lumière le projet Linux from Scratch et les bénéfices de l'utilisation de ce système. Les utilisateurs peuvent dicter tous les aspects de leur système, ceci incluant la répartition des répertoires, la configuration des scripts et la sécurité. Le système résultant sera compilé directement à partir du code source et l'utilisateur sera capable de spécifier où, pourquoi et comment les programmes sont installés. Ce livre permet aux lecteurs de personnaliser complètement les systèmes Linux suivant leurs besoins et donne plus de contrôle aux utilisateurs sur leur système.
J'espère que vous passerez un bon moment en travaillant sur votre propre système LFS et que vous apprécierez les nombreux bénéfices qu'apporte un système qui est réellement le vôtre.
--
Gerard Beekmans
gerard@linuxfromscratch.org
Il y a beaucoup de raisons qui pousseraient quelqu'un à vouloir lire ce livre. La raison principale est d'installer un système LFS à partir du code source. La question que beaucoup de personnes se posent est « pourquoi se fatiguer à installer manuellement un système Linux depuis le début alors qu'il suffit de télécharger une distribution existante ? ». C'est une bonne question.
Une raison importante de l'existence de LFS est d'apprendre comment fonctionne un système Linux de l'intérieur. Construire un système LFS vous apprend tout ce qui fait que Linux fonctionne, et comment les choses interagissent et dépendent les unes des autres, et le plus important, vous apprend à le personnaliser afin qu'il soit à votre goût et réponde à vos besoins.
Un avantage clé de LFS est qu'il permet aux utilisateurs d'avoir plus de contrôle sur votre système sans avoir à dépendre d'une implémentation créée par quelqu'un d'autre. Avec LFS, vous êtes maintenant sur le siège du conducteur et vous êtes capable de décider chaque aspect de votre système, comme la disposition des répertoires ou la configuration des scripts de démarrage. Vous saurez également exactement où, pourquoi et comment les programmes sont installés.
Un autre avantage de LFS est la possibilité de créer un système Linux très compact. Lors de l'installation d'une distribution habituelle, l'utilisateur finit par inclure beaucoup de programmes qui ne seront jamais utilisés. Ces programmes occupent de l'espace disque et font parfois perdre des cycles CPU précieux. Il n'est pas difficile de construire un système LFS de moins de 100 Mo, ce qui est très petit comparé à la majorité des installations existantes. Cela vous semble-t-il toujours beaucoup ? Certains d'entre nous ont travaillé afin de créer un système LFS minuscule. Nous avons installé un système spécialisé pour faire fonctionner le serveur web Apache ; l'espace disque total occupé était approximativement de 8 Mo. Avec plus de dépouillement encore, cela peut être ramené à 5 Mo ou moins. Essayez donc d'en faire autant avec une distribution courante ! C'est seulement un des points bénéfiques de la conception de votre propre implémentation d'un système Linux.
Si nous devions comparer une distribution Linux à un hamburger que vous achetez au restaurant fast-food, vous n'avez aucune idée de ce que vous mangez. LFS ne vous donne pas un hamburger, mais la recette pour faire un hamburger. Cela permet aux utilisateurs de prudemment l'inspecter, d'enlever les ingrédients non désirés et, par la même occasion, de rajouter des ingrédients qui correspondent mieux à la saveur qu'ils attendent de ce hamburger. Quand vous êtes satisfait des ingrédients, vous passez à l'étape suivante en les combinant ensemble. Vous avez désormais la chance de pouvoir le faire de la façon dont vous le souhaitez : grillez-le, faites-le cuire au four, faites-le frire, faites-le au barbecue ou mangez-le cru.
Une autre analogie que nous pouvons utiliser est de comparer LFS à une maison construite. LFS fournit les plans de la maison, mais c'est à vous de la construire. LFS vous donne la liberté d'ajuster les plans pendant tout le processus, le personnalisant suivant les besoins et préférences des utilisateurs.
Un autre avantage d'un système Linux personnalisé est un surcroît de sécurité. Vous compilerez le système complet à partir de la base, ce qui vous permet de tout vérifier, si vous le voulez, et d'appliquer tous les correctifs de sécurité désirés. Il n'est plus nécessaire d'attendre que quelqu'un d'autre vous fournisse un paquet réparant une faille de sécurité. Malgré tout vous n'avez aucune garantie que le nouveau paquet résolve le problème de manière adéquate. Vous ne pourrez jamais savoir si une faille de sécurité est réparée si vous ne le faites pas vous-même.
Le but de Linux From Scratch est de construire un système complet et utilisable, en ce qui concerne les fondations. Les lecteurs qui ne souhaitent pas construire leur propre système à partir de rien pourraient ne pas bénéficier des informations contenues dans ce livre. Si vous voulez seulement savoir ce qui se passe pendant le démarrage de l'ordinateur, nous vous recommandons le guide pratique « De la mise sous tension à l'invite de commande de Bash », disponible sur http://www.traduc.org/docs/HOWTO/lecture/From-PowerUp-To-Bash-Prompt-HOWTO.html ou, en anglais, sur le site du projet de documentation Linux (TLDP) http://www.tldp.org/HOWTO/From-PowerUp-To-Bash-Prompt-HOWTO.html. Ce guide pratique construit un système qui est similaire à celui de ce livre mais il se concentre strictement sur la création d'un système capable de démarrer jusqu'à l'invite de BASH. Prenez en compte vos objectifs. Si vous souhaitez construire un système Linux tout en apprenant, alors ce livre est votre meilleur choix possible.
Il existe trop de bonnes raisons de construire votre système LFS pour pouvoir toutes les lister ici. Cette section n'aborde que la partie visible de l'iceberg. En continuant dans votre expérience de LFS, vous trouverez la puissance que donnent l'information et la connaissance.
Ce livre suppose que le lecteur possède un bon ensemble de connaissances sur l'utilisation et l'installation de systèmes Linux. Avant de commencer à construire un système LFS, nous recommandons la lecture des guides pratiques suivants :
Software-Building-HOWTO http://www.tldp.org/HOWTO/Software-Building-HOWTO.html
C'est un guide complet sur la construction et l'installation « générique » de logiciels Unix sous Linux.
The Linux Users' Guide http://www.linuxhq.com/guides/LUG/guide.html
Ce guide couvre l'utilisation de différents logiciels Linux.
The Essential Pre-Reading Hint http://www.linuxfromscratch.org/hints/downloads/files/essential_prereading.txt (NdT :L'astuce essentielle à lire avant tout
C'est une astuce LFS écrite spécifiquement pour les nouveaux utilisateurs Linux. C'est principalement une liste de liens de sources excellentes d'informations sur une grande gamme de thèmes. Toute personne essayant d'installer LFS devrait au moins avoir une certaine compréhension de la majorité des thèmes de cette astuce...
L'hôte doit exécuté au minimum un noyau 2.6.2 compilé avec
GCC-3.0 ou ultérieur. Deux raisons expliquent ce prérequis. Tout
d'abord, la suite de tests NPTL (Native POSIX Threading
Library, soit la bibliothèque des threads POSIX)
causera une erreur de segmentation si le noyau de l'hôte n'a pas
été compilé avec GCC-3.0 ou avec une version ultérieure. Ensuite,
la version 2.6.2 ou ultérieure du noyau est nécessaire pour
utiliser Udev. Udev crée les périphériques dynamiquement en les
découvrant dans le système de fichiers sysfs
. Néanmoins, le support de ce système de
fichier a été récemment implémenté dans la plupart des pilotes du
noyau. Nous voulons être sûr que tous les périphériques système
critiques seront proprement créés.
Pour déterminer si le noyau de l'hôte valide les prérequis indiqués ci-dessus, lancez la commande suivante :
cat /proc/version
Elle devrait produire un affichage similaire à :
Linux version 2.6.2 (user@host) (gcc version 3.4.0) #1
Tue Apr 20 21:22:18 GMT 2004
Si le résultat de la commande ci-dessus indique que le noyau de l'hôte est soit 2.6.2 (ou ultérieur) ou qu'il n'a pas été compilé en utilisant GCC-3.0 (ou ultérieur), vous aurez besoin de l'installer. Il existe deux méthodes pour résoudre ceci. Tout d'abord, voir si votre distribution Linux fournit un noyau 2.6.2 (ou ultérieur). Dans ce cas, vous pouvez l'installer. Si votre distribution ne le propose pas ou si vous préférez ne pas l'installer, alors vous pouvez compiler un noyau 2.6 vous-même. Les instructions de compilation d'un noyau et de configuration du chargeur de démarrage (en supposant que l'hôte utilise GRUB) sont situés dans Chapitre 8. Cette deuxième option peut aussi être vue comme un test de vos connaissances Linux. Si cette étape est trop importante, alors le livre LFS ne vous sera pas d'une grande utilité actuellement.
Pour faciliter ce qui suit, voici quelques conventions typographiques suivies tout au long de ce livre. Cette section contient quelques exemples du format typographique trouvé dans ce livre.
./configure --prefix=/usr
Ce style de texte est conçu pour être tapé exactement de la même façon qu'il est vu sauf si le texte indique le contraire. Il est aussi utilisé dans les sections d'explications pour identifier les commandes référencées.
install-info: unknown option
'--dir-file=/mnt/lfs/usr/info/dir'
Ce style de texte (texte à largeur fixe) montre une sortie
d'écran, probablement le résultat de commandes. Ce format est
aussi utilisé pour afficher des noms de fichiers, comme
/etc/ld.so.conf
.
Emphase
Ce style de texte est utilisé dans différents buts dans ce livre. Son but principal est de préciser les points importants.
http://www.linuxfromscratch.org/
Ce format est utilisé pour les liens, ceux de la communauté LFS et ceux référençant des pages externes. Cela inclut les guides pratiques, les emplacements de téléchargement et des sites web.
cat > $LFS/etc/group << "EOF" root:x:0: bin:x:1: ...... EOF
Ce format est utilisé principalement lors de la création de
fichiers de configuration. La première commande indique au
système de créer le fichier $LFS/etc/group
à partir de ce qui est saisi
jusqu'à ce que la séquence de fin de fichier (EOF) soit
rencontrée. Donc, cette section entière est généralement saisie
de la même façon.
[TEXTE À REMPLACER]
Ce format est utilisé pour intégrer du texte qui ne devra pas être saisi tel quel et qui ne devra pas être copié/collé.
passwd(5)
Ce format est utilisé pour faire référence à une page de manuel
spécifique (noté après comme une page « man »). Le nombre entre parenthèses indique
une section spécifique à l'intérieur de man. Par exemple, passwd a deux pages man. Pour les
instructions d'installation de LFS, ces deux pages man seront
situés dans /usr/share/man/man1/passwd.1
et /usr/share/man/man5/passwd.5
. Ces deux pages
man comprennent des informations différentes. Quand le livre
utilise passwd(5)
, il fait
spécifiquement référence à specifically referring to /usr/share/man/man5/passwd.5
.
man passwd
affichera la première page man qu'il trouvera et qui aura une
correspondance avec « passwd », à priori /usr/share/man/man1/passwd.1
. Dans cet exemple,
vous devrez exécuter man 5
passwd pour lire cette page spécifique. Il
devrait être noté que la plupart des pages man n'ont pas de noms
de page dupliqués dans les différentes sections. Du coup,
man [nom programme]
est généralement suffisant.
Ce livre est divisé en plusieurs parties.
La première partie donne quelques informations importantes, comme par exemple sur la façon d'installer LFS. Cette section fournit aussi des méta-informations sur le livre.
La deuxième partie décrit comment préparer le processus de construction : création d'une partition, téléchargement des paquets et compilation d'outils temporaires.
La troisième partie guide le lecteur tout au long de la construction du système LFS : compilation et installation de tous les paquets un par un, initialisation des scripts de démarrage et installation du noyau. Le système Linux basique résultant est la fondation à partir de laquelle d'autres logiciels peuvent être construits pour étendre le système de la façon désirée. À la fin du livre se trouve une référence facile à utiliser et listant tous les programmes, bibliothèques et fichiers importants qui ont été installés.
Le logiciel utilisé pour créer un système LFS est constamment mis à jour et amélioré. Les messages d'avertissements pour la sécurité et les corrections de bogues pourraient survenir après la sortie du livre LFS. Pour vérifier si les versions du paquetage ou les instructions de cette version de LFS ont besoin de modifications pour corriger les vulnérabilités en terme de sécurité ou toute autre correction de bogue, merci de visiter http://www.linuxfromscratch.org/lfs/errata/6.1/ avant de commencer votre construction. Vous devez noter toute modification et les appliquer à la bonne section du livre pendant votre progression lors de la construction du système LFS.
Le système LFS sera construit en utilisant une distribution Linux déjà installée (telle que Debian, Mandrake, Red Hat ou SuSE). Ce système Linux existant (l'hôte) sera utilisé comme point de départ pour fournir certains programmes nécessaires, ceci incluant un compilateur, un éditeur de liens et un shell, pour construire le nouveau système. Sélectionnez l'option « développement » (development) lors de l'installation de la distribution pour disposer de ces outils.
Comme alternative à l'installation d'une distribution séparée complète sur votre machine, vous pouvez utiliser le LiveCD Linux From Scratch. Le CD fonctionne bien en tant que système hôte, fournissant tous les outils dont vous avez besoin pour suivre les instructions de ce livre avec succès. De plus, il contient les paquetages sources, correctifs et une copie de ce livre. Une fois que vous avez le CD, aucune connexion réseau et aucun téléchargement supplémentaire n'est nécessaire. Pour plus d'informations sur le LiveCD LFS ou pour télécharger une copie, visitez http://www.linuxfromscratch.org/livecd/.
Le Chapitre 2 de ce livre décrit comment créer une nouvelle partition native Linux et un système de fichiers, c'est-à-dire un emplacement où le nouveau système LFS sera compilé et installé. Le Chapitre 3 explique quels paquets et correctifs ont besoin d'être téléchargés pour construire un système LFS et comment les stocker sur le nouveau système de fichiers. Le Chapitre 4 discute de la configuration pour un environnement de travail approprié. Merci de lire le Chapitre 4 avec attention car il explique plusieurs problèmes importants dont le développeur doit être au courant avant de commencer à travailler sur le Chapitre 5 et les chapitres suivants.
Le Chapitre 5 explique l'installation d'un ensemble de paquets qui formera la suite de développement de base (ou ensemble d'outils) utilisé pour construire le système réel dans le Chapter 6. Certains de ces paquets sont nécessaires pour résoudre des dépendances circulaires — par exemple, pour compiler un compilateur, vous avez besoin d'un compilateur.
Le Chapitre 5 montre aussi à l'utilisateur comment construire une première passe de l'ensemble d'outils, incluant Binutils et GCC (première passe signifiant basiquement que ces deux paquets principaux seront installés une deuxième fois). La prochaine étape consiste à construire Glibc, la bibliothèque C. Glibc sera compilé par les programmes de l'ensemble d'outils, construits lors de la première passe. Ensuite, une seconde passe de l'ensemble d'outils sera lancée. Cette fois, l'ensemble d'outils sera lié dynamiquement avec la Glibc nouvellement construite. Les paquets restants du Chapitre 5 seront construits en utilisant l'ensemble d'outils de cette deuxième passe. Lorsque ceci sera fait, le processus d'installation de LFS ne dépendra plus de la distribution hôte, à l'exception du noyau en cours d'exécution.
Alors que ceci pourrait sembler être beaucoup de travail pour isoler le nouveau système de la distribution hôte, une explication technique complète est fournie au début du Chapitre 5.
Dans le Chapter 6, le système LFS complet est construit. Le programme chroot (changement de racine) est utilisé pour entrer dans un environnement virtuel et pour lancer un nouveau shell dont le répertoire racine sera initialisé à la partition LFS. Ceci ressemble au redémarrage et à l'instruction au noyau de monter la partition LFS comme partition racine. Le système ne redémarre pas réellement mais change la racine parce que la création d'un système démarrable (amorçable) réclame un travail supplémentaire qui n'est pas encore nécessaire. L'avantage principal est que « chroot » permet à l'utilisateur de continuer à utiliser l'hôte pendant la construction de LFS. En attendant que la compilation d'un paquet se termine, un utilisateur peut passer sur une console virtuelle (VC) différente ou un bureau X et continuer à utiliser son ordinateur comme d'habitude.
Pour terminer l'installation, les scripts de démarrage sont configurés dans le Chapitre 7, le noyau et le chargeur de démarrage sont configurés dans le Chapitre 8. Le Chapitre 9 contient des informations sur la suite de l'expérience LFS après ce livre. Après l'implémentation des étapes de ce livre, l'ordinateur sera prêt à redémarrer dans le nouveau système LFS.
Ceci expose rapidement le processus. Des informations détaillées sur chaque étape sont discutées dans les chapitres suivants avec les descriptions des paquets. Les éléments qui peuvent sembler compliqués seront clarifiés et tout ira à sa place, alors que le lecteur s'embarquera pour l'aventure LFS.
Il s'agit de la version 6.1 du livre « Linux From Scratch », datant du 9 juillet 2005. Si ce livre est daté de plus de six mois, une nouvelle et meilleure version est probablement déjà disponible. Pour le savoir, merci de vérifier la présence d'une nouvelle version sur l'un des miroirs via http://www.linuxfromscratch.org/.
Ci-dessous se trouve une liste des modifications apportées depuis la vers ion précédente du livre avec un résumé suivi d'une explication plus détaillée.
Paquets mis à jour :
Automake 1.9.5
Binutils 2.15.94.0.2.2
Bison 2.0
Bzip2 1.0.3
E2fsprogs 1.37
Expect 5.43.0
File 4.13
Findutils 4.2.23
GCC 3.4.3
Gettext 0.14.2
Glibc 2.3.4
Grep 2.5.1a
Grub 0.96
Iana-Etc 1.04
Iproute2 2.6.11-050330
LFS-Bootscripts 3.2.1
Libtool 1.5.14
Linux 2.6.11.12
Linux-libc-headers 2.6.11.2
M4 1.4.3
Man 1.5p
Man-pages 2.01
Module-init-tools 3.1
Perl 5.8.6
Procps 3.2.5
Psmisc 21.6
Sed 4.1.4
Shadow 4.0.9
Sysvinit 2.86
Tar 1.15.1
Texinfo 4.8
Tcl 8.4.9
Udev 056
Util-linux 2.12q
Zlib 1.2.2
Paquets ajoutés :
bash-3.0-fixes-3.patch
bash-3.0-avoid_WCONTINUED-1.patch
flex-2.5.31-debian_fixes-3.patch
glibc-2.3.4-fix_test-1.patch
gzip-1.3.5-security_fixes-1.patch
Hotplug 2004_09_23
mktemp-1.5-add_tempfile-2.patch
sysklogd-1.4.1-fixes-1.patch
tar-1.15.1-sparse_fix-1.patch
util-linux-2.12p-cramfs-1.patch
vim-6.0-security_fix-1.patch
zlib-1.2.2-security_fix-1.patch;
Paquets supprimés :
bash-3.0-display_wrap-1.patch
flex-2.5.31-debian_fixes-2.patch
man-1.5o1-80cols-1.patch
mktemp-1.5-add_tempfile-1.patch
sysklogd-1.4.1-kernel_headers-1.patch
sysvinit-2.85-proclen-1.patch
texinfo-4.7-segfault-1.patch
util-linux-2.12b-sfdisk-1.patch
zlib-1.2.1-security-1.patch
July 9th, 2005 [archaic]: Rewrote kernel notes.
July 9th, 2005 [matt]: Added information regarding security mailing lists and freshmeat to chapter09/whatnow.xml. Fixes bug 1583. Thanks to Steve Crosby for the report and the suggested text.
July 7th, 2005 [manuel]: Revised packages and patches sizes. Using the lfs-packages-6.1.tar package and `du -k` to meassure it. Fixed beginpage tags for PDF output. Removed blank pages in PDF output for non-published versions.
July 6th, 2005 [archaic]: Added security patch for zlib.
July 6th, 2005 [matt]: Several typo corrections, as suggested by Bernard Leak.
July 5th, 2005 [archaic]: Removed reference to the wiki. Pointed to the FAQ.
July 4th, 2005 [archaic]: Reworded errata page so it only refers to security warnings and bug fixes, not new features.
July 4th, 2005 [archaic]: Brought (hopefully) all references of man/info pages into conformity. Man page conformity was based on if referring to a specific man page or man pages in general. Updated typography to reflect this.
July 2nd, 2005 [archaic]: Several minor wording changes in chapters 8 and 9 (matt). Also removed the paragraph about compressing kernel modules as it is hint material at best.
July 2nd, 2005 [archaic]: Several minor wording changes in chapter 8 (matt).
July 1st, 2005 [archaic]: Several minor wording changes in chapter 6 (matt).
July 1st, 2005 [archaic]: Brought all occurences of LFS-Bootscripts into conformity.
June 30th, 2005 [archaic]: Several minor wording changes in chapters 1 - 5 (matt).
June 30th, 2005 [archaic]: Added a livecd-root entity.
June 29th, 2005 [archaic]: Moved the host requirements page to the preface section of the book.
June 28th, 2005 [archaic]: Switched from mounting /dev on a ramfs to a tmpfs.
June 27th, 2005 [matthew]: Removed mention of test suite problems from chapter 1 as more comprehensive information is given in chapter 5 (archaic).
June 27th, 2005 [matthew]: Reworded description of the glibc atime failure case, and removed the description of the shm test failure as we already mount a tmpfs (archaic).
June 27th, 2005 [archaic]: Filled in text for errata page. Thanks for the text, Steve!
June 26th, 2005 [manuel]: Small tags corrections.
June 25th, 2005 [archaic]: Added placeholder for errata page and a temporary link (currently dead).
June 25th, 2005 [archaic]: Added "generic-version" and "test-results" entities.
June 25th, 2005 [archaic]: Added the compress symlink to gzip.
June 25th, 2005 [jhuntwork]: Added a --with-tclinclude flag to Expect build to ensure that it knows where to find the Tcl source directory.
June 25th, 2005 [matthew]: Updated to the latest version of the mktemp tempfile patch, which supports building outside the source directory
June 23rd, 2005 [archaic]: Rewrote the inputrc page.
June 22nd, 2005 [archaic]: Added a link to point to test results.
June 22nd, 2005 [archaic]: Upgraded shadow to 4.0.9. Removed lastlog patch.
June 21st, 2005 [archaic]: Removed --with-included-regex from chapter05/grep since there seems to no longer be a valid reason to use it and the explanation of it was incorrect.
June 21st, 2005 [archaic]: Updated to findutils-4.2.23.
June 20th, 2005 [archaic]: Updated flex patch from -2 to -3.
June 20th, 2005 [manuel]: Added a warning about kernel headers and Linux-Libc-Headers, plus fixed the list of installed files on kernel.xml (bug 1569). Some typos and tags fixes ported from trunk (r6048 to r6050 and r6053 to r6056.) Fixed top program description (bug 1549.) Fixed tar description (bug 1553.) Reworded Util-linux patch explanation (bug 1554.)
June 19th, 2005 [jhuntwork]: Changed listing of IRC servers to show only irc.linuxfromscratch.org.
June 19th, 2005 [jhuntwork]: Removed outdated bootcd page and added a brief description of the LiveCD to section 1.1.
June 16th, 2005 [archaic]: Added installation dependencies for hotplug.
June 16th, 2005 [matthew]: Another round of typo and markup fixes in chapter 7, as reported by Randy McMurchy.
June 16th, 2005 [matthew]: Typo and markup fixes in chapter 7, as reported by Randy McMurchy.
June 16th, 2005 [jhuntwork]: Adjusted description of the patch package. Thanks Randy McMurchy.
June 16th, 2005 [archaic]: Fixed link to BLFS's db page referenced in iproute2. (merged from trunk r6006)
June 15th, 2005 [archaic]: Added --disable-nls to pass2 binutils to avoid requirement of gettext. (merged from trunk r5983)
June 14th, 2005 [archaic]: Updated all build sizes. (merged from trunk r5916, r5917, r5918, and r5972)
June 14th, 2005 [archaic]: Removed --with-included-regex from chapter6's grep since it is less reliable than glibc's in non-C locales.
June 14th, 2005 [archaic]: Removed references to separate gcc tarballs (gcc-core, gcc-g++, etc.)
June 12th, 2005 [matt]: Upgraded to linux-2.6.11.12.
June 8th, 2005 [archaic]: Removed suggestion on where to move /sources, and reworded the rest of the page (chapter06/revisedchroot.xml).
June 8th, 2005 [archaic]: Added a command to prevent module-init-tools from rewriting it's man page (which relies on docbook2man).
Jun 1st, 2005 [manuel]: Changed patches root to lfs/svn/testing/
May 23nd, 2005 [manuel]: Minor wording improvements (thanks to Peter Ennis)
May 22nd, 2005 [matt]: Updated to Linux-2.6.11.10.
May 15th, 2005 [matt]: Added gzip security patch.
May 15th, 2005 [matt]: Updated to Linux 2.6.11.9.
May 15th, 2005 [matt]: Updated to LFS-Bootscripts 3.2.1.
May 12th, 2005 [matt]: More wording and tagging improvements (thanks to Peter Ennis and Tony Morgan)
May 12th, 2005 [matt]: Minor wording improvements (thanks to Peter Ennis)
April 27th, 2005 [archaic]: Added a patch to fix 2 glibc testsuite failures when the running kernel is 2.6.11.x.
April 18th, 2005 [manuel]: Adjusted the beginpage tags to match the previous text changes.
April 17th, 2005 [manuel]: Updated the stylesheets to use DocBook-XSL 1.68.1.
April 17, 2005 [matt]: Don't create hotplug's events log file; the bootscripts handle that for us.
April 17, 2005 [matt]: Use canonical charmaps in /etc/profile and don't set LC_ALL (Ken Moffat and Alexander Patrakov)
April 16, 2005 [matt]: Reword handling of hotpluggable devices now that we install the hotplug package (Andrew Benton)
April 16, 2005 [matt]: Minor wording/typo fixes (Allard Welter)
April 16, 2005 [matt]: Minor wording/typo fixes (Peter Ennis)
April 16, 2005 [matt]: Removed references to statically linking the pass 1 toolchain which should have gone as part of bug 1061 (Andrew Benton)
April 13, 2005 [manuel]: Spelling fixes pointed by Archiac. Added tags to fix the PDF look in chapter 06.
April 12, 2005 [manuel]: Small redaction changes. Added tags to fix the PDF look in all chapters except chapter 06.
April 11, 2005 [manuel]: Mention bzip2's testsuite. Several tags and text corrections.
April 6, 2005 [matt]: Move e2fsprogs sed command to before entering the build directory (Steffen R. Knollmann).
April 4, 2005 [matt]: Typo: The udev initscript registers udevsend, not udev, as the hotplug handler (Bryan Kadzban)
April 4, 2005 [matt]: No need to manually create
/var/log/hotplug
as
hotplug's Makefile creates it (Ken Moffat). Also minor
rewording to improve consistency.
April 4, 2005 [matt]: Fix e2fsprogs compile problem (Ken Moffat & Greg Schafer)
April 2, 2005 [jhuntwork]: Fixed dtd url for sysklogd xml files
March 31, 2005 [jhuntwork]: Changed the link for less to point to ftp.gnu.org
March 31, 2005 [matt]: Upgraded to LFS-Bootscripts 3.2.0
March 31, 2005 [matt]: Upgraded to m4-1.4.3
March 30, 2005 [matt]: Upgraded to iproute2-2.6.11-050330
March 30, 2005 [jhuntwork]: Removed syslog-ng-1.6.6, libol-0.3.15. Reinstated sysklogd-1.4.1. Thanks to Archaic for the patch.
March 26, 2005 [matt]: Upgraded to linux-libc-headers-2.6.11.2
March 26, 2005 [matt]: Upgraded to linux-libc-headers-2.6.11.1
March 26, 2005 [matt]: Upgraded to linux-2.6.11.6
March 22, 2005 [jim]: Upgraded to e2fsprogs-1.3.7.
March 21, 2005 [jim]: Added patch to fix issue with shadow and lastlog.
March 19, 2005 [jim]: Added patch to fix issue with tar -S
March 19, 2005 [matt]: Removed references to kernel security patch
March 19, 2005 [jim]: Upgraded to udev-056
March 19, 2005 [jim]: Upgraded to linux-2.6.11.5
March 19, 2005 [jim]: Change references to Iproute2 to IPRoute2
March 18, 2005 [jim]: Upgraded to Findutils 4.2.20
March 16, 2005 [jim]: Upgraded to linux-2.6.11.4
March 16, 2005 [jim]: Removed reference to kernel security patch
March 16, 2005 [jim]: Removed find_update patch for IPRoute2, it is not needed anymore
March 15, 2005 [matt]: Upgraded to iproute2-2.6.11-050314
March 14, 2005 [matt]: List the installed files/directories descriptions in a somewhat more alphabetic order.
March 14, 2005 [matt]: Fix typos, and reword some of the hotplug explanations for (hopefully) improved clarity
March 14, 2005 [matt]: Upgraded to gettext-0.14.3
March 14, 2005 [jim]: Added /var/log/hotplug
for capturing of
hotplug events. Added /lib/firmware for firmware loading
with hotplug
March 13, 2005 [jim]: Updated iproute2 db patch to iproute2-2.6.11-050310. Removed unneeded find_update patch also for iproute2-2.6.11-050310
March 13, 2005 [matt]: Upgraded to iproute2-2.6.11-050310
March 13, 2005 [matt]: Upgraded to linux-2.6.11.3 and linux-libc-headers-2.6.11.0
March 13, 2005 [matt]: Reword About SBUs section to reflect the earlier fix for bug 1061
March 13, 2005 [matt]: Dynamically link the pass1 toolchain to workaround bug 1061 and remove all related explanatory text
March 12, 2005 [matt]: Upgraded to udev-054
March 12, 2005 [matt]: Upgraded to findutils-4.2.19
March 12, 2005 [matt]: Upgraded psmisc to 21.6
March 10, 2005 [matt]: gettext no longer installs libgettext{lib,src}.a (Jack Brown)
March 3, 2005 [matt]: Remove --without-cvs from glibc instructions, as we're not using glibc CVS snapshots anymore
March 3, 2005 [matt]: Fixed a couple of typo's in the download locations
March 2, 2005 [matt]: Add note regarding potential custom features in a host distribution's version of e2fsprogs. Fixes bug 1047. Thanks to Steve Crosby for the suggested explanatory text.
March 2, 2005 [jim]: Update download locations
February 28, 2005 [jim]: Upgraded bash fixes patch to -3
February 28, 2005 [matt]: Upgraded binutils to 2.14.94.0.2.2
February 28, 2005 [matt]: Move /usr/bin/logger
to /bin
as the bootscripts need it there.
Fixes bug 1035.
February 28, 2005 [matt]: Upgraded to iana-etc-1.04
February 28, 2005 [matt]: Correct the instructions for invoking udev's testsuite (Randy McMurchy)
February 27, 2005 [matt]: Correct the title of the readline patch in chapter 3. Fixes bug 1049
February 27, 2005 [matt]: Mention udev's testsuite. Fixes bug 1042
February 27, 2005 [matt]: Use --without-csharp instead of --disable-csharp, as the latter doesn't work as intended. Fixes bug 1033
February 27, 2005 [matt]: Upgraded to gettext-0.14.2
February 27, 2005 [matt]: Upgraded to findutils-4.2.18
February 27, 2005 [matt]: Upgraded to bzip2-1.0.3
February 19, 2005 [gerard]: Chapter 5-Stripping: removed
doc
from the directories to
be removed in /tools
. This
directory is not created anymore.
February 19, 2005 [jeremy]: Added correction to chapter 5 glibc build to fix the disabling of selinux functionality. Thanks to Bobson on IRC (bobson@bobson.net) for pointing this out. Closes bugzilla 1034.
February 19, 2005 [gerard]: Synchronized Testing branch with current Unstable/Trunk. Move Testing branch to Trunk and discontinue Testing branch as per lfs-dev discussion on branch changes.
February 5, 2005 [matt]: Copy hotplug's pnp.distmap file to silence its warnings. Also tidy up some explanatory text
January 29, 2005 [matt]: Upgraded to sed-4.1.4
January 29, 2005 [matt]: Upgraded to procps-3.2.5
January 29, 2005 [matt]: Upgraded to shadow-4.0.7
January 29, 2005 [matt]: Upgraded to util-linux-2.12q.
January 27, 2005 [matt]: Added a warning that the
/usr/src/linux
symlink
shouldn't be created. Fixes bug 1012.
January 27, 2005 [matt]: Added link to the live-cd FTP location. Fixes bug 1014.
January 27, 2005 [matt]: Added bison, flex and m4 to binutils dependency list. Fixes Bug 1018.
January 27, 2005 [manuel]: Updated to gcc-3.4.3-specs-2.patch.
January 19, 2005 [jeremy]: Added an extra symlink for libgcc_s.so to chapter 6 - this never migrated from unstable until now.
January 9, 2005 [matt]: Added a security patch for the kernel
January 9, 2005 [matt]: Added a security patch for vim
January 9, 2005 [matt]: Upgraded to man-1.5p
January 9, 2005 [matt]: Upgraded to texinfo-4.8
January 9, 2005 [matt]: Upgraded to util-linux-2.12p
January 9, 2005 [matt]: Upgraded to udev-050
January 9, 2005 [matt]: Upgraded to tcl-8.4.9
January 9, 2005 [matt]: Upgraded to tar-1.15.1
January 9, 2005 [matt]: Upgraded to perl-5.8.6
January 9, 2005 [matt]: Upgraded to man-pages-2.01
January 9, 2005 [matt]: Upgraded to linux-libc-headers-2.6.10.0
January 9, 2005 [matt]: Upgraded to linux-2.6.10
January 9, 2005 [matt]: Upgraded to gcc-3.4.3
January 9, 2005 [matt]: Upgraded to bison-2.0
January 9, 2005 [matt]: Upgraded to autoconf-1.9.4
January 5, 2005 [jeremy]: Minor textual correction in network configuration, since iproute will not recognize the old eth0:1 format for ip aliasing. Closes bug 1013.
January 5, 2005 [jeremy]: Added the --disable-selinux parameter to Ch 5 glibc. Allows building from hosts which use SELinux functionality, like Fedora Core 3
December 25, 2004 [jeremy]: Added text suggested by MSB, closing Bug 943
December 25, 2004 [jeremy]: Upgraded binutils to 2.14.94.0.2 - should fix the TLS strip issue that's been seen, at least on X86
December 22, 2004 [manuel]: Readded to chapter09/reboot.xml a para lost from version 5.1.
December 20, 2004 [manuel]: Made grub's configuration location FHS compliant.
December 19, 2004 [manuel]: Added the irc.lfs-matrix.de IRC server.
December 5, 2004 [jeremy]: Added the DOCBOOKTOMAN parameter to Module-init-utils - without this, compilation fails. Thanks Boris Buegling
December 2, 2004 [jeremy]: Removed the old display_wrap bash patch, in favor of the newer fixes patch, and added the avoid_WCONTINUED patch as well
December 2, 2004 [jeremy]: Upgraded to TCL 8.4.8, Grep 2.5.1a Util-linux 2.12i, Iana-etc 1.03, File 4.12, Module-init-tools 3.1, Procps 3.2.4
December 2, 2004 [jeremy]: Migrated change from unstable to build Glibc against sanitized linux-libc-headers instead of raw kernel headers, bringing us more in line with what the kernel developers think should be happening.
December 1, 2004 [jeremy]: Dropped Udev from being built in Chapter 5, in favor of creating a minimal set of devices at the beginning of Chapter 6. All devices are created after the installation of Udev near the end of Chapter 6
December 1, 2004 [jeremy]: Upgraded to Automake 1.9.3, Binutils 2.15.92.0.2, Findutils 4.2.3, GCC 3.4.2, Glibc 20041011, Iana-Etc 1.02 Iproute2 2.6.9-041019, LFS-Bootscripts 2.2.3, Libtool 1.5.10, Linux 2.6.9 Linux-libc-headers 2.6.9.1, Man 1.5o1, Man-pages 1.70, Shadow 4.0.6, Udev 046, Zlib 1.2.2, Hotplug 2004_09_23, Libol 0.3.14, Syslog-ng 1.6.5
Sortie de la version 6.0 le 10 octobre 2004.
Si vous rencontrez des erreurs lors de la construction du système LFS, si vous avez des questions ou si vous pensez qu'il y a une erreur de typographie dans ce livre, merci de commencer par consulter la FAQ (Foire aux Questions) sur http://www.linuxfromscratch.org/faq/.
Le serveur linuxfromscratch.org
gère
quelques listes de diffusion utilisées pour le développement
du projet LFS. Ces listes incluent, entre autres, les listes
de développement et de support.
Pour connaître les listes disponibles, les conditions d'abonnement, l'emplacement des archives et quelques autres informations, allez sur http://www.linuxfromscratch.org/mail.html.
Les listes de diffusion gérées par linuxfromscratch.org
sont aussi accessibles via
le serveur NNTP. Tous les messages envoyés sur une liste de
diffusion sont copiés dans le groupe de nouvelles
correspondant, et vice-versa.
Le serveur de nouvelles est situé sur news.linuxfromscratch.org.
Plusieurs membres de la communauté LFS offrent une assistance
sur le réseau IRC (Internet Relay Chat) de notre communauté.
Avant d'utiliser ce mode de support, assurez-vous que la
réponse à votre question ne se trouve pas déjà dans la FAQ
LFS (voir ci-dessus) ou dans les archives des listes de
diffusion (voir ci-dessous) pour tenter de trouver une
réponse à votre question. Vous trouverez le réseau IRC à
l'adresse irc.linuxfromscratch.org
,
port 6667. Le canal du support se nomme #LFS-support.
Pour plus d'informations sur les paquets, des indications très utiles sont disponibles dans la page de référence des paquetages LFS située sur : http://www.109bean.org.uk/LFS-references.html.
Le projet LFS a un bon nombre de miroirs configurés tout autour du monde pour faciliter l'accès au site web ainsi que le téléchargement des paquetages requis. Merci de visiter le site web de LFS sur http://www.linuxfromscratch.org/mirrors.html pour obtenir une liste des miroirs à jour.
Si vous rencontrez une erreur ou si vous vous posez une question en travaillant avec ce livre, vérifiez la FAQ dont la page est située sur http://www.linuxfromscratch.org/faq/#generalfaq. Les questions y ont souvent des réponses. Si votre question n'a pas sa réponse sur cette page, essayez de trouver la source du problème. L'astuce suivante vous donnera quelques conseils pour cela : http://www.linuxfromscratch.org/hints/downloads/files/errors.txt.
Nous avons aussi une formidable communauté LFS, volontaire pour offrir une assistance via les listes de discussion et IRC (voir la section la section intitulée « Ressources » de ce livre). Pour assister au diagnostic et à la résolution du problème, merci d'inclure toute information utile dans votre demande d'aide.
À part une brève explication du problème, voici les éléments essentiels à inclure dans votre demande d'aide :
La version du livre que vous utilisez (dans ce cas, 6.1)
La distribution hôte (et sa version) que vous utilisez pour créer LFS
Le paquet ou la section où le problème a été rencontré
Le message d'erreur exact ou le symptôme reçu
Notez si vous avez dévié du livre
Dévier du livre ne signifie pas que nous n'allons pas vous aider. Après tout, LFS est basé sur les préférences de l'utilisateur. Nous préciser les modifications effectuées sur la procédure établie nous aide à évaluer et à déterminer les causes probables de votre problème.
Si quelque chose se passe mal lors de l'exécution du script
configure,
regardez le fichier config.log
.
Ce fichier pourrait contenir les erreurs rencontrées lors de
l'exécution de configure qui n'ont pas été
affichées à l'écran. Incluez les lignes intéressantes si vous avez besoin
d'aide.
L'affichage écran et le contenu de différents fichiers sont utiles pour déterminer la cause des problèmes de compilation. L'affichage de l'écran du script configure et du make peuvent être utiles. Il n'est pas nécessaire d'inclure la sortie complète mais incluez suffisamment d'informations intéressantes. Ci-dessous se trouve un exemple de type d'informations à inclure à partir de l'affichage écran de make :
gcc -DALIASPATH=\"/mnt/lfs/usr/share/locale:.\"
-DLOCALEDIR=\"/mnt/lfs/usr/share/locale\"
-DLIBDIR=\"/mnt/lfs/usr/lib\"
-DINCLUDEDIR=\"/mnt/lfs/usr/include\" -DHAVE_CONFIG_H -I. -I.
-g -O2 -c getopt1.c
gcc -g -O2 -static -o make ar.o arscan.o commands.o dir.o
expand.o file.o function.o getopt.o implicit.o job.o main.o
misc.o read.o remake.o rule.o signame.o variable.o vpath.o
default.o remote-stub.o version.o opt1.o
-lutil job.o: In function `load_too_high':
/lfs/tmp/make-3.79.1/job.c:1565: undefined reference
to `getloadavg'
collect2: ld returned 1 exit status
make[2]: *** [make] Error 1
make[2]: Leaving directory `/lfs/tmp/make-3.79.1'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/lfs/tmp/make-3.79.1'
make: *** [all-recursive-am] Error 2
Dans ce cas, beaucoup de personnes n'inclueraient que la section du bas :
make [2]: *** [make] Error 1
Cette information n'est pas suffisante pour diagnostiquer correctement le problème car il note seulement que quelque chose s'est mal passé, par ce qui s'est mal passé. La section entière, comme dans l'exemple ci-dessus, est ce qui devrait être sauvé car la commande exécutée et le(s) message(s) d'erreur associé(s) sont inclus.
Un excellent article sur les demandes d'aide sur Internet est disponible en ligne sur http://catb.org/~esr/faqs/smart-questions.html. Lisez et suivez les astuces de ce document pour accroître vos chances d'obtenir l'aide dont vous avez besoin.
Dans ce chapitre, la partition qui contiendra le système LFS est préparée. Nous créerons la partition elle-même, lui ajouterons un système de fichiers et nous la monterons.
Comme la plupart des autres systèmes d'exploitation, LFS est habituellement installé dans une partition dédiée. L'approche recommandée pour la construction d'un système LFS est d'utiliser une partition vide disponible ou, si vous avez assez d'espace non partitioné, d'en créer une. Néanmoins, un système LFS (en fait, même plusieurs systèmes LFS) peuvent aussi être installés sur une partition déjà occupée par un autre système d'exploitation. Les différents systèmes cohabiteront en paix. Le document http://www.linuxfromscratch.org/hints/downloads/files/lfs_next_to_existing_ systems.txt expliquer comment implémenter ceci alors que ce livre se base sur la méthode utilisant une partition vierge pour l'installation.
Un système minimal requiert une partition d'environ 1,3 Go. C'est suffisant pour conserver toutes les archives tar des sources et pour compiler tous les paquets. Néanmoins, si le système LFS a pour but d'être un système Linux primaire, des logiciels supplémentaires seront probablement installés et réclameront une place supplémentaire (entre 2 et 3 Go). Le système LFS lui-même ne prendre pas tout cet espace. Une grande partie de cet espace est requis pour fournir un espace libre suffisant mais temporaire. Compiler des paquets peut demander beaucoup d'espace disque qui sera récupéré après l'installation du paquet.
Parce qu'il n'y a pas toujours assez de mémoire (RAM) disponible pour les processus de compilation, une bonne idée est d'utiliser une petite partition comme espace d'échange (swap). Cet espace est utilisé par le noyau pour stocker des données rarement utilisées et pour laisser plus de place disponible aux processus actifs. La partition de swap pour un système LFS peut être le même que celui utilisé par le système hôte, donc une autre partition n'a pas besoin d'être créé si votre système hôte a déjà cette configuration.
Lancez un programme de partitionnement de disques tel que
cfdisk ou
fdisk avec une
option en ligne de commande nommant le disque dur sur lequel la
nouvelle partition sera créée—par exemple /dev/hda
pour un disque IDE. Créez une
partition Linux native et, si nécessaire, une partition de
swap. Merci de vous référer aux pages man de
cfdisk(8) ou
fdisk(8) si vous
ne savez pas encore utiliser le programme.
Rappellez-vous de la désignation de la nouvelle partition
(c'est-à-dire hda5
). Ce livre y
fera référence en tant que la partition LFS. Rappellez-vous
aussi de la désignation de la partition swap. Ces noms seront
nécessaires après pour le fichier /etc/fstab
.
Maintenant qu'une partition vierge est prête, le système de fichiers peut être créé. Le système le plus communément utilisé dans le monde Linux est le système de fichiers étendu, deuxième version, (plus connu sous son acronyme, ext2), mais avec les nouveaux disques haute capacité, les systèmes de fichiers journalisés deviennent de plus en plus populaires. Nous créerons un système de fichiers ext2. Les instructions de construction d'autres systèmes de fichiers sont disponibles dans http://www.linuxfromscratch.org/blfs/view/svn/ postlfs/filesystems.html.
Pour créer un système de fichiers ext2 sur la partition LFS, lancez ce qui suit :
mke2fs /dev/[xxx]
Remplacez [xxx]
avec
le nom de la partition LFS (hda5
dans notre exemple précédent).
Quelques distributions hôtes utilisent des fonctionnalités personnalisées dans leur outil de création de systèmes de fichiers (e2fsprogs). Ceci peut poser des problèmes lors du démarrage dans votre nouveau LFS au chapitre 9 car toutes ces fonctionnalités ne seront pas supportées par la version d'e2fsprogs installée par LFS si vous obtenez une erreur similaire à « unsupported filesystem features, upgrade your e2fsprogs ». Pour vérifier que votre système hôte utilise des améliorations personnalisées, utilisez la commande suivante :
debugfs -R feature /dev/[xxx]
Si la sortie contient des fonctionnalités autres que dir_index, filetype, large_file, resize_inode ou sparse_super, alors votre système hôte pourrait avoir des améliorations personnalisées. Dans ce cas, pour éviter tout problème ultérieur, vous devez compiler le paquetage e2fsprogs et utiliser les binaires résultant de cette compilation pour re-créer le système de fichiers sur votre partition LFS :
cd /tmp tar xjf /path/to/sources/e2fsprogs-1.37.tar.bz2 cd e2fsprogs-1.37 mkdir build cd build ../configure make #note that we intentionally don't 'make install' here! ./misc/mke2fs /dev/[xxx] cd /tmp rm -rf e2fsprogs-1.37
Si une partition de swap a été créée, elle devra être initialisée, pour pouvoir être utilisée, en exécutant la commande ci-dessous. Si vous utilisez déjà une partition de swap, il n'est pas nécessaire de la formater.
mkswap /dev/[yyy]
Remplacez [yyy]
avec
le nom de la partition de swap.
Maintenant qu'un système de fichiers a été créé, la partition
doit être accessible. Pour cela, la partition a besoin d'être
montée sur un point de montage choisi. Pour ce livre, il est
supposé que le système de fichiers est monté sous /mnt/lfs
mais le choix du répertoire vous
appartient.
Choisissez un point de montage et affectez-le à la variable
d'environnement LFS
en
lançant :
export LFS=/mnt/lfs
Maintenant, créez le point de montage et montez le système de fichiers LFS en lançant :
mkdir -p $LFS mount /dev/[xxx] $LFS
Remplacez [xxx]
avec
la désignation de la partition LFS.
Si vous utilisez plusieurs partitions pour LFS (c'est-à-dire
une pour /
et une autre pour
/usr
), montez-les en
utilisant :
mkdir -p $LFS mount /dev/[xxx] $LFS mkdir $LFS/usr mount /dev/[yyy] $LFS/usr
Remplacez [xxx]
et
[yyy]
avec les noms
de partition appropriés.
Assurez-vous que cette nouvelle partition n'est pas montée avec
des droits trop restrictifs (telles que les options nosuid,
nodev ou noatime. Lancez la commande mount sans aucun paramètre pour voir
les options configurées pour la partition LFS montée. Si
nosuid
, nodev
et/ou noatime
sont configurées, la
partition devra être remontée.
Maintenant qu'il existe un endroit établi pour travailler, il est temps de télécharger ces paquets.
Ce chapitre inclut une liste de paquets devant être téléchargés pour construire un système Linux basique. Les numéros de versions affichés correspondent aux versions des logiciels qui, selon nous, fonctionnent à coup sûr. Le livre est basé sur leur utilisation. Nous vous recommandons fortement de ne pas utiliser de versions supérieures car les commandes de construction pour une version pourraient ne pas fonctionner avec une version plus récente. Les versions plus récentes pourraient aussi avoir des problèmes nécessitant des contournements. Ces derniers seront développés et stabilisés dans la version de développement du livre.
Tous les liens (URL), si possible, réfèrent à la page d'informations du paquet sur http://www.freshmeat.net/. Les pages Freshmeat fournissent un accès aisé aux sites de téléchargement officiels ainsi qu'aux site web des projets, aux listes de discussion, à la FAQ, aux journaux des modifications (changelog) et bien plus encore !
Les emplacements de téléchargements pourraient ne pas être toujours accessibles. Si un emplacement de téléchargement a changé depuis la publication de ce livre, Google (http://www.google.com/) fournit un outil de recherche puissant pour la plupart des paquets. Si cette recherche n'a pas de succès, essayez un autre moyen de téléchargement, disponibles sur http://www.linuxfromscratch.org/ lfs/packages.html.
Les paquets et les correctifs téléchargés doivent être stockés
quelque part où ils seront facilement disponibles pendant toute
la construction. Un répertoire fonctionnel est aussi requis
pour déballer les sources et pour les construire. Le répertoire
$LFS/sources
peut être utilisé à
la fois comme emplacement de stockage pour les archives tar et
les correctifs, mais aussi comme répertoire fonctionnel. En
utilisant ce répertoire, les éléments requis seront situés sur
la partition LFS et seront disponibles à toutes les étapes du
processus de construction.
Pour créer ce répertoire, lancez, en tant qu'utilisateur root, la commande suivante, avant de commencer la session de téléchargement :
mkdir $LFS/sources
Donnez le droit d'écriture et le droit sticky sur ce répertoire. « Sticky » signifie que même si de nombreux utilisateurs peuvent d'écrire sur un répertoire, seul le propriétaire du fichier peut supprimer ce fichier à l'intérieur du répertoire sticky. La commande suivante activera les droits d'écriture et sticky :
chmod a+wt $LFS/sources
Téléchargez ou obtenez autrement les paquets suivants :
ftp://ftp.gw.com/mirrors/pub/unix/file/
File (4.13) pourrait ne plus être disponible à l'emplacement indiqué. Les administrateurs du site de téléchargement principal suppriment de temps en temps les anciennes versions lorsque de nouvelles sont disponibles. Un autre emplacement de téléchargement, pouvant avoir à disposition la bonne version, est ftp://ftp.linuxfromscratch.org/pub/lfs/.
http://www.kernel.org/pub/linux/utils/kernel/module-init-tools/
ftp://ftp.pld.org.pl/software/shadow/
Shadow (4.0.9) pourrait ne plus être disponible à l'emplacement indiqué. Les administrateurs du site de téléchargement principal suppriment de temps en temps les anciennes versions lorsque de nouvelles sont disponibles. Un autre emplacement de téléchargement, pouvant avoir à disposition la bonne version, est ftp://ftp.linuxfromscratch.org/pub/lfs/.
Taille totale de ces paquets : 146 Mo
En plus des paquets, quelques correctifs sont aussi requis. Ces correctifs corrigent certaines erreurs contenues dans les paquets, ces erreurs devraient être corrigées par le mainteneur. Les correctifs font aussi quelques modifications pour faciliter l'utilisation des paquets. Les correctifs suivants seront nécessaires pour construire un système LFS :
http://www.linuxfromscratch.org/patches/lfs/6.1/bash-3.0-fixes-3.patch
http://www.linuxfromscratch.org/patches/lfs/6.1/bash-3.0-avoid_WCONTINUED-1.patch
http://www.linuxfromscratch.org/patches/lfs/6.1/coreutils-5.2.1-suppress_uptime_kill_su-1.patch
http://www.linuxfromscratch.org/patches/lfs/6.1/coreutils-5.2.1-uname-2.patch
http://www.linuxfromscratch.org/patches/lfs/6.1/expect-5.43.0-spawn-1.patch
http://www.linuxfromscratch.org/patches/lfs/6.1/flex-2.5.31-debian_fixes-3.patch
http://www.linuxfromscratch.org/patches/lfs/6.1/gcc-3.4.3-linkonce-1.patch
http://www.linuxfromscratch.org/patches/lfs/6.1/gcc-3.4.3-no_fixincludes-1.patch
http://www.linuxfromscratch.org/patches/lfs/6.1/gcc-3.4.3-specs-2.patch
http://www.linuxfromscratch.org/patches/lfs/6.1/glibc-2.3.4-fix_test-1.patch
http://www.linuxfromscratch.org/patches/lfs/6.1/gzip-1.3.5-security_fixes-1.patch
http://www.linuxfromscratch.org/patches/lfs/6.1/inetutils-1.4.2-kernel_headers-1.patch
http://www.linuxfromscratch.org/patches/lfs/6.1/inetutils-1.4.2-no_server_man_pages-1.patch
http://www.linuxfromscratch.org/patches/lfs/6.1/iproute2-2.6.11_050330-remove_db-1.patch
http://www.linuxfromscratch.org/patches/lfs/6.1/mktemp-1.5-add_tempfile-2.patch
http://www.linuxfromscratch.org/patches/lfs/6.1/perl-5.8.6-libc-1.patch
http://www.linuxfromscratch.org/patches/lfs/6.1/readline-5.0-fixes-1.patch
http://www.linuxfromscratch.org/patches/lfs/6.1/sysklogd-1.4.1-fixes-1.patch
http://www.linuxfromscratch.org/patches/lfs/6.1/tar-1.15.1-sparse_fix-1.patch
http://www.linuxfromscratch.org/patches/lfs/6.1/util-linux-2.12q-cramfs-1.patch
http://www.linuxfromscratch.org/patches/lfs/6.1/vim-6.3-security_fix-1.patch
http://www.linuxfromscratch.org/patches/lfs/6.1/zlib-1.2.2-security_fix-1.patch
En plus des correctifs requis ci-dessus, il existe un certain nombre de correctifs optionnels créés par la communauté LFS. Ces correctifs résolvent des problèmes mineurs ou activent des fonctionnalités qui ne sont pas disponibles par défaut. Vous pouvez consulter la base de données des correctifs à loisir sur http://www.linuxfromscratch.org/patches/ et vous pouvez récupérer tout correctif supplémentaire correspondant aux besoins de votre système.
Tout au long de ce livre, la variable d'environnement
LFS
sera utilisée de nombreuses
fois. Il est vitale que cette variable soit toujours définie.
Elle doit pointer vers le point de montage choisi pour la
partition LFS. Vérifiez que votre variable LFS
est correctement configurée avec :
echo $LFS
Assurez-vous que la sortie affiche le chemin vers le point de
montage de la partition LFS, c'est-à-dire /mnt/lfs
si l'exemple fourni a été suivi. Si
cet affichage est mauvais, vous pouvez toujours initialiser la
variable avec :
export LFS=/mnt/lfs
Avoir cette variable initialisée est tout à votre bénéfice car
des commandes telles que mkdir
$LFS/tools
peuvent être saisies de façon
littérale. Votre shell remplacera « $LFS » par « /mnt/lfs » (ou par ce chemin avec lequel
vous avez initialisé la variable) lorsqu'il exécutera la ligne
de commande.
N'oubliez pas de vérifier que $LFS
est initialisé à chaque fois que vous entrez dans
l'environnement (par exemple, avec « su » pour root ou un autre utilisateur).
Tous les programmes compilés dans le Chapitre 5 seront installés dans
$LFS/tools
pour les tenir séparés
des programmes compilés dans le Chapter 6. Les programmes
compilés ici sont seulement des outils temporaires et ne
prendront pas part au système LFS final. En les conservant dans
un répertoire séparé, nous pourrons facilement les supprimer
plus tard. Ceci nous aide aussi à les empêcher de finir dans
les répertoires de production de votre hôte (facile à faire par
accident dans le Chapitre
5).
Créez le répertoire requis en lançant la commande suivante en tant qu'utilisateur root :
mkdir $LFS/tools
La prochaine étape consiste en la création du lien symbolique
/tools
sur votre système
hôte. Il pointera vers
le répertoire que vous venez de créer sur la partition LFS.
Lancez cette commande en tant qu'utilisateur root :
ln -s $LFS/tools /
La commande ci-dessus est correcte. La commande
ln a quelques
variations syntaxiques, assurez-vous de vérifier
info coreutils
ln et la page man ln(1)
avant de rapporter ce que vous
pensez être une erreur.
Le lien symbolique créé nous permet de compiler notre ensemble
d'outils de façon à ce qu'il se réfère à /tools
, ce qui signifie que le compilateur,
l'assembleur et l'éditeur de liens fonctionneront tous dans ce
chapitre (alors que nous utilisons toujours quelques outils
provenant de l'hôte) et dans le suivant (lorsque nous serons en
« chroot » sur la
partition LFS).
Lorsque vous êtes connecté en tant qu'utilisateur root, faire une simple erreur peut endommager voire dévaster votre système. Donc, nous recommandons de construire les paquets dans ce chapitre en tant qu'utilisateur non privilégié. Vous pouvez bien sûr utiliser votre propre nom d'utilisateur mais, pour faciliter l'établissement d'un environnement de travail propre, créez un nouvel utilisateur nommé lfs comme membre d'un nouveau groupe lfs et utilisez-le lors du processus d'installation. En tant que root, lancez les commandes suivantes pour créer le nouvel utilisateur :
groupadd lfs useradd -s /bin/bash -g lfs -m -k /dev/null lfs
Voici la signification des options en ligne de commande :
-s
/bin/bash
Ceci fait de bash le shell par défaut de l'utilisateur lfs.
-g
lfs
Cette option ajouté l'utilisateur lfs au groupe lfs.
-m
Ceci crée un répertoire personnel pour l'utilisateur lfs.
-k
/dev/null
Ce paramètre empêche tout copie possible de fichiers
provenant du répertoire squelette (par défaut,
/etc/skel
) en modifiant son
emplacement par le périphérique spécial null.
lfs
Ceci est le nom réel pour le groupe et l'utilisateur créé.
Pour vous connecter en tant qu'utilisateur lfs (et non pas de passer à l'utilisateur lfs alors que vous êtes connecté en tant que root, ce qui ne requiert pas de mot de passe pour l'utilisateur lfs), donnez un mot de passe à lfs :
passwd lfs
Donnez-lui un accès complet à $LFS/tools
en indiquant que lfs est le propriétaire du
répertoire :
chown lfs $LFS/tools
Si un répertoire de travail séparé a été créé comme suggéré, faites que l'utilisateur lfs soit aussi le propriétaire de ce répertoire :
chown lfs $LFS/sources
Ensuite, connectez-vous en tant que lfs. Ceci peut se faire via une console virtuelle, avec le gestionnaire d'affichage ou avec la commande suivante de substitution d'utilisateur :
su - lfs
Le « - » indique à
su de lancer un
shell de connexion. La différence entre un shell de connexion
et un autre se trouve dans la page man bash(1)
et dans info bash.
Configurez un bon environnement de travail en créant deux
nouveaux fichiers de démarrage pour le shell
bash. En étant
connecté en tant qu'utilisateur lfs, lancez la commande suivante
pour créer un nouveau .bash_profile
:
cat > ~/.bash_profile << "EOF" exec env -i HOME=$HOME TERM=$TERM PS1='\u:\w\$ ' /bin/bash EOF
Lorsque vous êtes connecté en tant que lfs, le shell initial est
habituellement un shell de connexion qui lit le fichier
/etc/profile
de l'hôte (contenant
probablement quelques configurations et variables
d'environnement) et puis .bash_profile
. La commande
exec env
-i.../bin/bash dans le fichier .bash_profile
remplace le shell en cours avec
un nouveau ayant un environnement complètement vide sauf pour
les variables HOME
, TERM
et PS1
. Ceci
nous assure qu'aucune variable d'environnement non souhaitée et
potentiellement dangereuse, provenant du système hôte, ne
parvienne dans l'environnement de construction. La technique
utilisée ici s'assure de ce but d'environnement propre.
La nouvelle instance du shell est un shell sans connexion, qui ne lit donc pas
les fichiers /etc/profile
et
.bash_profile
mais plutôt le
fichier .bashrc
. Créez le fichier
.bashrc
maintenant :
cat > ~/.bashrc << "EOF" set +h umask 022 LFS=/mnt/lfs LC_ALL=POSIX PATH=/tools/bin:/bin:/usr/bin export LFS LC_ALL PATH EOF
La commande set
+h désactive la fonction de hachage de
bash. D'habitude,
le hachage est une fonctionnalité utile. bash utilise une table de hachage
pour se rappeler le chemin complet des fichiers exécutables
pour éviter d'avoir à chercher dans PATH
à chaque fois qu'il doit trouver le même
exécutable. Néanmoins, les nouveaux outils devraient être
utilisés dès leur installation. En désactivant la fonction de
hachage, le shell cherchera en permanence dans PATH
lorsqu'un programme doit être exécuté.
Ainsi, le shell trouvera les nouveaux outils compilés dans
$LFS/tools
dès qu'ils sont
disponibles et sans se rappeller de la version précédente du
même programme mais dans un autre emplacement.
Configurer le masque de création de fichier (umask) à 022 nous assure que les nouveaux fichiers et répertoires créés sont modifiables uniquement par leurs propriétaires mais lisibles et exécutables par tout le monde (en supposant que les modes par défait sont utilisés par l'appel système open(2), les nouveaux fichiers finiront avec les droits 644 et les répertoires avec 755).
La variable LFS
devrait être
configurée avec le point de montage choisi.
La variable LC_ALL
contrôle la
localisation de certains programmes, faisant que leurs messages
suivent les conventions d'un pays spécifié. Si le système hôte
utilise une version de Glibc plus ancienne que la 2.2.4, avoir
LC_ALL
initialisé à quelque chose
d'autre que « POSIX » ou
« C » (pendant ce
chapitre) pourrait poser des problèmes si vous quittez
l'environnement chroot et souhaitez y retourner plus tard.
Initialiser LC_ALL
à
« POSIX » ou
« C » (les deux sont
équivalents) nous assure que tout fonctionnera comme attendu
dans l'environnement chroot.
En plaçant /tools/bin
au début du
PATH
standard, tous les programmes
installées dans Chapitre
5 sont récupérés par le shell immédiatement après leur
installation. Ceci, combiné avec la désactivation du hachage,
limite le risque que d'anciens programmes de l'hôte soient
utilisés alors que les mêmes programmes sont disponibles depuis
l'environnement du chapitre 5.
Enfin, pour avoir un environnement complètement préparé pour la construction des outils temporaires, récupérez le source du profile de l'utilisateur tout juste créé :
source ~/.bash_profile
Beaucoup de personnes souhaitent savoir combien de temps la compilation et l'installation de chaque paquet va prendre. Mais, Linux from Scratch est construit sur tant de systèmes différents qu'il est impossible de donner des temps précis. Le plus gros paquet (Glibc) prendra approximativement vingt minutes sur les systèmes les plus rapides mais pourrait prendre environ trois jours sur les moins rapides. Au lieu de donner les temps constatés, l'unité de construction standard (Standard Binutils Unit) est utilisée.
La mesure SBU fonctionne ainsi. Le premier paquet lié statiquement, que vous compilez dans ce livre, est Binutils lors du Chapitre 5. Le temps que prend la compilation de ce paquet est ce que nous appelons « SBU ». Tous les autres temps de compilation sont exprimés relativement à ce temps.
Par exemple, considérez un paquet spécifique dont le temps de compilation correspond à 4,5 SBU. Ceci signifie que s'il vous a fallu 10 minutes pour compiler et installer la première passe de Binutils, alors vous savez que cela prendra environ 45 minutes pour construire ce paquet. Heureusement, la plupart des temps de construction sont bien plus courts que celui de Binutils.
En général, les SBU ne sont pas vraiment précis car ils dépendent de trop de facteurs, dont la version de GCC sur votre machine hôte. Notez que les SBU sont encore moins précis sur les machines multi-processeurs (SMP). Ils sont fournis ici pour donner une estimation du temps nécessaire pour installer un paquetage mais ces nombres peuvent varier de plusieurs dizaines de minutes dans certains cas.
Si vous souhaitez voir des chronométrages réels pour des machines spécifiques, nous recommandons la page d'accueil de « The LinuxFromScratch SBU » sur http://www.linuxfromscratch.org/~bdubbs/.
La plupart des paquets disposent d'une suite de tests. Lancer cette suite de tests pour un paquet nouvellement construit est généralement une bonne idée car cela peut apporter une vérification comme quoi tout a été compilé correctement. Une suite de tests réussissant l'ensemble des vérifications prouve généralement que le paquet fonctionne à peu près comme le développeur en avait l'intention. Néanmoins, cela ne garantit pas que le paquet ne contient pas de bogues.
Certaines des suites de tests sont plus importantes que d'autres. Par exemple, les suites de tests des paquets formant le cœur de l'ensemble des outils (GCC, Binutils et Glibc, la bibliothèque C) sont de la plus grande importance étant donné leur rôle central dans un système fonctionnel. Les suites de tests pour GCC et Glibc peuvent prendre beaucoup de temps pour se terminer, spécialement sur du matériel lent, mais ils sont nécessaires.
L'expérience nous a montré qu'il y a peu à gagner en lançant ces suites de tests au Chapitre 5. Il n'y a pas d'échappatoire au fait que le système hôte exerce toujours une influence sur les tests dans ce chapitre, occassionnant fréquemment des échecs étonnants et inexplicables. Comme les outils construit dans le Chapitre 5 sont temporaires et éventuellement supprimés. Pour le lecteur habituel de ce livre, nous recommandons de ne pas lancer les suites de tests dans le Chapitre 5 pour l'utilisateur de base. Les instructions de lancement de ces suites de test sont fournies pour les testeurs et les développeurs mais elles sont réellement optionnelles pour tous les autres.
Un problème commun lors du lancement des suites de test
pour Binutils et GCC est de manquer de pseudo-terminaux
(PTY). Le symptôme est un nombre inhabituellement haut de
tests ayant échoués. Ceci peut arriver pour un certain
nombre de raisons. La plus raisonnable est que le système
hôte ne dispose pas d'un système de fichiers devpts
file configuré correctement. Ce
problème est discuté avec plus de détails dans le Chapitre 5.
Quelques fois, les suites de test des paquets échoueront mais pour des raisons dont les développeurs sont conscieux et qu'ils ont estimé non critiques. Consultez les traces situées dans http://www.linuxfromscratch.org/lfs/build-logs/6.1/ pour vérifier si ces échecs sont attendus to verify whether or not these failures are expected. Ce site est valide pour tous les tests effectués dans ce livre.
Ce chapitre montre comment compiler et installer un système Linux minimal. Ce système ne contiendra que les outils nécessaires pour commencer la construction du système LFS final dans Chapter 6 et de créer un environnement de travail avec plus de facilité pour l'utilisateur que ne le permettrait un environnement minimum.
Il y a deux étapes dans la construction de ce système minimal. La première étape consiste à construire un ensemble d'outils tous nouveaux et indépendant de l'hôte (compilateur, assembleur, éditeur de liens, bibliothèques et quelques outils). La deuxième étape utilise cet ensemble d'outils pour construire tous les autres outils essentiels.
Les fichiers compilés dans ce chapitre vont être installés sous
le répertoire $LFS/tools
, de
façon à les garder séparés des fichiers installés dans le
chapitre suivant et des répertoires de production de votre
hôte. Comme tous les paquets compilés ici sont simplement
temporaires, nous ne voulons pas polluer le futur système LFS.
Avant de lancer les instructions de construction pour un
paquet, le paquet doit être déballé déballé en tant que
l''utilisateur lfs et la
commande cd
doit être utilisé pour entrer dans le répertoire tout juste
créé. Les instructions de construction supposent que le shell
bash est utilisé.
Plusieurs paquets sont corrigés avant d'être compilés, mais seulement dans le cas où la correction est nécessaire pour résoudre un problème. Souvent, le correctif est nécessaire à la fois dans ce chapitre et dans le suivant, mais quelque fois dans seulement un des deux. Donc, ne vous inquiétez pas lorsque des instructions pour un correctif téléchargé semblent manquer. Des messages d'avertissements sur un décalage (offset) ou sur autre chose (fuzz) peuvent apparaître lors de l'application d'un correctif. Ne vous inquiétez pas pour ces messages, le correctif a bien été appliqué.
Pendant la compilation de la plupart des paquets, plusieurs messages d'avertissement du compilateur défileront sur votre écran. Ceci est normal et peut être ignoré sans danger. Ces messages d'avertissement ne sont que des avertissements—des avertissements sur un utilisation obsolète, mais pas invalide, de la syntaxe de C ou de C++. Les standards C changent assez souvent et quelques paquets continuent à utiliser les anciens standards. Ce n'est pas un véritable problème mais cela provoque les messages.
Après l'installation de chaque paquet, supprimez son répertoire source et son répertoire de construction, sauf si nous vous le demandons spécifiquement. Supprimer les sources permet de gagner de la place mais empêche aussi une mauvaise configuration lorsque le même paquet est réinstallé un peu plus tard. Seuls trois paquets ont besoin de conserver leur répertoire de sources et de construction pendant un moment pour que leur contenu soit utilisé par des commandes suivantes. Faites particulièrement attention à ces rappels.
Vérifiez une dernière fois que la variable d'environnement
LFS
est configurée
correctement :
echo $LFS
Assurez-vous que le résultat contient le bon répertoire vers le
point de montage de la partition LFS, qui est /mnt/lfs
suivant notre exemple.
echo $LFS
Cette section explique certains détails rationnels et techniques derrière la méthode de contruction. Il n'est pas essentiel de comprendre immédiatement tout ce qui se trouve dans cette section. La plupart des informations seront plus claires après avoir réalisé réellement une construction complète. Cette section peut servir de référence à tout moment lors du processus de construction.
Le but global de Chapitre 5 est de fournir un environnement temporaire où nous pouvons utiliser chroot à partir duquel nous pouvons produit une construction propre, sans soucis, du système LFS cible dans Chapter 6. Tout au long du chemin, nous nous séparons du système hôte autant que possible et, se faisant, nous construisons un ensemble d'outils qui se tient. Il devrait être noté que le processus de construction a été conçu pour minimiser les risques pour les nouveaux lecteurs et pour founir une valeur éducative maximale en même temps.
Avant de continuer, faites attention au nom de la
plateforme de travail, souvent appelé la triplette cible.
De nombreuses fois, la triplette cible sera probablement
i686-pc-linux-gnu.
Une façon simple de déterminer le nom de la triplette cible
est de lancer le script config.guess venant avec le
source pour un grand nombre de paquetages. Déballez les
sources de Binutils, lancez le script ./config.guess
et notez
la sortie.
De même, faites attention au nom de l'éditeur de liens de
la plateforme, souvent appelé le chargeur dynamique (à ne
pas confondre avec l'éditeur de liens ld faisant partie de Binutils).
Le chargeur dynamique fourni par Glibc trouve et charge les
bibliothèques partagées nécessaires à un programme pour
s'exécuter, puis l'exécute. Le nom de l'éditeur dynamique
sera habituellement ld-linux.so.2
. Sur des plateformes moins
connues, le nom pourrait être ld.so.1
alors que les nouvelles
plateformes 64 bits pourraient être nommées encore
différemment. Le nom de l'éditeur de liens dynamiques de la
plateforme peut être déterminé en cherchant dans le
répertoire /lib
du système
hôte. Une façon certaine de déterminer le nom est
d'inspecter un binaire au hasard de la hôte système en
exécutant : readelf -l
<nom du binaire> | grep interpreter
et de noter le résultat. La référence faisant autorité
couvrant toutes les plateformes est dans le fichier
shlib-versions
à la racine du
répertoire des sources de Glibc.
Quelques points techniques sur la façon dont fonctionne la méthode de construction Chapitre 5 :
Le processus est similaire dans son principe à la cross-compilation où les outils installés dans le même préfixe fonctionnent en coopération et utilisent, du coup, un peu de « magie » GNU
Une manipulation attentionnée du chemin de recherche des bibliothèques de l'éditeur de liens standard vous assure que les programmes sont liés seulement avec les bibloiothèques choisies
Une manipulation attentionnée du fichier specs
de gcc indique au compilateur
l'éditeur de liens dynamique cible à utiliser
Binutils est tout d'abord installé parce que les exécutions de Glibc et GCC par configure réalisent quelques tests de fonctionnalités sur l'assembleur et l'éditeur de liens pour déterminer quelle fonctionnalité logicielle activer ou désactiver. Ceci est plus important que vous pourriez supposer. Un GCC ou une Glibc mal configurée peut résulter en un ensemble d'outils subtilement cassé, où l'impact d'une tellle cassure ne se montrerait pas avant la fin de la construction de la distribution complète. Un échec dans la suite de tests surlignera habituellement sur cette erreur avant que trop de travail supplémentaire n'ait été réalisé.
Binutils installe son assembleur et son éditeur de liens à deux
endroits, /tools/bin
et
/tools/$TARGET_TRIPLET/bin
. Les
outils dans un emplacement sont liés en dur à l'autre. Une
facette importante de l'éditeur de liens est son ordre de
recherche des bibliothèques. Des informations détaillées
peuvent être obtenues à partir de ld en lui passant le commutateur
--verbose
. Par exemple,
un ld --verbose | grep
SEARCH
illustrera les chemins de recherche
réels et leur ordre. Il montre quels fichiers sont liés par
ld en compilant
un programme de test et en passant le commutateur --verbose
à l'éditeur de liens.
Par exemple, gcc dummy.c
-Wl,--verbose 2>&1 | grep succeeded
affichera tous les fichiers ouverts avec succès lors de
l'édition des liens.
Le prochain paquetage installé est GCC. Un exemple de ce qui peut être vu pendant son exécution de configure est :
checking what assembler to use...
/tools/i686-pc-linux-gnu/bin/as
checking what linker to use... /tools/i686-pc-linux-gnu/bin/ld
C'est important pour les raisons mentionnées ci-dessus. Cela
démontre aussi que le script configure de GCC ne cherche pas
les répertoires PATH pour trouver les outils à utiliser.
Néanmoins, lors d'une opération normale de gcc, les mêmes chemins de recherche
ne sont pas forcément utilisés. Pour trouver quel éditeur de
liens standard gcc utilisera, lancez :
gcc
-print-prog-name=ld
.
Des informations détaillées peuvent être obtenues à partir de
gcc en lui
fournissant l'option en ligne de commande -v
lors de la compilation d'un
programme de tests. Par exemple, gcc -v dummy.c
affichera des
informations détaillées sur les étapes du préprocesseur, de la
compilation et de l'assemblage, ceci incluant les chemins de
recherche inclus par gcc et leur ordre.
Le prochain paquetage installé est Glibc. Les plus importantes
considérations pour construire Glibc est le compilateur, les
outils binaires et les en-têtes du noyau. Le compilateur n'est
généralement pas un probl_me car Glibc utilise toujours le
gcc trouvé dans
un répertoire du PATH
. Les outils
binaires et les en-têtes du noyau peuvent être un peu plus
compliqués. Du coup, ne prenez pas de risque et utilisez les
options disponibles de configure pour renforcer les bonnes
sélections. Après l'exécution de configure, vérifiez le contenu du
fichier config.make
dans le
répertoire glibc-build
pour tous
les détails importants. Notez l'utilisation de CC="gcc -B/tools/bin/"
pour
contrôler les outils binaires utilisés, et l'utilisation de
-nostdinc
et -isystem
pour contrôler le chemin
de recherche des en-têtes du compilateur. Ces éléments
soulignent un aspect important du paquetage Glibc — il
est auto-suffisant en terme de machinerie de construction et ne
se repose généralement pas sur l'ensemble d'outils par défaut.
Après l'installation de Glibc, réalisez les ajustements pour
vous assurer que la recherche et l'édition de liens prennent
seulement place à l'intérieur du préfixe /tools
. Installez un ld ajusté qui a un chemin de
recherche limité, codé en dur, vers /tools/lib
. Puis, modifiez le fichier specs
de gcc pour
pointer vers le nouvel éditeur de liens dynamique dans
/tools/lib
. Cette dernière étape
est vitale pour le processus complet. Comme mentionné
ci-dessus, un chemin en dur vers un éditeur de liens est
intégré dans chaque exécutable ainsi que dans chaque exécutable
partagé (ELF). Ceci peut être inspecté en exécutant :
readelf -l <name of
binary> | grep interpreter
. Modifier le
fichier specs de gcc nous assure que chaque programme compilé à
partir de maintenant et jusqu'à la fin de ce chapitre utilisera
le nouvel éditeur de liens dynamiques dans /tools/lib
.
Le besoin d'utiliser le nouvel éditeur de liens dynamique est
aussi la raison pour laquelle le correctif Specs est appliqué
lors de la seconde passe de GCC. Échouer sur ce point résultera
en des programmes GCC ayant le nom de l'éditeur de liens
provenant du répertoire /lib
du
système hôte intégré en eux, ce qui empêchera le but de
s'éloigner de l'hôte.
Lors de la seconde passe de Binutils, nous sommes capable
d'utiliser l'option --with-lib-path
de configure pour
contrôler le chemin de recherche des bibliothèques de
ld. À partir de
là, l'ensemble d'outils principal est contenu en lui-même. Le
reste des paquetages de Chapitre 5 se contruit à partir
de la nouvelle Glibc dans /tools
.
Avant d'entrer dans l'environnement chroot dans Chapter 6, le premier paquetage
majeur à être installé est Glibc, à cause de sa nature
auto-suffisante mentionnée ci-dessus. Une fois que Glibc est
installée dans /usr
, réalisez une
rapide modification des valeurs par défaut de l'ensemble des
outils puis continuez la construction du reste du système LFS
cible.
Le paquet Binutils contient un éditeur de liens, un assembleur et d'autres outils pour gérer des fichiers objets.
Il est important que Binutils soit le premier paquet compilé parce que à la fois Glibc et GCC réalisent différents tests sur l'éditeur de liens et l'assembleur disponibles pour déterminer leur propres fonctionnalités à activer.
Ce paquet est connu pour avoir des soucis quand les options
d'optimisation par défaut (en incluant les options -march
et -mcpu
) sont modifiées. Donc, si
des variables d'environnement qui surchargent les
optimisations par défaut, telles que CFLAGS
et CXXFLAGS
,
ont été définies, supprimez cette initialisation pour la
construction de Binutils.
La documentation de Binutils recommande de construire Binutils en dehors du répertoire des sources, c'est-à-dire dans un répertoire de construction dédié :
mkdir ../binutils-build cd ../binutils-build
Pour que les valeurs SBU listées dans le reste du livre
vous soient utiles, mesurez le temps pris pour construire
ce paquet, de la configuration jusqu'à la première
installation. Pour cela, englobez les trois commandes
dans une commande time de cette façon :
time { ./configure ...
&& make && make install;
}
.
Maintenant, préparez la compilation de Binutils :
../binutils-2.15.94.0.2.2/configure --prefix=/tools --disable-nls
Voici la signification des options de configure :
--prefix=/tools
Ceci indique au script configure de se préparer à
installer les programmes Binutils dans le répertoire
/tools
.
--disable-nls
Ceci désactive l'internationalisation car ce n'est pas nécessaire pour des outils temporaires.
Continuez avec la compilation du paquet :
make
La compilation est maintenant terminée. Normalement, la suite de tests devrait être lancé mais, à ce moment, l'ensemble de travail de la suite de tests (Tcl, Expect and DejaGnu) n'est pas encore en place. Les bénéfices à lancer les tests maintenant seraient minimes car les programmes de la première passe seront bientôt remplacés par ceux de la seconde.
Installez le paquet :
make install
Ensuite, préparez l'éditeur de liens pour la phase d'« ajustement » un peu plus tard :
make -C ld clean make -C ld LIB_PATH=/tools/lib
Voici la signification des paramètres de make :
-C ld
clean
: Ceci indique au programme
make de supprimer tous les fichiers compilés du
sous-répertoire ld
.
-C ld
LIB_PATH=/tools/lib
: Cette option
reconstruit tout ce qui se trouve dans le
sous-répertoire ld
.
Spécifier la variable makefile the LIB_PATH
en ligne de commande nous
autorise à écraser la valeur par défaut et à la faire
pointer vers notre emplacement temporaire des outils.
La valeur de cette variable spécifie le chemin de
recherche des bibliothèques par défaut pour l'éditeur
de liens. Cette préparation est utilisée plus tard dans
le chapitre.
-C ld
clean
Ceci indique au programme make de supprimer tous les
fichiers compilés du sous-répertoire ld
.
-C ld
LDFLAGS="-all-static"
LIB_PATH=/tools/lib
Cette option reconstruit tout ce qui se trouve dans le
sous-répertoire ld
.
Spécifier la variable makefile the LIB_PATH
en ligne de commande nous
autorise à écraser la valeur par défaut et à la faire
pointer vers notre emplacement temporaire des outils.
La valeur de cette variable spécifie le chemin de
recherche des bibliothèques par défaut pour l'éditeur
de liens. Cette préparation est utilisée plus tard dans
le chapitre.
Ne supprimez pas encore les répertoires de construction et des sources dont vous aurez encore besoin dans leur état actuel un peu plus tard dans ce chapitre.
Les détails sur ce paquet sont disponibles dans la section intitulée « Contenu de Binutils »
Le paquet GCC contient la collection de compilateurs GNU, qui inclut les compilateurs C et C++.
Ce paquet est connu pour avoir des soucis quand les options
d'optimisation par défaut (en incluant les options -march
et -mcpu
) sont modifiées. Donc, si
des variables d'environnement qui surchargent les
optimisations par défaut, telles que CFLAGS
et CXXFLAGS
,
ont été définies, supprimez cette initialisation pour la
construction de GCC.
La documentation de GCC recommande de ne pas construire GCC dans le répertoire des sources mais dans un répertoire de construction dédié :
mkdir ../gcc-build cd ../gcc-build
Préparez la compilation de GCC :
../gcc-3.4.3/configure --prefix=/tools \ --libexecdir=/tools/lib --with-local-prefix=/tools \ --disable-nls --enable-shared --enable-languages=c
Voici la signification des options de configure :
--with-local-prefix=/tools
Le but de cette option est de supprimer /usr/local/include
du chemin de
recherche des fichiers include de gcc. Ce n'est pas absolument
essentiel ; néanmoins, c'est une aide pour
minimiser l'influence du système hôte.
--enable-shared
Cette option permet la construction de libgcc_s.so.1
et libgcc_eh.a
. Disposer de libgcc_eh.a
nous assure que le script
configure de Glibc (le prochain paquet à compiler)
produira de bons résultats.
--enable-languages=c
Cette option nous assure que seul le compilateur C sera construit.
Continuez avec la compilation du paquet :
make bootstrap
Voici la signification des paramètres de make :
bootstrap
Cette cible ne compile pas GCC une seule fois mais plusieurs fois. Il utilise les programmes compilés dans le premier tour pour se compiler une deuxième fois, puis une troisième fois. Il compare alors les deuxième et troisième compilations pour s'assurer qu'il arrive à se reproduire lui-même sans fautes, ce qui semble vouloir dire qu'il a été compilé correctement.
La compilation est maintenant terminée. À ce point, la suite de tests devrait être lancée. Mais, comme nous l'avons dit plus tôt, l'ensemble de travail de la suite de tests n'est pas encore en place. Les bénéfices à lancer les tests maintenant seraient minimes car les programmes de la première passe seront bientôt remplacés.
Installez le paquet :
make install
En touche finale, créez un lien symbolique. Beaucoup de programmes et de scripts lancent cc au lieu de gcc, ceci pour conserver des programmes génériques et donc utilisables sur tout type de système Unix où le compilateur GNU C n'est pas toujours installé. Utiliser cc permet de libérer l'administrateur système dans son choix du compilateur C à installer.
ln -s gcc /tools/bin/cc
Les détails sur ce paquet sont disponibles dans la section intitulée « Contenu de GCC »
Le paquet Linux-Libc-Headers contient les en-têtes du noyau « nettoyés ».
Pendant des années, la pratique commune était d'utiliser les
en-têtes « bruts » du
noyau (directement de l'archive tar du noyau) dans
/usr/include
mais, au fil des
ans, les développeurs du noyau ont pris fortement position
contre cet état de fait. Ceci a donné naissance au projet
Linux-Libc-Headers, qui a été conçu pour maintenir une
version stable de l'interface de programmation des
applications (API) des en-têtes du noyau Linux.
Installez les fichiers d'en-têtes :
cp -R include/asm-i386 /tools/include/asm cp -R include/linux /tools/include
Si votre architecture n'est pas i386 (compatible), ajustez la première commande en accord.
Les détails sur ce paquet sont situés dans la section intitulée « Contenu de Linux-Libc-Headers »
Le paquet Glibc contient la bibliothèque C principale. Cette bibliothèque fournit toutes les routines basiques pour allouer de la mémoire, rechercher des répertoires, ouvrir et fermer des fichiers, les lire et les écrire, gérer les chaînes, faire correspondre des modèles, faire de l'arithmétique et ainsi de suite.
Ce paquet est connu pour avoir des soucis quand les options
d'optimisation par défaut (en incluant les options -march
et -mcpu
) sont modifiées. Donc, si
des variables d'environnement qui surchargent les
optimisations par défaut, telles que CFLAGS
et CXXFLAGS
,
ont été définies, supprimez cette initialisation pour la
construction de Glibc.
Il devrait être noté que compiler Glibc de toute autre façon que celle proposée par le livre compromet la stabilité du système.
Glibc échoue sur deux tests lorsque le noyau en cours d'exécution est le 2.6.11.x. Le problème est dû aux tests eux-mêmes et n'a rien à voir avec la libc ou le noyau. Si vous planifiez d'exécuter la suite de tests, appliquez ce correctif :
patch -Np1 -i ../glibc-2.3.4-fix_test-1.patch
La documentation de Glibc recommande de construire Glibc en dehors du répertoire des sources, c'est-à-dire dans un répertoire dédié :
mkdir ../glibc-build cd ../glibc-build
Ensuite, préparez la compilation de Glibc :
../glibc-2.3.4/configure --prefix=/tools \ --disable-profile --enable-add-ons \ --enable-kernel=2.6.0 --with-binutils=/tools/bin \ --without-gd --with-headers=/tools/include \ --without-selinux
Voici la signification des options de configure :
--disable-profile
Ceci construit les bibliothèques sans les informations de profilage. Enlevez cette option si le profilage sur les outils temporaires est nécessaire.
--enable-add-ons
Ceci indique à Glibc d'utiliser le composant NPTL comme bibliothèque de threads.
--enable-kernel=2.6.0
Ceci indique à Glibc de compiler la bibliothèque avec le support des noyaux 2.6.x.
--with-binutils=/tools/bin
Bien que pas nécessaire, ce commutateur nous assure qu'il ne reste aucune erreur provenant des programmes Binutils lors de la construction de Glibc.
--without-gd
Ce commutateur empêche la construction du programme memusagestat, programme qui insiste pour être lié avec les bibliothèques de l'hôte (libgd, libpng, libz et ainsi de suite).
--with-headers=/tools/include
Ceci indique à Glibc de se compiler lui-même avec les en-têtes récemment installés dans le répertoire des outils, de façon à ce qu'il sache exactement de quelles fonctionnalités disposent le noyau et qu'il puisse s'optimiser correctement.
--without-selinux
Lors de la construction à partir d'hôtes qui incluent la fonctionnalité SELinux (par exemple Fedora Core 3), Glibc construira le support pour SELinux. Comme l'environnement d'outils LFS ne contient pas de support pour SELinux, une Glibc compilée avec ce support ne fonctionnera pas correctement.
Lors de cette étape, le message d'avertissement suivant peut apparaître :
configure: WARNING: *** These auxiliary programs are missing or *** incompatible versions: msgfmt *** some features will be disabled. *** Check the INSTALL file for required versions.
Le programme msgfmt, manquant ou incompatible, ne pose généralement pas de problème mais certaines personnes pensent qu'il peut poser problème lors de l'exécution de la suite de tests. Ce programme msgfmt fait partie du paquet Gettext que la distribution hôte devrait fournir. Si msgfmt est présent mais semble incompatible, mettez à jour le paquet Gettext du système hôte ou continuez sans et voyez si la suite de tests continue son exécution sans problèmes.
Compilez le paquet :
make
La compilation est maintenant terminée. Comme dit plus tôt, lancer les suites de tests pour les outils temporaires de ce chapitre n'est pas nécessaire. Pour exécuter la suite de tests Glibc, si désiré, lancer la commande suivante :
make check
Pour une discussion sur les échecs de tests qui ont une importance particulière, merci de voir la section intitulée « Glibc-2.3.4 »
Dans ce chapitre, certains tests peuvent être perturbés par des outils existants ou par des problèmes d'environnement sur le système hôte. Les échecs de la suite de tests de Glibc dans ce chapitre ne portent typiquement pas à conséquence. La bibliothèque Glibc installée dans Chapter 6 est celle qui sera utilisée à la fin, donc c'est celle qui aura besoin de passer la plupart des tests (y compris dans Chapter 6, certains échecs pourraient survenir, par exemple celui des mathématiques).
Si vous expérimentez un échec, prenez-en note puis continuez en ré-exécutant la commande make check. La suite de tests devrait reprendre là où elle a quitté précédemment. Cette séquence d'arrêt/relancement est annulée en lançant la commande make -k check. En utilisant cette option, assurez-vous de tracer la sortie pour que le journal des traces puisse être examiné plus tard pour les différents échecs.
L'étape d'installation de Glibc affichera un message
d'avertissement sans conséquence pour l'absence de
/tools/etc/ld.so.conf
.
Supprimez ce message avec :
mkdir /tools/etc touch /tools/etc/ld.so.conf
Installez le paquet :
make install
Différents pays et cultures ont des conventions variables sur la façon de communiquer. Ces conventions vont du très simple, telle que la représentation de la date et de l'heure à du très compliqué, telle que le langage parlé. L'internationalisation des programmes GNU fonctionne en utilisant les locales.
Si les suites de tests ne seront pas exécutés dans ce chapitre (suivant ainsi notre recommandation), il y a peu d'intérêts à installer les locales maintenant. Les bonnes locales seront installées dans le chapitre suivant.
Néanmoins, pour installer les locales Glibc, utilisez la commande suivante :
make localedata/install-locales
Pour gagner du temps, une alternative au lancement de la
commande précédente (qui génère et installe chaque locale que
Glibc connait) est d'installer seulement les locales voulues
et nécessaires. Ceci peut se faire en utilisant la commande
localedef. Des
informations sur cette commande sont situées dans le fichier
INSTALL
des sources de Glibc.
Néanmoins, il existe un certain nombre de locales
essentielles pour réussir les tests des futurs paquets, en
particulier les tests de libstdc++ pour GCC. Les
instructions suivantes installeront l'ensemble minimale de
locales nécessaires pour que les tests réussissent :
mkdir -p /tools/lib/locale localedef -i de_DE -f ISO-8859-1 de_DE localedef -i de_DE@euro -f ISO-8859-15 de_DE@euro localedef -i en_HK -f ISO-8859-1 en_HK localedef -i en_PH -f ISO-8859-1 en_PH localedef -i en_US -f ISO-8859-1 en_US localedef -i es_MX -f ISO-8859-1 es_MX localedef -i fa_IR -f UTF-8 fa_IR localedef -i fr_FR -f ISO-8859-1 fr_FR localedef -i fr_FR@euro -f ISO-8859-15 fr_FR@euro localedef -i it_IT -f ISO-8859-1 it_IT localedef -i ja_JP -f EUC-JP ja_JP
Les détails sur ce paquet sont situés dans la section intitulée « Contenu de Glibc »
Maintenant que les bibliothèques C temporaires ont été installées, tous les outils compilés dans le reste de ce chapitre doivent être liés avec ces bibliothèques. Pour accomplir cela, l'éditeur de liens et le fichier specs du compilateur doivent être ajustés.
L'éditeur de liens ajusté (à la fin de la première passe de
Binutils) est installé en lançant la commande suivante à partir
du répertoire binutils-build
:
make -C ld install
À partir de ce moment, tout sera lié uniquement avec les
bibliothèques comprises dans /tools/lib
.
Si l'avertissement précédent de différencier les répertoires source et de conversion de Binutils à partir de la première passe n'a pas été suivi, ignorez simplement la commande ci-dessus. Le résultat en est une petite chance de programmes de tests toujours liés avec les bibliothèques de l'hôte. Ce n'est pas idéal mais ce n'est pas un problème majeur. La situation est corrigée à l'installation de la deuxième passe de Binutils un peu plus tard.
Maintenant que l'éditeur de liens ajusté est installé, les répertoires source et de construction de Binutils doivent être supprimés.
La prochaine tâche est de modifier le fichier specs de GCC pour qu'il pointe vers le nouvel éditeur de liens. Un simple script sed devrait y parvenir :
SPECFILE=`gcc --print-file specs` && sed 's@ /lib/ld-linux.so.2@ /tools/lib/ld-linux.so.2@g' \ $SPECFILE > tempspecfile && mv -f tempspecfile $SPECFILE && unset SPECFILE
Il est recommandé que la commande ci-dessus soit copiée/collée pour assurer la précision de la commande. Autrement, le fichier specs est éditable manuellement. Ceci est fait en remplaçant chaque occurrence de « /lib/ld-linux.so.2 » par « /tools/lib/ld-linux.so.2 ».
Assurez-vous d'inspecter visuellement le fichier specs pour vérifier que la modification attendue a été réellement réalisée.
Au cas où le nom de l'éditeur de liens de la plateforme de
travail est autre que ld-linux.so.2
, remplacez ld-linux.so.2
avec le nom de l'éditeur de
liens de votre plateforme dans les commandes ci-dessus.
Référez-vous à la section
intitulée « Notes techniques sur l'ensemble
d'outils » si nécessaire.
Enfin, il existe un risque que certains fichiers include du système hôte aient trouvé leur chemin vers le répertoire include privé de GCC. Ceci peut arriver à cause du processus « fixincludes » de GCC fonctionnant en tant que partie de la construction GCC. Ceci est expliquer un peu plus tard dans ce chapitre. Lancez les commandes suivantes pour éliminer cette possibilité :
rm -f /tools/lib/gcc/*/*/include/{pthread.h,bits/sigthread.h}
Il est impératif à ce moment de s'arrêter et de s'assurer que les fonctions basiques (compilation et édition des liens) du nouvel atelier d'outils fonctionnent comme attendu. Pour réaliser une vérification de santé, lancez les commandes suivantes :
echo 'main(){}' > dummy.c cc dummy.c readelf -l a.out | grep ': /tools'
Si tout fonctionne correctement, il ne devrait pas y avoir d'erreurs et la sortie de la dernière commande sera de la forme :
[Requesting program interpreter:
/tools/lib/ld-linux.so.2]
Notez que /tools/lib
apparaît
comme préfixe du chargeur dynamique.
Si l'affichage diffère ou s'il n'y a aucun affichage, alors
quelque chose ne se passe pas bien. Investiguez et retracez
vos étapes pour trouver où se cache le problème et comment
le corriger. Ce problème doit être corrigé avant de
continuer. Tout d'abord, relancez la vérification en
utilisant gcc
au lieu de cc. Si cela fonctionne, le lien
symbolique /tools/bin/cc
est
manquant. Revisitez la section intitulée « GCC-3.4.3
- Passe 1 » et installez le lien symbolique.
Ensuite, assurez-vous que le PATH
est correct. Ceci se vérifie en lançant
echo $PATH
et en vérifiant que /tools/bin
est en tête de la liste. Si le
PATH
est mauvais, cela pourrait
signifier que vous n'êtes pas connecté en tant
qu'utilisateur lfs
ou que quelque chose s'est mal passé dans la section intitulée
« Configurer l'environnement » Une autre
possibilité est que quelque chose a pu mal se passer avec
la correction du fichier specs ci-dessus. Dans ce cas,
refaites la modification de ce fichier en vous
assurant de copier/coller les lignes comme cela était
recommandé.
Une fois satisfait, nettoyez les fichiers de test :
rm dummy.c a.out
Le paquet Tcl contient le langage de commandes des outils (Tool Command Language).
Ce paquet et les deux suivants (Expect et DejaGNU) sont installés uniquement pour supporter les suites de tests de GCC et Binutils. Installer ces trois paquets dans un but de tests pourrait sembler excessif mais c'est très rassurant, voire essentielle, de savoir que les outils les plus importants fonctionnent correctement. Même si les suites de tests ne sont pas exécutées dans ce chapitre (elles ne sont pas obligatoires), ces paquets sont nécessaires pour lancer les suites de tests du Chapter 6.
Préparez la compilation de Tcl :
cd unix ./configure --prefix=/tools
Construisez le paquet :
make
Pour tester les résultats, lancez : TZ=UTC make test
. La suite
de tests de Tcl est connue pour ses échecs sous certaines
conditions concernant l'hôte, conditions toujours pas
comprises. Du coup, des échecs de la suite de tests ne sont
pas surprenants ici et ne doivent pas être considérés comme
critiques. Le paramètre TZ=UTC
initialise le fuseau
horaire avec le temps universel coordonné (Coordinated
Universal Time soit l'UTC) connu aussi sous le
nom de Greenwich Mean Time (GMT), mais
seulement pour la durée de l'exécution de la suite de tests.
Ceci nous assure que les tests d'horloge fonctionneront
correctement. Des détails sur la variable d'environnement
TZ
sont fournis dans Chapitre 7.
Installez le paquet :
make install
Ne supprimez pas
encore le répertoire des sources tcl8.4.9
car le paquet suivant a besoin
des en-têtes.
Initialisez une variable avec le chemin complet du répertoire actuel. Le prochain paquetage, Expect, utilisera cette variable pour trouver les en-têtes de Tcl.
cd .. export TCLPATH=`pwd`
Maintenant, créez un lien symbolique nécessaire :
ln -s tclsh8.4 /tools/bin/tclsh
Le paquet Expect contient un programme pour réaliser des dialogues scriptés avec d'autres programmes interactifs.
Tout d'abord, corrigez un bogue résultant en de nombreux faux échecs lors de l'exécution de la suite de tests de GCC :
patch -Np1 -i ../expect-5.43.0-spawn-1.patch
Maintenant, préparez la compilation d'Expect :
./configure --prefix=/tools --with-tcl=/tools/lib \ --with-tclinclude=$TCLPATH --with-x=no
Voici la signification des options de configure :
--with-tcl=/tools/lib
Ceci nous assure que le script configure trouve l'installation Tcl dans l'emplacement temporaire des outils à la place d'un résidant sur le système hôte.
--with-tclinclude=$TCLPATH
Ceci indique explicitement à Expect où trouver le répertoire des sources de Tcl et ses en-têtes internes. Utiliser cette option évite certaines conditions d'échec pour configure s'il ne peut pas découvrir automatiquement l'emplacement de ce répertoire.
--with-x=no
Ceci indique au script configure de ne pas chercher Tk (le composant interface de Tcl) ou les bibliothèques d'X Window System, les deux pouvant résider sur le système hôte mais n'existant pas sur l'environnement temporaire.
Construisez le paquet :
make
Pour tester les résultats, lancez : make test
. Notez que la
suite de tests d'Expect est connue pour avoir de nombreux
échecs sous certaines conditions de l'hôte, conditions qui ne
sont pas de notre contrôle. Du coup, les échecs de la suite
de tests ne sont pas surprenantes et ne sont pas considérés
comme critiques.)
Installez-le :
make SCRIPTS="" install
Voici la signification du paramètre de make :
SCRIPTS=""
:
Ceci empêche l'installation de scripts expect
supplémentaires non nécessaires.
SCRIPTS=""
Ceci empêche l'installation de scripts expect supplémentaires non nécessaires.
Maintenant, supprimez la variable TCLPATH
:
unset TCLPATH
Les répertoires des sources de Tcl et d'Expect peuvent maintenant être supprimés.
Le paquet DejaGNU contient un ensemble de travail pour tester d'autres programmes.
Préparez la compilation de DejaGNU :
./configure --prefix=/tools
Construisez et installez le paquet :
make install
Ce paquet est connu pour avoir des soucis quand les options
d'optimisation par défaut (en incluant les options -march
et -mcpu
) sont modifiées. Donc, si
des variables d'environnement qui surchargent les
optimisations par défaut, telles que CFLAGS
et CXXFLAGS
,
ont été définies, supprimez cette initialisation pour la
construction de GCC.
Les outils requis pour tester GCC et Binutils (Tcl, Expect et
DejaGnu) sont maintenant installés. GCC et Binutils peuvent
maintenant être reconstruit en les liant avec la nouvelle
Glibc et en les testant correctement (si vous souhaitez
lancer les suites de tests dans ce chapitre). Merci de noter
que ces suites de tests dépendent énormément de pseudos
terminaux (PTY) fonctionnels fournis par votre distribution
hôte. Les PTY sont le plus souvent implémentés via le système
de fichiers devpts
. Vérifiez
si le système hôte est correctement configuré en réalisant un
simple test :
expect -c "spawn ls"
Le résultat devrait être :
The system has no more ptys.
Ask your system administrator to create more.
Si vous récupérez le message ci-dessus, la distribution hôte n'est pas correctement configurée pour les PTY. Dans ce cas, il ne sert à rien de lancer les suites de tests de GCC et Binutils jusqu'à la correction de ce problème. Merci de consulter la FAQ LFS sur http://www.linuxfromscratch.org//lfs/faq.html#no-ptys pour plus d'informations sur la façon de faire fonctionner les PTY.
Tout d'abord, corrigez un problème connu et faites un ajustement essentiel :
patch -Np1 -i ../gcc-3.4.3-no_fixincludes-1.patch patch -Np1 -i ../gcc-3.4.3-specs-2.patch
Le premier correctif désactive le script GCC fixincludes. Ceci a déjà été mentionné brièvement mais une explication plus en détail de fixincludes est apportée ici. Sous des circonstances normales, le script GCC fixincludes parcourt le système pour trouver les fichiers d'en-tête qui ont besoin d'être corrigé. Il pourrait trouver que certains des fichiers d'en-têtes de Glibc sur lee système devraient être corrigés, les corriger et les placer dans le répertoire des en-têtes privés de GCC. Dans le Chapter 6, après avoir installé la nouvelle Glibc, ce répertoire serait recherché avant le répertoire include du système, faisant que GCC trouverait les en-têtes corrigés du système hôte qui ne correspondront certainement pas à la version de Glibc actuellement utilisée pour le système LFS.
Le deuxième correctif modifie l'emplacement par défaut de
l'éditeur de liens dynamiques de GCC (généralement
ld-linux.so.2
). Il supprime
aussi /usr/include
du chemin de
recherche des includes de GCC. Corriger maintenant plutôt
qu'ajuster le fichier specs après l'installation nous assure
que l'éditeur de liens dynamiques sera utilisé lors de la
construction de GCC. C'est-à-dire, tous les binaires finaux
(et temporaires) créés lors de la construction seront liés à
la nouvelle Glibc.
Les correctifs ci-dessus sont critiques pour s'assurer une construction avec succès. N'oubliez pas de les appliquer.
De nouveau, créez un répertoire de construction séparé :
mkdir ../gcc-build cd ../gcc-build
Avant de commencer la construction de GCC, rappelez-vous de désinitialiser toute variable d'environnement surchargeant les options d'optimisation par défaut.
Maintenant, préparez la compilation de GCC :
../gcc-3.4.3/configure --prefix=/tools \ --libexecdir=/tools/lib --with-local-prefix=/tools \ --enable-clocale=gnu --enable-shared \ --enable-threads=posix --enable-__cxa_atexit \ --enable-languages=c,c++ --disable-libstdcxx-pch
Voici la signification des nouvelles options de configure :
--enable-clocale=gnu
Cette option nous assure que le bon modèle de locale est sélectionné pour les bibliothèques C++ sous toutes les circonstances. Si le script configure trouve la locale de_DE installée, il sélectionnera le bon modèle de locale gnu. Néanmoins, si la locale de_DE n'est pas installée, il existe un risque de construire des bibliothèques C++ incompatibles avec ABI à cause du choix d'un mauvais modèle générique de locale.
--enable-threads=posix
Ceci active la gestion des exceptions C++ pour le code multi-threadé.
--enable-__cxa_atexit
Cette option autorise l'utilisation de __cxa_atexit, plutôt que atexit, pour enregistrer les destructeurs C++ des objets statiques locaux et globaux. Cette option est essentielle pour la gestion des destructeurs en compatibilité complète avec les standards. Il affecte aussi l'ABI C++ et donc résulte en des bibliothèques partagées et des programmes C++ interopérables avec les autres distributions Linux.
--enable-languages=c,c++
Cette option est nécessaire pour s'assurer que les compilateurs C et C++ seront construits.
--disable-libstdcxx-pch
Ce commutateur empêche la construction de l'en-tête
précompilé (PCH) de libstdc++
. Il prend beaucoup d'espace
et nous n'en avons aucune utilité.
Compilez le paquet :
make
Il n'est pas nécessaire d'utiliser la cible bootstrap
maintenant car le
compilateur utilisé pour compiler ce GCC a été construit avec
exactement la même version des sources de GCC utilisées
précédemment.
La compilation est maintenant terminée. Comme mentionné plus tôt, lancer les suites de test pour les outils temporaires de ce chapitre n'est pas nécessaire. Néanmoins, pour exécuter la suite de tests de GCC, lancez la commande suivante :
make -k check
L'option -k
est
utilisée pour faire en sorte que toute la suite de tests est
exécutée et qu'elle ne s'arrête pas au premier échec. La
suite de tests GCC est très complète et il est pratiquement
garantie que certaines erreurs apparaîtront. Pour obtenir un
résumé des résultats de la suite de tests, lancez ceci :
../gcc-3.4.3/contrib/test_summary
Pour un simple résumé, envoyez la sortie sur un tube suivi de
grep -A7
Summ
.
Les résultats peuvent être comparés à ceux postés sur http://www.linuxfromscratch.org/lfs/build-logs/6.1/.
Quelques échecs inattendus ne peuvent souvent pas être évités. Les développeurs GCC sont généralement au courant mais ne les ont pas encore résolus. À moins que vos tests soient grandement différents de ceux de l'URL ci-dessus, vous pouvez continuer sans crainte.
Installez le paquet :
make install
À ce moment, il est fortement recommandé de répéter la vérification que nous avions réalisé dans ce chapitre. Référez-vous à la section intitulée « Ajuster l'atelier des outils » et répétez le test de compilation. Si les résultats sont mauvais, alors la raison probable en est l'oubli de l'application du correctif "GCC Specs" mentionné ci-dessus.
Les détails sur ce paquet sont situés dans la section intitulée « Contenu de GCC »
Le paquet Binutils contient un éditeur de liens, un assembleur et d'autres outils pour gérer des fichiers objets.
Ce paquet est connu pour avoir des soucis quand les options
d'optimisation par défaut (en incluant les options -march
et -mcpu
) sont modifiées. Donc, si
des variables d'environnement qui surchargent les
optimisations par défaut, telles que CFLAGS
et CXXFLAGS
,
ont été définies, supprimez cette initialisation pour la
construction de Binutils.
Créez de nouveau un répertoire de construction séparé :
mkdir ../binutils-build cd ../binutils-build
Préparez la compilation de Binutils :
../binutils-2.15.94.0.2.2/configure --prefix=/tools \ --disable-nls --enable-shared --with-lib-path=/tools/lib
Voici la signification des nouvelles options de configure :
--with-lib-path=/tools/lib
Ceci indique au script configure de spécifier le chemin
de recherche des bibliothèques lors de la compilation
de Binutils, résultant au passage de /tools/lib
à l'éditeur de liens. Ceci
empêche l'éditeur de liens de chercher dans tous les
répertoires de bibliothèques de l'hôte.
Compilez le paquet :
make
La compilation est maintenant terminée. Comme dit plutôt, lancer les suites de tests n'est pas nécessaire pour les outils temporaires dans ce chapitre. Néanmoins, pour lancer la suite de tests Binutils, lancez la commande suivante :
make check
Installez le paquet :
make install
Maintenant, préparez l'éditeur de liens pour la phase de « ré-ajustement » du prochain chapitre :
make -C ld clean make -C ld LIB_PATH=/usr/lib:/lib
Ne supprimez pas encore les répertoires des sources et de construction de Binutils. Ces répertoires seront nécessaires pour le prochain chapitre dans l'état où ils sont actuellement.
Les détails sur ce paquet sont disponibles dans la section intitulée « Contenu de Binutils »
Le paquet Gawk contient des programmes de manipulation de fichiers texte.
Préparez la compilation de Gawk :
./configure --prefix=/tools
Compilez le paquet :
make
Pour tester les résultats, lancez : make check
.
Installez le paquet :
make install
Les détails sur ce paquet sont situés dans la section intitulée « Contenu de Gawk »
Le paquet Coreutils contient des outils pour afficher et configurer les caractéristiques basiques d'un système.
Préparez la compilation de Coreutils :
DEFAULT_POSIX2_VERSION=199209 ./configure --prefix=/tools
Ce paquet a un problème lorsqu'il est compilé avec des
versions de Glibc plus anciennes que la 2.3.2. Certains
outils de Coreutils (tels que head, tail et sort) rejetteront leur syntaxe
traditionnelle, une syntaxe utilisée depuis environ
30 ans. Cette ancienne syntaxe est si ancrée que la
compatibilité doit être préservée jusqu'à ce que les endroits
où elle est utilisée pourront être mis à jour. La
compatibilité descendante est obtenue en initialisant la
variable d'environnement DEFAULT_POSIX2_VERSION
à « 199209 » dans la commande ci-dessus. Si
vous ne voulez pas que Coreutils soit compatible avec la
syntaxe traditionnelle, oubliez simplement d'initialiser la
variable d'environnement DEFAULT_POSIX2_VERSION
. Il est important de se
rappeller que faire ceci aura des conséquences, dont la
correction des nombreux paquets utilisant toujours l'ancienne
syntaxe. Il est donc fortement recommander de suivre
exactement les instructions comme indiquées ci-dessus.
Compilez le paquet :
make
Pour tester les résultats, lancez : make RUN_EXPENSIVE_TESTS=yes
check
. Le paramètre RUN_EXPENSIVE_TESTS=yes
RUN_EXPENSIVE_
TESTS=yes
indique à la suite de tests de lancer
quelques tests supplémentaires, considérés relativement
coûteux (en terme de puissance CPU et d'utilisation mémoire)
mais habituellement sans problème sous Linux.
Installez le paquet :
make install
Les détails sur ce paquet sont disponibles dans la section intitulée « Contenu de Coreutils ».
Le paquet Bzip2 contient des programmes de compression et décompression de fichiers. Compresser des fichiers texte avec bzip2 permettent d'atteindre un taux de compression bien meilleur qu'avec l'outil gzip traditionnel.
Le paquet Bzip2 ne contient pas de script configure. Compilez-le avec :
make
Pour tester les résultats, exécutez : make test
.
Installez le paquet :
make PREFIX=/tools install
Les détails sur ce paquet sont situés dans la section intitulée « Contenu de Bzip2 »
Le paquet Gzip contient des programmes de compression et décompression de fichiers.
Préparez la compilation de Gzip :
./configure --prefix=/tools
Compilez le paquet :
make
Ce paquet ne dispose pas de suite de tests.
Installez le paquet :
make install
Les détails sur ce paquet sont situés dans la section intitulée « Contenu de Gzip »
Le paquet Diffutils contient les programmes montrant les différences entre fichiers ou répertoires.
Préparez la compilation de Diffutils :
./configure --prefix=/tools
Compilez le paquet :
make
Ce paquet ne contient pas de suite de tests.
Installez le paquet :
make install
Les détails sur ce paquet sont situés dans la section intitulée « Contenu de Diffutils »
Le paquet Findutils contient des programmes de recherche de fichiers. Ces programmes sont fournis pour rechercher récursivement dans une hiérarchie de répertoires et pour créer, maintenir et chercher dans une base de données (souvent plus rapide que la recherche récursive mais moins fiable si la base de données n'a pas été mise à jour récemment).
Préparez la compilation de Findutils :
./configure --prefix=/tools
Compilez le paquet :
make
Pour tester les résultats, lancez : make check
.
Installez le paquet :
make install
Les détails sur ce paquet sont situés dans la section intitulée « Contenu de Findutils »
Le paquet Make contient un programme pour compiler des paquetages.
Préparez la compilation de Make :
./configure --prefix=/tools
Compilez le paquet :
make
Pour tester les résultats, lancez : make check
.
Installez le paquet :
make install
Les détails de ce paquet sont situés dans la section intitulée « Contenu de Make »
Le paquet Grep contient des programmes de recherche à l'intérieur de fichiers.
Préparez la compilation de Grep :
./configure --prefix=/tools \ --disable-perl-regexp
Voici la signification des options de configure :
--disable-perl-regexp
Ceci nous assure que grep ne sera pas lié à une bibliothèque PCRE qui pourrait être présente sur l'hôte et qui ne serait pas disponible une fois que nous serons entrés dans l'environnement chroot.
Compilez les programmes :
make
Pour tester les résultats, lancez : make check
.
Installez le paquet :
make install
Les détails sur ce paquet sont disponibles dans la section intitulée « Contenu de Grep ».
Le paquet Sed contient un éditeur de flux.
Préparez la compilation de Sed :
./configure --prefix=/tools
Compilez le paquet :
make
Pour tester les résultats, lancez : make check
.
Installez le paquet :
make install
Les détails de ce paquet sont situés dans la section intitulée « Contenu de Sed »
Le paquet Gettext contient des outils pour l'internationalisation et la localisation. Ceci permet aux programmes d'être compilés avec le support des langages natifs (Native Language Support ou NLS), leur permettant d'afficher des messages dans la langue native de l'utilisateur.
Préparez la compilation de Gettext :
./configure --prefix=/tools --disable-libasprintf \ --without-csharp
Voici la signification des options de configure :
--disable-libasprintf
Ce commutateur indique à Gettext de ne pas construire
la bibliothèque asprintf
.
Parce que rien dans ce chapitre ou le suivant ne
requiert cette bibliothèque et que Gettext est
reconstruit plus tard, l'exclure sauve du temps et de
l'espace.
--without-csharp
Ceci nous assure que Gettext ne contruira pas le support du compilateur C# qui pourrait être présent sur l'hôte mais qui ne sera pas disponible une fois que nous serons entrés dans l'environnement du chroot.
Compilez le paquet :
make
Pour tester les résultats, lancez : make check
. Ceci peut
prendre beaucoup de temps, environ 7 SBU. La suite de
tests Gettext est connue pour avoir des échecs sous certaines
conditions liées à l'hôte, par exemple lorsqu'il trouve un
compilateur Java sur l'hôte. Un correctif expérimental
désactivant Java est disponible à partir du projet des
correctifs LFS sur http://www.linuxfromscratch.org/patches/.
Installez le paquet :
make install
Les détails sur ce paquet sont situés dans la section intitulée « Contenu de Gettext »
Le paquet Ncurses contient les bibliothèques de gestion des écrans type caractère, indépendant des terminaux.
Préparez la compilation de Ncurses :
./configure --prefix=/tools --with-shared \ --without-debug --without-ada --enable-overwrite
Voici la signification des options de configure :
--without-ada
Ceci nous assure que Ncurses ne construira pas le support du compilateur Ada qui pourrait être présent sur l'hôte mais qui ne sera pas disponible lorsque nous entrerons dans l'environnement chroot.
--enable-overwrite
Ceci indique à Ncurses d'installer les fichiers
d'en-tête dans /tools/include
au lieu de
/tools/include/ncurses
pour s'assurer que les autres paquets trouveront bien
les en-têtes de Ncurses.
Compilez le paquet :
make
Ce paquet ne fournit pas de suite de tests.
Installez le paquet :
make install
Les détails sur ce paquet sont disponibles dans la section intitulée « Contenu de Ncurses »
Le paquet Patch contient un programme permettant de modifier et de créer des fichiers en appliquant un fichier correctif (appelé généralement « patch ») créé généralement par le programme diff.
Préparez la compilation de Patch :
CPPFLAGS=-D_GNU_SOURCE ./configure --prefix=/tools
Le commutateur du préprocesseur -D_GNU_SOURCE
n'est nécessaire
que sur la plateforme PowerPC. Il peut être oublié pour les
autres.
Compilez le paquet :
make
Ce paquet ne fournit pas de suite de tests.
Installez le paquet :
make install
Les détails sur ce paquet sont situés dans la section intitulée « Contenu de Patch »
Le paquet Tar contient un programme d'archivage.
Préparez la compilation de Tar :
./configure --prefix=/tools
Compilez le paquet :
make
Pour tester les résultats, lancez : make check
.
Installez le paquet :
make install
Les détails sur ce paquet sont situés dans la section intitulée « Contenu de Tar »
Le paquet Texinfo contient des programmes de lecture, écriture et de conversion des pages Info.
Préparez la compilation de Texinfo :
./configure --prefix=/tools
Compilez le paquet :
make
Pour tester les résultats, lancez : make check
.
Installez le paquet :
make install
Les détails de ce paquet sont situés dans la section intitulée « Contenu de Texinfo »
Le paquet Bash contient le shell Bourne-Again.
Bash a un problème lorsqu'il est compilé avec les nouvelles versions de Glibc, le faisant s'arrêter brutalement. Cette commande corrige ce problème :
patch -Np1 -i ../bash-3.0-avoid_WCONTINUED-1.patch
Préparez la compilation de Bash :
./configure --prefix=/tools --without-bash-malloc
Voici la signification des options de configure :
--without-bash-malloc
Cette option désactive l'utilisation par Bash de la fonction d'allocation mémoire (malloc) qui est connue pour causer des erreurs de segmentation. En désactivant cette option, Bash utilisera les fonctions malloc de Glibc qui sont plus stables.
Compilez le paquet :
make
Pour tester les résultats, lancez : make tests
.
Installez le paquet :
make install
Créez un lien pour les programmes qui utilisent sh comme shell :
ln -s bash /tools/bin/sh
Les détails sur ce paquet sont situés dans la section intitulée « Contenu de Bash »
Le paquet M4 contient un processeur de macros.
Prepare M4 for compilation:
./configure --prefix=/tools
Compile the package:
make
To test the results, issue: make check
.
Install the package:
make install
Details on this package are located in la section intitulée « Contenu de M4 »
Le paquet Bison contient un générateur d'analyseurs.
Préparez la compilation de Bison :
./configure --prefix=/tools
Compilez le paquet :
make
Pour tester les résultats, lancez : make check
.
Installez le paquet :
make install
Les détails sur ce paquet sont situés dans la section intitulée « Contenu de Bison »
Le paquet Flex contient un outil de génération de programmes reconnaissant des modèles de texte.
Flex contient quelques bogues connus. Ils sont corrigés avec le correctif suivant :
patch -Np1 -i ../flex-2.5.31-debian_fixes-3.patch
GNU autotools détectera que le code source de Flex a été modifé par le correctif précédent et tente de mettre à jour la page man en accord. Ceci ne fonctionne pas sur certains systèmes et la page par défaut est suffisante, donc assurez-vous qu'elle n'est pas regénérée :
touch doc/flex.1
Maintenant, préparez la compilation de Flex :
./configure --prefix=/tools
Compilez le paquet :
make
Pour tester les résultats, lancez : make check
.
Installez le paquet :
make install
Les détails sur ce paquet sont situés dans la section intitulée « Contenu de Flex »
The Util-linux package contains miscellaneous utility programs. Among them are utilities for handling file systems, consoles, partitions, and messages.
Util-linux n'utilise pas les en-têtes et bibliothèques tout
juste installés dans le répertoire /tools
par défaut. Ceci est corrigé en
modifiant le script configure :
sed -i 's@/usr/include@/tools/include@g' configure
Préparez la compilation de Util-linux :
./configure
Compilez quelques routines d'aide :
make -C lib
Seuls quelques utilitaires contenus dans ce paquet sont nécessaires :
make -C mount mount umount make -C text-utils more
Ce paquet ne fournit pas de suite de tests.
Copiez ces programmes dans le répertoire des outils temporaires: :
cp mount/{,u}mount text-utils/more /tools/bin
Les détails sur ce paquet sont disponibles dans la section intitulée « Contenu d'Util-linux »
Le paquet Perl contient le langage pratique d'extraction et de rapport (Practical Extraction and Report Language).
Tout d'abord, adaptez quelques chemins codés en dur vers la bibliothèque C en appliquant le correctif suivant :
patch -Np1 -i ../perl-5.8.6-libc-1.patch
Préparez la compilation de Perl (assurez-vous que la partie de la commande marquée « IO Fcntl POSIX » est saisie correctement, ce ne sont que des lettres) :
./configure.gnu --prefix=/tools -Dstatic_ext='IO Fcntl POSIX'
Voici la signification de l'option de configure :
-Dstatic_ext='IO Fcntl
POSIX'
: ceci indique à Perl de
construire l'ensemble minimal d'extensions statiques
nécessaires à l'installation et au test du paquet
Coreutils dans le prochain chapitre.
-Dstatic_ext='IO Fcntl
POSIX'
Ceci indique à Perl de construire l'ensemble minimal d'extensions statiques nécessaires à l'installation et au test du paquet Coreutils dans le prochain chapitre.
Seulement une partie des outils de ce paquetage doit être construit :
make perl utilities
Bien que Perl est fourni avec une suite de tests, il n'est
pas recommandé de l'exécuter maintenant. Seules des parties
de Perl ont été construites et l'exécution de make test
obligerait la
construction du reste de Perl, ce qui n'est pas nécessaire
actuellement. La suite de tests peut être exécuté dans le
chapitre suivant si désiré.
Puis, installez ces outils et leurs bibliothèques :
cp perl pod/pod2man /tools/bin mkdir -p /tools/lib/perl5/5.8.6 cp -R lib/* /tools/lib/perl5/5.8.6
Les détails sur ce paquet sont disponibles dans la section intitulée « Contenu de Perl »
Les étapes de cette section sont optionnelles mais si le partition LFS est plutôt petite, il est bénéfique d'appendre que des éléments inutiles sont supprimables. Les exécutables et les bibliothèques que vous avez construit jusqu'à maintenant contiennent jusqu'à 130 Mo de symboles de déboguages inutiles. Supprimez ces symboles avec :
strip --strip-debug /tools/lib/* strip --strip-unneeded /tools/{,s}bin/*
La dernière des commandes ci-dessus laissera de côté une vingtaine de fichiers en indiquant qu'elle ne reconnait pas leur format. La plupart sont des scripts et non pas des binaires.
Faites attention à ne pas utiliser --strip-unneeded
sur les
bibliothèques. Cela détruirait les statiques et les paquets
devraient être de nouveau construits.
Pour sauver encore 30 Mo, supprimez toute la documentation :
rm -rf /tools/{info,man}
Il y aura maintenant au moins 850 Mo d'espace disque libre sur le système de fichiers LFS à utiliser pour construire et installer Glibc dans la prochaine phase. Si vous pouvez construire et installer Glibc, vous pourrez aussi construire et installer le reste.
Dans ce chapitre, nous entrons dans le site de construction et lançons la construction du système LFS. C'est-à-dire, nous entrons avec chroot dans le mini système Linux temporaire, faisons quelques préparations finales et lançons l'installation de tous les paquets un par un.
L'installation du logiciel est simple. Bien que, dans beaucoup de cas, les instructions d'installation pourraient être plus courtes et plus génériques, nous avons opté pour fournir les instructions complètes pour chaque paquet et minimiser ainsi les possibilités d'erreurs. La clé pour apprendre ce qui fait fonctionner un système Linux est de savoir à quoi sert chaque paquet et pourquoi l'utilisateur (ou le système) en a besoin. Pour chaque paquet installé, un résumé de son contenu est donné, suivant par des descriptions concises de chaque programme et de chaque bibliothèque que le paquet a installé.
En utilisant les optimisations du compilateur fournies dans ce chapitre, merci de lire l'astuce sur l'optimisation sur http://www.linuxfromscratch.org/hints/downloads/files/optimization.txt. Les optimisations du compilateur peuvent faire qu'un programme s'exécute plus rapidement mais elles peuvent aussi caiser des difficultés et des problèmes de compilation à l'exécution de ce programme. Si un paquet refuse de compiler lors de l'utilisation d'optimisation, essayez de le compiler sans optimisation pour voir si cela corrige le problème. Même si le paquet compile avec les optimisations, il y a un risque qu'il pourrait avoir été mal compilé à cause des interactions complexes entre le code et les outils de construction. Le petit potentiel de gains réussi en utilisant les optimisations de compilation est souvent ridicule comparé aux risques. Les utilisateurs construisant une LFS pour la première fois sont encouragés à construire sans optimisations personnalisées. Le système sera toujours très rapide et restera stable en même temps.
L'ordre dans lequel les paquets sont installés dans ce chapitre
a besoin d'être strictement suivi pour s'assurer qu'aucun
programme n'acquiert accidentellement un chemin ayant comme
référence /tools
en dur. Pour la
même raison, ne compilez pas les paquets en parallèle. La
compilation en parallèle permet de gagner du temps (tout
particulièrement sur les machines à plusieurs CPU), mais cela
pourrait résulter en un programme contenant un chemin codé en
dur vers /tools
, ce qui empêchera
le programme de fonctionner si ce répertoire est supprimé.
Avant les instructions d'installation, chaque page d'installation fournit des informations sur le paquet, incluant une description concise de ce qu'il contient, approximativement combien de temps prendra la construction et les autres paquets nécessaires lors de cette étape de construction. Suivant les instructions d'installation, il existe une liste de programmes et de bibliothèques (avec quelques brèves descriptions de ceux-ci) que le paquet installe.
Pour garder trace du paquet qui installe certains fichiers spécifiques, un gestionnaire de paquet peut être utilisé. Pour un aperçu général des différents styles de gestionnaires de paquets, merci de vous référer à http://www.linuxfromscratch.org/blfs/view/svn/introduction/important.htmlhttp://www.linuxfromscratch.org/blfs/view/svn/ introduction/important.html. Pour une méthode de gestion des paquets spécifiquement tournée vers LFS, nous recommandons http://www.linuxfromscratch.org/hints/downloads/files/more_control_and_pkg_man.txt.
Le reste de ce libre est à réaliser en étant connecté en
tant qu'utilisateur root et non plus en tant
qu'utilisateur lfs.
De plus, vérifiez de nouveau que la variable $LFS
est bien configurée.
Différents systèmes de fichiers exportés par le noyau sont utilisés pour communiquer avec le noyau. Ces systèmes de fichiers sont virtuels par le fait qu'aucun espace disque n'est utilisé pour eux. Le contenu de ces systèmes de fichiers réside en mémoire.
Commencez en créant les répertoires dans lesquels les systèmes de fichiers seront montés :
mkdir -p $LFS/{proc,sys}
Maintenant, montez les systèmes de fichiers :
mount -t proc proc $LFS/proc mount -t sysfs sysfs $LFS/sys
Rappellez-vous que si vous stoppez le système LFS et que vous le relancez, il est important de vérifier que ces systèmes de fichiers sont montés avant d'entrer dans l'environnement chroot.
Des systèmes de fichiers supplémentaires seront bientôt montés à l'intérieur de l'environnement chroot. Pour garder l'hôte à jour, réalisez un « faux montage » pour chacun d'entre eux maintenant :
mount -f -t tmpfs tmpfs $LFS/dev mount -f -t tmpfs tmpfs $LFS/dev/shm mount -f -t devpts -o gid=4,mode=620 devpts $LFS/dev/pts
Il est temps d'entrer dans l'environnement chroot pour commencer la construction et l'installation du système final LFS. En tant que root, lancez la commande suivante pour entrer dans ce petit monde peuplé seulement, pour le moment, des outils temporaires :
chroot "$LFS" /tools/bin/env -i \ HOME=/root TERM="$TERM" PS1='\u:\w\$ ' \ PATH=/bin:/usr/bin:/sbin:/usr/sbin:/tools/bin \ /tools/bin/bash --login +h
L'option -i
donnée à la
commande env
effacera toutes les variables de l'environnement chroot. Après
cela, seules les variables HOME
,
TERM
, PS1
et PATH
sont toujours initialisées.
La construction TERM=$TERM
initialisera la
variable TERM
à l'intérieur du
chroot avec la même valeur qu'à l'extérieur ; cette
variable est nécessaire pour que les programmes comme
vim et
less fonctionnent
correctement. Si vous avez besoin de la présence d'autres
variables, telles que CFLAGS
ou
CXXFLAGS
, c'est le bon moment pour
les initialiser de nouveau.
À partir de maintenant, il n'est plus nécessaire d'utiliser la
variable LFS
parce que tout le
travail sera restreint au système de fichiers LFS car le shell
pense que $LFS
est maintenant la
racine (/
.
Notez que /tools/bin
arrive
dernier dans le PATH
. Ceci signifie
qu'un outil temporaire ne sera plus utilisé une fois que la
version finale sera utilisée. Ceci survient quand le shell ne
se rappelle plus les emplacements des binaires exécutés. Pour
cette raison, le hachage est désactivé en passant l'option
+h à
bash.
Il est important que toutes les commandes pour le reste de ce
chapitre et les chapitres suivants sont lancés à l'intérieur de
l'environnement chroot. Si vous devez quitter cet environnement
quelqu'en soit la raison (un redémarrage par exemple), vous
devez vous rappeller de commencer par monter les systèmes de
fichiers proc
et devpts
(discutés dans la section
précédente) et d'entrer de nouveau dans chroot avant de
continuer les installations.
Notez que l'invite de bash dira « I have no name! » (Je n'ai pas de
nom !). C'est normal car le fichier /etc/passwd
n'existe pas encore.
Actuellement, le répertoire /tools
appartient à l'utilisateur
lfs. Néanmoins, ce
compte utilisateur existe seulement sur votre système hôte.
Bien que le répertoire /tools
peut être supprimé une fois le système LFS terminé, il peut
être conservé pour construire d'autres systèmes LFS. Si ce
répertoire est conservé tel qu'il est, les fichiers
appartiennent à un identifiant sans compte correspondant. Ceci
est dangereux car par la suite un compte utilisateur pourrait
obtenir cet identifiant et devenir soudainement le propriétaire
du répertoire /tools
et les
fichiers qu'il contient, les exposant à une manipulation
détournée possible.
Pour éviter ce problème, ajoutez l'utilisateur lfs dans votre nouveau système LFS
en créant plus tard le fichier /etc/passwd
, et en prenant garde d'affecter
le bon identifiant utilisateur et groupe. Sinon, affectez le
contenu du répertoire /tools
à
l'utilisateur root en
lançant la commande suivante :
chown -R 0:0 /tools
La commande utilise 0:0
au lieu de root:root
car chown n'est
pas capable de résoudre le nom « root » tant que le fichier des mots de
passe n'est pas créé. Ce livre suppose que vous avez exécuté la
commande chown.
Il est temps de créer la hiérarchie de répertoires sur le système de fichiers LFS. Créez une hiérarchie de répertoires standard en lançant les commandes suivantes :
install -d /{bin,boot,dev,etc/opt,home,lib,mnt} install -d /{sbin,srv,usr/local,var,opt} install -d /root -m 0750 install -d /tmp /var/tmp -m 1777 install -d /media/{floppy,cdrom} install -d /usr/{bin,include,lib,sbin,share,src} ln -s share/{man,doc,info} /usr install -d /usr/share/{doc,info,locale,man} install -d /usr/share/{misc,terminfo,zoneinfo} install -d /usr/share/man/man{1,2,3,4,5,6,7,8} install -d /usr/local/{bin,etc,include,lib,sbin,share,src} ln -s share/{man,doc,info} /usr/local install -d /usr/local/share/{doc,info,locale,man} install -d /usr/local/share/{misc,terminfo,zoneinfo} install -d /usr/local/share/man/man{1,2,3,4,5,6,7,8} install -d /var/{lock,log,mail,run,spool} install -d /var/{opt,cache,lib/{misc,locate},local} install -d /opt/{bin,doc,include,info} install -d /opt/{lib,man/man{1,2,3,4,5,6,7,8}}
Par défaut, les répertoires sont créés avec les droits 755, ce qui n'est pas souhaitable pour tous les répertoires. Dans la commande ci-dessus, deux modifications seront effectuées : un pour le répertoire principal de root et un autre pour les répertoires des fichiers temporaires.
Le premier changement de droit nous assure que n'importe qui ne
pourra pas entrer dans le répertoire /root
(de façon identique à ce que ferait un
utilisateur pour son répertoire principal). Le deuxième
changement assure que tout utilisateur peut écrire dans les
répertoires /tmp
et /var/tmp
, mais ne peut pas supprimer les
fichiers des autres utilisateurs. Cette dernière interdiction
est dûe au « sticky bit »,
le bit le plus haut dans le masque 1777.
L'arborescence de répertoires est basée sur le standard FHS
(disponible sur http://www.pathname.com/fhs/).
En plus de cette arborescence, ce standard stipule
l'existence de /usr/local/games
et /usr/share/games
. Le FHS
n'est pas précis en ce qui concerne la structure du
sous-répertoire /usr/local/share
, donc nous créons
seulement les répertoires nécessaires. Néanmoins, n'hésitez
pas à créer ces répertoires si vous préférez vous conformer
plus strictement au FHS.
Certains programmes stockent en dur des chemins vers des programmes qui n'existent pas encore. Pour satisfaire ces programmes, créez un certain nombre de liens symboliques qui seront remplacés par les vrais fichiers tout au long de ce chapitre une fois que tous les logiciels seront installés.
ln -s /tools/bin/{bash,cat,pwd,stty} /bin ln -s /tools/bin/perl /usr/bin ln -s /tools/lib/libgcc_s.so{,.1} /usr/lib ln -s bash /bin/sh
Pour que root puisse se
connecter et que le nom « root » soit reconnu, il doit exister des
entrées adéquates dans les fichiers /etc/passwd
et /etc/group
.
Créez le fichier /etc/passwd
en
lançant les commandes suivantes :
cat > /etc/passwd << "EOF" root:x:0:0:root:/root:/bin/bash EOF
Le mot de passe pour root (le caractère « x » ici est seulement pour conserver l'emplacement) sera initialisé plus tard.
Créez le fichier /etc/group
en
lançant la commande suivante :
cat > /etc/group << "EOF" root:x:0: bin:x:1: sys:x:2: kmem:x:3: tty:x:4: tape:x:5: daemon:x:6: floppy:x:7: disk:x:8: lp:x:9: dialout:x:10: audio:x:11: video:x:12: utmp:x:13: usb:x:14: EOF
Les groupes créés ne font pas partie d'un standard—ils ont été choisis en partie suite aux pré-requis de la configuration d'Udev dans la section suivante et en partie par une convention commune employée par un certain nombre de distributions Linux existantes. LSB (Linux Standard Base, disponible sur http://www.linuxbase.org) recommande seulement que, en plus du groupe « root » disposant d'un GID 0, un groupe « bin » de GID 1 soit présent. Tous les autres noms de groupe et GID associés sont choisis librement par l'administrateur du système car les programmes bien écrits ne dépendent pas des numéros de GID mais utilisent plutôt le nom du groupe.
Pour supprimer l'invite « I have no
name! », commencez un nouveau shell. Comme un Glibc
complet a été installé dans le Chapitre 5 et que les fichiers
/etc/passwd
et /etc/group
ont été créés, la résolution des
noms d'utilisateur et des noms de groupe devraient fonctionner.
exec /tools/bin/bash --login +h
Notez l'utilisation de la directive +h
. Ceci indique à
bash de ne pas
utiliser son hachage interne des chemins. Sans cette directive,
bash se
rappellerait le chemin vers les binaires qu'il a exécuté. Pour
utiliser les binaires dès leur installation, l'option
+h
sera utilisée pour
toute la durée de ce chapitre.
Les programmes login, agetty et init (ainsi que d'autres) utilisent un certain nombre de journaux pour enregistrer les informations comme la personne connectée au système et sa date d'entrée. Néanmoins, ces programmes n'écrivent pas les journaux de trace s'ils n'existent pas déjà. Initialisez les journaux et donnez-leur les bons droits :
touch /var/run/utmp /var/log/{btmp,lastlog,wtmp} chgrp utmp /var/run/utmp /var/log/lastlog chmod 664 /var/run/utmp /var/log/lastlog
Le fichier /var/run/utmp
enregistre les utilisateurs actuellement connectés. Le fichier
/var/log/wtmp
enregistre toutes
les connexions et déconnexions. Le fichier /var/log/lastlog
enregistre pour chaque
utilisateur quand il ou elle s'est déjà connecté. Le fichier
/var/log/btmp
enregistre les
tentatives échouées de connexion.
Lorsque le noyau démarre le système, il requiert la présence
de quelques nœuds périphériques, en particulier les
périphériques console
et
null
. Créez-les en lançant les
commandes suivantes :
mknod -m 600 /dev/console c 5 1 mknod -m 666 /dev/null c 1 3
La méthode recommandée pour peupler le répertoire
/dev
de périphériques est de
monter un système de fichiers virtuel (comme tmpfs
) sur le répertoire /dev
, et d'autoriser la création dynamique
des périphériques sur le système de fichiers virtuels une
fois qu'ils sont détectés ou que quelque chose tente d'y
accéder. Ceci est fait généralement lors du démarrage. Comme
ce nouveau système n'a pas encore été démarré, il est
nécessaire de faire ce que le paquetage LFS-Bootscripts
aurait fait en montant /dev
:
mount -n -t tmpfs none /dev
Le paquetage Udev est celui qui va créé les périphériques
dans le répertoire /dev
. Comme
il ne sera installé que plus tard lors de ce processus, créez
manuellement l'ensemble minimum de nœuds de
périphériques nécessaire pour terminer la construction de ce
système :
mknod -m 622 /dev/console c 5 1 mknod -m 666 /dev/null c 1 3 mknod -m 666 /dev/zero c 1 5 mknod -m 666 /dev/ptmx c 5 2 mknod -m 666 /dev/tty c 5 0 mknod -m 444 /dev/random c 1 8 mknod -m 444 /dev/urandom c 1 9 chown root:tty /dev/{console,ptmx,tty}
Certains liens symboliques er répertoires sont requis par LFS qui les crée lors du démarrage du système grâce au paquetage LFS-Bootscripts. Comme il s'agit d'un environnement chroot et que nous n'avons pas démarré avec lui, ces liens symboliques et répertoires doivent être créés ici :
ln -s /proc/self/fd /dev/fd ln -s /proc/self/fd/0 /dev/stdin ln -s /proc/self/fd/1 /dev/stdout ln -s /proc/self/fd/2 /dev/stderr ln -s /proc/kcore /dev/core mkdir /dev/pts mkdir /dev/shm
Enfin, montez les bons systèmes de fichiers virtuels (noyau) sur les répertoires nouvellement créés:
mount -t devpts -o gid=4,mode=620 none /dev/pts mount -t tmpfs none /dev/shm
Les commandes mount exécutées ci-dessus pourraient causer les messages d'avertissement suivants :
can't open /etc/fstab: No such file or directory.
Ce fichier—/etc/fstab
—n'a pas été encore créé
mais il n'est pas non plus requis pour le bon montage des
systèmes de fichiers. De cette façon, le message peut être
ignoré sans crainte.
Le paquet Linux-Libc-Headers contient les en-têtes du noyau « nettoyés ».
Pendant des années, une pratique courante était d'utiliser
les en-têtes « bruts »
du noyau (provenant directement de l'archive tar du noyau)
dans /usr/include
, mais sur les
quelques années précédentes, les développeurs du noyau ont
acquis la conviction que cela ne devait pas se passer ainsi.
Cela a donné naissance au projet Linux-Libc-Headers, qui a
été conçu pour maintenir une version stable de l'API des
en-têtes de Linux.
Installez les fichiers d'en-tête :
cp -R include/asm-i386 /usr/include/asm cp -R include/linux /usr/include
Assurez-vous que tous les en-têtes appartiennent bien à root :
chown -R root:root /usr/include/{asm,linux}
Assurez-vous que tous les utilisateurs puissent lire les en-têtes :
find /usr/include/{asm,linux} -type d -exec chmod 755 {} \; find /usr/include/{asm,linux} -type f -exec chmod 644 {} \;
Le paquet Man-pages contient plus de 1 200 pages man.
Le paquet Glibc contient la bibliothèque C principale. Cette bibliothèque fournit toutes les routines basiques pour allouer de la mémoire, rechercher des répertoires, ouvrir et fermer des fichiers, les lire et les écrire, gérer les chaînes, faire correspondre des modèles, faire de l'arithmétique et ainsi de suite.
Ce paquet est connu pour avoir des soucis quand les options
d'optimisation par défaut (en incluant les options -march
et -mcpu
) sont modifiées. Donc, si
des variables d'environnement qui surchargent les
optimisations par défaut, telles que CFLAGS
et CXXFLAGS
,
ont été définies, supprimez cette initialisation pour la
construction de GCC.
Le système de construction de la Glibc est très bien fait et
s'installera parfaitement, même si notre fichier specs pour
le compilateur et l'éditeur de liens pointent toujours vers
/tools
. Les specs et l'éditeur
de liens ne peuvent pas être ajustés avant l'installation de
la Glibc parce que les tests d'autoconf de Glibc donneraient
alors des résultats faussés, défaussant ainsi notre but
d'achever une construction propre.
L'archive tar linuxthreads contient les pages man pour les bibliothèques de threading installées par Glibc. Déballez l'archive tar à l'intérieur du répertoire source Glibc :
tar -xjvf /sources/glibc-linuxthreads-2.3.4.tar.bz2
Glibc contient deux tests qui échoueront si le noyau en cours d'exécution est un 2.6.11.x. Le problème se situe sur les tests eux-même, pas avec la libc ou le noyau. Ce correctif corrige le problème :
patch -Np1 -i ../glibc-2.3.4-fix_test-1.patch
La documentation de Glibc recommande de construire Glibc en dehors du répertoire des sources dans un répertoire de construction dédié :
mkdir ../glibc-build cd ../glibc-build
Préparez la compilation de Glibc :
../glibc-2.3.4/configure --prefix=/usr \ --disable-profile --enable-add-ons \ --enable-kernel=2.6.0 --libexecdir=/usr/lib/glibc
Voici la signification des options de configure :
--libexecdir=/usr/lib/glibc
Ceci modifie l'emplacement du programme pt_chown
, dont la valeur par défaut
est /usr/libexec
, par
/usr/lib/glibc
.
Compilez le paquet :
make
Dans cette section, la suite de tests de Glibc est considérée comme critique. Ne pas la laissez passer quelque soient les circonstances.
Testez les résultats :
make check
La suite de tests Glibc est grandement dépendante de certaines fonctions de l'hôte système, en particulier le noyau. En général, la suite de tests Glibc devrait toujours réussir. Néanmoins, dans certaines circonstances, quelques échecs sont inévitables. Voici une liste des problèmes les plus fréquents :
Les tes math échouent quelque fois lors de leur exécution sur des systèmes où le processeur n'est pas un Intel ou un AMD authentique. Certains paramètrages d'optimisation sont aussi un facteur connu pour ce type de problèmes.
Les tests gettext échouent quelque fois à cause de problèmes sur le système hôte, les raisons exactes n'étant pas encore claires.
Si vous avez monté la partition LFS avec l'option
noatime
, le
test atime
échouera. Comme mentionné dans la section intitulée
« Monter la nouvelle partition »,
n'utilisez pas l'option noatime
lors de la
construction de LFS.
Lors d'une exécution sur un matériel ancien et lent, quelques tests peuvent échouer à cause de délais excédés.
Bien que ce ne soit qu'un simple message, l'étape
d'installation de Glibc se plaindra de l'absence de
/etc/ld.so.conf
. Supprimez ce
message d'avertissement avec :
touch /etc/ld.so.conf
Installez le paquet :
make install
Les locales qui permettent à votre système de répondre en une langue différente n'ont pas été installées avec la commande ci-dessus. Installez-les avec ceci :
make localedata/install-locales
Pour gagner du temps, une alternative à la commande
précédente (qui génère et installe toutes les locales qu'il
connait) est d'installer uniquement les locales que vous
souhaitez et dont vous avez besoin. Ceci se fait en utilisant
la commande localedef. Des informations sur
cette commande sont disponibles dans le fichier INSTALL
des sources de Glibc. Néanmoins, il
existe un certain nombre de locales essentielles pour réussir
les tests des paquets futurs, en particulier les tests de
libstdc++. Les
instructions suivantes, contrairement à la cible install-locales
ci-dessus,
installeront l'ensemble minimal des locales nécessaires pour
que les tests se passent dans de bonnes conditions :
mkdir -p /usr/lib/locale localedef -i de_DE -f ISO-8859-1 de_DE localedef -i de_DE@euro -f ISO-8859-15 de_DE@euro localedef -i en_HK -f ISO-8859-1 en_HK localedef -i en_PH -f ISO-8859-1 en_PH localedef -i en_US -f ISO-8859-1 en_US localedef -i es_MX -f ISO-8859-1 es_MX localedef -i fa_IR -f UTF-8 fa_IR localedef -i fr_FR -f ISO-8859-1 fr_FR localedef -i fr_FR@euro -f ISO-8859-15 fr_FR@euro localedef -i it_IT -f ISO-8859-1 it_IT localedef -i ja_JP -f EUC-JP ja_JP
Certaines locales installées par la commande make localedata/install-locales ci-dessus ne sont pas supportées correctement par certaines applications comprises dans les livres LFS et BLFS. À cause des différents problèmes survenus parce que les développeurs des applications ont fait dex choix qui ont cassé ces locales, LFS ne devrait pas être utilisé avec des locales qui utilisent des ensembles de caractères à plusieurs octets (ceci incluant UTF-8) ou l'ordre d'écriture de droite à gauche. De nombreux correctifs officieux et instables sont requis pour corriger ces problèmes et il a été décidé par les développeurs de LFS que ces locales complexes ne seraient pas supportées. Ceci s'applique aussi aux locales ja_JP et fa_IR—elles ont été installés seulement pour que les tests de GCC et Gettext réussissent bien que le programme watch (un composant du paquetage Procps) ne fonctionne pas correctement avec elles. Différents essais pour contourner ces restrictions sont documentés dans les astuces relatives à l'internationalisation.
Construisez les pages man de linuxthreads qui sont une grande référence à l'API des threads (applicable aussi à NPTL) :
make -C ../glibc-2.3.4/linuxthreads/man
Installez ces pages :
make -C ../glibc-2.3.4/linuxthreads/man install
Le fichier /etc/nsswitch.conf
doit être créé parce que, bien que Glibc en fournisse un par
défaut lorsque ce fichier est manquant ou corrompu, les
valeurs par défaut de Glibc ne fonctionnent pas bien dans un
environnement en réseau. De plus, le fuseau horaire a besoin
d'être configuré.
Créez un nouveau fichier /etc/nsswitch.conf
en lançant ce qui
suit :
cat > /etc/nsswitch.conf << "EOF" # Début /etc/nsswitch.conf passwd: files group: files shadow: files hosts: files dns networks: files protocols: files services: files ethers: files rpc: files # Fin /etc/nsswitch.conf EOF
Pour déterminer dans quel fuseau horaire vous vous situez, lancez le script suivant :
tzselect
Lorsque avoir répondu à quelques questions sur votre
emplacement, le script affichera le nom du fuseau horaire
(quelque chose comme EST5EDT ou Canada/Eastern). Ensuite, créez le
fichier /etc/localtime
en
lançant :
cp --remove-destination /usr/share/zoneinfo/[xxx] \ /etc/localtime
Remplacez [xxx]
avec le nom du fuseau horaire que tzselect a fourni (c'est-à-dire
Canada/Eastern).
Voici la signification de l'option de cp :
--remove-destination
Ceci est nécessaire pour forcer la suppression du lien
symbolique déjà existant. La raison pour laquelle nous
copions plutôt que de simplement créer un lien
symbolique est de se couvrir de la situation où
/usr
serait une partition
séparée. Ceci pourrait arriver, par exemple, en
démarrant en mode simple utilisateur.
Par défaut, le chargeur dynamique (/lib/ld-linux.so.2
) cherche les
bibliothèques partagées, nécessaires aux programmes lors de
leur exécution, dans /lib
et
/usr/lib
. Néanmoins, s'il
existe des bibliothèques dans d'autres répertoires que
/lib
et /usr/lib
, leur emplacement doit être ajouté
dans le fichier /etc/ld.so.conf
pour que le chargeur dynamique les trouve. /usr/local/lib
et /opt/lib
sont deux répertoires connus pour
contenir des bibliothèques supplémentaires, donc ajoutez ces
deux répertoires au chemin de recherche du chargeur
dynamique.
Créez un nouveau fichier /etc/ld.so.conf
en lançant ce qui
suit :
cat > /etc/ld.so.conf << "EOF" # Début /etc/ld.so.conf /usr/local/lib /opt/lib # Fin /etc/ld.so.conf EOF
Maintenant que les bibliothèques C finales ont été installées,
il est temps d'ajuster de nouveau l'ensemble d'outils.
L'ensemble d'outils sera ajusté de façon à ce qu'il lie tout
programme nouvellement compilé avec ces nouvelles
bibliothèques. C'est le même processus que celui utilisé dans
la phase « Ajustement » au
début du Chapitre 5,
avec les ajustements inversés. Dans Chapitre 5, l'ensemble était
passé des répertoires /{,usr/}lib
de l'hôte dans le nouveau répertoire /tools/lib
. Maintenant, l'ensemble sera guidé
du même répertoire /tools/lib
vers les répertoires /{,usr/}lib
de LFS.
Commencez en ajustant l'éditeur de liens. Les répertoires des
sources et de construction de la duxième passe de Binutils ont
été conservés dans ce but. Installez l'éditeur de liens ajusté
en exécutant la commande suivante à partir du répertoire
binutils-build
:
make -C ld INSTALL=/tools/bin/install install
Si le précédent avertissement pour conserver les
répertoires des sources et de construction de Binutils lors
de la deuxième passe dans Chapitre 5 a été oublié, ou
s'ils ont été accidentellement supprimés ou rendus
inaccessubles, ignorez la commande ci-dessus. Le résultat
en sera que le prochain paquet, Binutils, sera lié aux
bibliothèques C dans /tools
plutôt que dans /{,usr/}lib
.
Ceci n'est pas idéal. Néanmoins, les tests ont montrés que
les binaires Binutils résultants devraient être identiques.
À partir de maintenant, chaque programme compilé sera lié avec
les bibliothèques de /usr/lib
et
de /lib
. L'option supplémentaire
INSTALL=/tools/bin/install
est
nécessaire car le fichier Makefile
créé lors de la seconde passe
contient toujours la référence à /usr/bin/install, qui n'a pas encore
été installé. Quelques distributions hôtes contiennent un lien
symbolique ginstall
qui est
prioritaure dans le fichier Makefile
et peut cause un problème. La
commande ci-dessus tient compte de ce problème.
Supprimez les répertoires des sources et de construction de Binutils maintenant.
Ensuite, modifiez le fichier specs de GCC pour qu'il pointe sur le nouvel éditeur de liens. Une commande perl accomplit ceci :
perl -pi -e 's@ /tools/lib/ld-linux.so.2@ /lib/ld-linux.so.2@g;' \ -e 's@\*startfile_prefix_spec:\n@$_/usr/lib/ @g;' \ `gcc --print-file specs`
C'est une bonne idée d'inspecter visuellement le fichier specs pour vérifier que les modifications attendues ont réellement été effectuées.
En travaillant sur une plateforme où le nom de l'éditeur de
liens est quelque chose d'autres que ld-linux.so.2
, substituez
« ld-linux.so.2 » par
le nom de l'éditeur de liens dans les commandes suivantes.
Référez-vous à la section
intitulée « Notes techniques sur l'ensemble
d'outils » si nécessaire.
Il est impératif à ce moment d'arrêter et de vous assurer que le s fonctions basiques (compilation et édition des liens) de l'ensemble des outils ajusté fonctionnent comme attendu. Pour cela, réalisez une petite vérification :
echo 'main(){}' > dummy.c cc dummy.c readelf -l a.out | grep ': /lib'
Si tout fonctionne correctement, il ne devrait pas y avoir d'erreurs et la sortie de la commande sera (avec des différences spécifiques aux plateformes dans le nom de l'éditeur de liens) :
[Requesting program interpreter:
/lib/ld-linux.so.2]
Notez que /lib
est maintenant
le préfixe de notre éditeur de liens.
Si la sortie n'apparaît pas comme ce qui est montré ci-dessus ou si aucune sortie n'est renvoyée, alors quelque chose s'est mal passé. Investiguez et retracez les étapes pour savoir d'où vient le problème et comment le corriger. La raison la plus probable est que quelque chose s'est mal passé lors de la modification du fichier specs ci-dessus. Tout probl_me devra être résolu avant de continuer le processus.
Une fois que tout fonctionne correctement, nettoyez les fichiers tests :
rm dummy.c a.out
Le paquet Binutils contient un éditeur de liens, un assembleur et d'autres outils pour gérer des fichiers objets.
Ce paquet est connu pour avoir des soucis quand les options
d'optimisation par défaut (en incluant les options -march
et -mcpu
) sont modifiées. Donc, si
des variables d'environnement qui surchargent les
optimisations par défaut, telles que CFLAGS
et CXXFLAGS
,
ont été définies, supprimez cette initialisation pour la
construction de Binutils.
Vérifiez que les pseudo-terminaux (PTY) fonctionnent correctement dans l'environnement chroot. Vérifiez que tout est bien configuré en effectuant un test simple :
expect -c "spawn ls"
Si le message suivant apparaît, l'environnement chroot n'est pas configuré correctement pour des opérations sur les PTY :
The system has no more ptys.
Ask your system administrator to create more.
Ce problème doit être résolu avant de lancer les suites de tests pour Binutils et GCC.
La documentation de Binutils recommande de construire Binutils à l'extérieur du répertoire des sources dans un répertoire dédié :
mkdir ../binutils-build cd ../binutils-build
Préparez la compilation de Binutils :
../binutils-2.15.94.0.2.2/configure --prefix=/usr \ --enable-shared
Compilez le paquet :
make tooldir=/usr
Normalement, le répertoire tooldir (celui où seront placés
les exécutables) est configuré avec $(exec_prefix)/$(target_alias)
. Par
exemple, les machines i686 l'étendront en /usr/i686-pc-linux-gnu
. Comme il s'agit
d'un système personnalisé, nous n'avons pas besoin d'un
répertoire spécifique à notre cible dans /usr
. $(exec_prefix)/$(target_alias)
serait
utilisée si le système avait pour but une cross-compilation
(par exemple, compiler un paquet sur une machine Intel qui
génère du code pouvant être exécuté sur des machines
PowerPC).
La suite de tests de Binutils dans cette section est considérée comme critique. Ne pas la laissez passer, quelqu'en soit la raison.
Testez les résultats :
make check
Installez le paquet :
make tooldir=/usr install
Installez le fichier d'en-tête libiberty
, requis par certains
paquets :
cp ../binutils-2.15.94.0.2.2/include/libiberty.h /usr/include
Le paquet GCC contient la collection de compilateurs GNU, qui inclut les compilateurs C et C++.
Ce paquet est connu pour avoir des soucis quand les options
d'optimisation par défaut (en incluant les options -march
et -mcpu
) sont modifiées. Donc, si
des variables d'environnement qui surchargent les
optimisations par défaut, telles que CFLAGS
et CXXFLAGS
,
ont été définies, supprimez cette initialisation pour la
construction de GCC.
Appliquez seulement le correctif No-Fixincludes (et pas Specs) utilisé aussi dans le chapitre précédent :
patch -Np1 -i ../gcc-3.4.3-no_fixincludes-1.patch
La compilation de GCC échoue pour certains paquets en dehors d'une installation LFS de base (par exemple, Mozilla et kdegraphics) si GCC est utilisé avec les dernières versions de Binutils. Appliquez le correctif suivant pour corriger ce problème :
patch -Np1 -i ../gcc-3.4.3-linkonce-1.patch
Appliquez une substitution sed qui supprimera l'installation
de libiberty.a
. À la place, la
version de libiberty.a
fournie
par Binutils sera utilisée :
sed -i 's/install_to_$(INSTALL_DEST) //' libiberty/Makefile.in
La documentation de GCC recommande de construire GCC en dehors du répertoire source, c'est-à-dire dans un répertoire dédié :
mkdir ../gcc-build cd ../gcc-build
Préparez la compilation de GCC :
../gcc-3.4.3/configure --prefix=/usr \ --libexecdir=/usr/lib --enable-shared \ --enable-threads=posix --enable-__cxa_atexit \ --enable-clocale=gnu --enable-languages=c,c++
Compilez le paquet :
make
Dans cette section, la suite de tests pour GCC est considérée critique. Ne pas la laisser passer quelque soient les circonstances.
Testez les résultats mais ne vous arrêtez pas aux erreurs :
make -k check
Quelques erreurs sont connues et ont été indiquées dans le chapitre précédent. Les notes de la suite de tests sur la section intitulée « GCC-3.4.3 - Passe 2 » sont toujours très appropriées ici. Assurez-vous de vous y référer si nécessaire.
Installez le paquet :
make install
Quelques paquets s'attendent à ce que le préprocesseur C soit
installé dans le répertoire /lib
. Pour supporter ces paquets, créez ce
lien symbolique :
ln -s ../usr/bin/cpp /lib
Beaucoup de paquets utilisent le nom cc pour appeller le compilateur C. Pour satisfaire ces paquets, créez un lien symbolique :
ln -s gcc /usr/bin/cc
À ce moment, il est fortement recommandé de répéter les vérifications réalisées plus tôt dans ce chapitre. Référez-vous à la section intitulée « Ré-ajustement de l'ensemble d'outils » et répétez la vérification. Si les résultats sont mauvais, alors il y a des chances pour que le correctif GCC Specs ait été mal appliqué à partir de Chapitre 5.
Le paquet Coreutils contient des outils pour afficher et configurer les caractéristiques basiques d'un système.
Un problème connu avec le programme uname provenant de ce paquet est
que l'option -p
renvoit toujours unknown
.
Le correctif suivant corrige ce comportement pour les
architectures Intel :
patch -Np1 -i ../coreutils-5.2.1-uname-2.patch
Empêchez Coreutils d'installer des binaires qui pourraient être installés plus tard par d'autres paquets :
patch -Np1 -i \ ../coreutils-5.2.1-suppress_uptime_kill_su-1.patch
Maintenant, préparez la compilation de Coreutils :
DEFAULT_POSIX2_VERSION=199209 ./configure --prefix=/usr
Compilez le paquet :
make
La suite de tests de Coreutils fait quelques suppositions sur la présence d'utilisateurs et de groupes systèmes qui ne sont pas valides à l'intérieur de l'environnement minimal qui existe pour le moment. Du coup, des éléments supplémentaires doivent être configurés avant de lancer ces tests. Allez directement à « Installez le paquet » si vous ne comptez pas lancer les tests.
Créez deux groupes et un utilisateur :
echo "dummy1:x:1000:" >> /etc/group echo "dummy2:x:1001:dummy" >> /etc/group echo "dummy:x:1000:1000:::/bin/bash" >> /etc/passwd
Maintenant, la suite de tests peut être lancée. Tout d'abord, lancez les quelques tests qui ont besoin d'être lancé en tant que root :
make NON_ROOT_USERNAME=dummy check-root
Puis, lancez le reste des tests en tant qu'utilisateur dummy :
src/su dummy -c "make RUN_EXPENSIVE_TESTS=yes check"
Une fois les tests terminés, supprimez l'utilisateur et les groupes :
sed -i '/dummy/d' /etc/passwd /etc/group
Installez le paquet :
make install
Déplacez quelques programmes aux bons emplacements :
mv /usr/bin/{[,basename,cat,chgrp,chmod,chown,cp,dd,df} /bin mv /usr/bin/{date,echo,false,head,hostname,install,ln} /bin mv /usr/bin/{ls,mkdir,mknod,mv,pwd,rm,rmdir,sync} /bin mv /usr/bin/{sleep,stty,test,touch,true,uname} /bin mv /usr/bin/chroot /usr/sbin
Finalement, créez un lien symbolique pour être compatible avec la FHS :
ln -s ../../bin/install /usr/bin
Le paquet Zlib contient des routines de compression et décompression utilisées par quelques programmes.
Zlib a une vulnérabilité de type dépassement de tampon, pouvant amener à une attaque de type déni de service. Le correctif suivant corrige le problème :
patch -Np1 -i ../zlib-1.2.2-security_fix-1.patch
Zlib est connu pour mal construire sa bibliothèque
partagée si CFLAGS
fait partie
de l'environnement. En initialisant une variable
CFLAGS
, assurez-vous d'ajouter
la directive -fPIC
à la variable
CFLAGS
pour la durée de la
commande configure ci-dessous puis de la
supprimer après coup.
Préparez la compilation de Zlib :
./configure --prefix=/usr --shared --libdir=/lib
Compilez le paquet :
make
Pour tester les résultats, lancez : make check
.
Installez la bibliothèque partagée :
make install
La commande précédente a installé un fichier .so
dans /lib
. Nous le supprimerons et créerons de
nouveau un lien vers /usr/lib
:
rm /lib/libz.so ln -sf ../../lib/libz.so.1.2.2 /usr/lib/libz.so
Construisez aussi la bibliothèque statique :
make clean ./configure --prefix=/usr make
Pour tester de nouveau les résultats, lancez :
make check
.
Installez la bibliothèque statique :
make install
Corrigez les droits sur la bibliothèque statique :
chmod 644 /usr/lib/libz.a
Le paquet Mktemp contient des programmes utilisés pour créer des fichiers temporaires sécurisés à partir de scripts shell.
Beaucoup de scripts utilisent toujours le programme obsolète tempfile, qui dispose à peu près des mêmes fonctionnalités que mktemp. Corrigez mktemp pour inclure un emballage tempfile :
patch -Np1 -i ../mktemp-1.5-add_tempfile-2.patch
Préparez la compilation de Mktemp :
./configure --prefix=/usr --with-libc
Voici la signification de l'option de configure :
--with-libc
Ceci fait que le programme mktemp utilise les fonctions mkstemp et mkdtemp de la bibliothèque système C.
Compilez le paquet :
make
Installez le paquet :
make install make install-tempfile
Le paquet Iana-Etc fournit des données pour les services et protocoles réseau.
La commande suivante convertit les données brutes fournies
par l'IANA dans les bons formats pour les fichiers de données
/etc/protocols
et /etc/services
:
make
Installez le paquet :
make install
Le paquet Findutils contient des programmes de recherche de fichiers. Ces programmes sont fournis pour rechercher récursivement dans une hiérarchie de répertoires et pour créer, maintenir et chercher dans une base de données (souvent plus rapide que la recherche récursive mais moins fiable si la base de données n'a pas été mise à jour récemment).
Préparez la compilation de Findutils :
./configure --prefix=/usr --libexecdir=/usr/lib/locate \ --localstatedir=/var/lib/misc
L'option localstatedir ci-dessus change l'emplacement de la base de données locate avec /var/lib/misc pour être compatible avec FHS.
Compilez le paquet :
make
Pour tester les résultats, lancez : make check
.
Installez le paquet :
make install
Le paquet Gawk contient des programmes de manipulation de fichiers texte.
Préparez la compilation de Gawk :
./configure --prefix=/usr --libexecdir=/usr/lib
Compilez le paquet :
make
Pour tester les résultats, lancez : make check
.
Installez le paquet :
make install
Le paquet Ncurses contient les bibliothèques de gestion des écrans type caractère, indépendant des terminaux.
Préparez la compilation de Ncurses :
./configure --prefix=/usr --with-shared --without-debug
Compilez le paquet :
make
Ce paquet ne fournit pas de suite de tests.
Installez le paquet :
make install
Donnez les droits en exécution des bibliothèques Ncurses :
chmod 755 /usr/lib/*.5.4
Corrigez une bibliothèque qui ne devrait pas être exécutable :
chmod 644 /usr/lib/libncurses++.a
Déplacez les bibliothèques dans le répertoire /lib
où elles sont supposées être :
mv /usr/lib/libncurses.so.5* /lib
Comme les bibliothèques ont été déplacées, certains liens symboliques pointent vers des fichiers inexistants. Re-créez ces liens symboliques :
ln -sf ../../lib/libncurses.so.5 /usr/lib/libncurses.so ln -sf libncurses.so /usr/lib/libcurses.so
Le paquet Readline est un ensemble de bibliothèques qui offrent des fonctionnalités d'édition de la ligne de commande et d'historique.
Le correctif suivant inclut une correction pour un problème où Readline affiche parfois seulement 33 caractères sur une ligne puis continue sur la suivante. Il inclut aussi d'autres corrections recommandées par l'auteur de Readline.
patch -Np1 -i ../readline-5.0-fixes-1.patch
Préparez la compilation de Readline :
./configure --prefix=/usr --libdir=/lib
Compilez le paquet :
make SHLIB_XLDFLAGS=-lncurses
Voici la signification de l'option de make :
SHLIB_XLDFLAGS=-lncurses
Cette option force Readline à se lier à la bibliothèque
libncurses
.
Installez le paquet :
make install
Donnez aux bibliothèques dynamiques de Readline plus de droits appropriés :
chmod 755 /lib/lib{readline,history}.so*
Maintenant, déplacez les bibliothèques dynamiques à un emplacement plus appropriées :
mv /lib/lib{readline,history}.a /usr/lib
Ensuite, supprimez les fichiers .so
dans /lib
et créez un lien vers /usr/lib
.
rm /lib/lib{readline,history}.so ln -sf ../../lib/libreadline.so.5 /usr/lib/libreadline.so ln -sf ../../lib/libhistory.so.5 /usr/lib/libhistory.so
Le paquet Vim contient un puissant éditeur de texte.
Si vous préférez un autre éditeur, comme Emacs, Joe ou Nano, merci de vous référer à http://www.linuxfromscratch.org/blfs/view/svn/postlfs/editors.html pour des instructions d'installation.
Tout d'abord, déballez les archives vim-6.3.tar.bz2
et (en option) vim-6.3-lang.tar.gz
dans le même
répertoire. Puis, changez les emplacements par défaut des
fichiers de configuration vimrc
et gvimrc
par /etc
:
echo '#define SYS_VIMRC_FILE "/etc/vimrc"' >> src/feature.h echo '#define SYS_GVIMRC_FILE "/etc/gvimrc"' >> src/feature.h
Vim a une vulnérabilité de sécurité déjà adressé par le mainteneur. Le correctif suivant s'occupe lui-aussi du problème :
patch -Np1 -i ../vim-6.3-security_fix-1.patch
Maintenant, préparez la compilation de Vim :
./configure --prefix=/usr --enable-multibyte
Le commutateur optionnel mais hautement recommandé --enable-multibyte
inclut le
support pour l'édition de fichiers comprenant des codages de
caractères multioctets dans vim. Ceci est nécessaire dans le
cas d'une utilisation d'une locale avec un ensemble de
caractères multi-octets. Ce commutateur peut aussi être utile
pour avoir la capacité d'éditer des fichiers créés
initialement avec des distributions Linux comme Fedora Core
qui utilise UTF-8 comme ensemble de caractères par défaut.
Compilez le paquet :
make
Pour tester les résultats, lancez : make test
. Néanmoins, cette
suite de tests affiche à l'écran beaucoup de caractères
binaires qui peuvent causer des soucis sur votre terminal.
Ceci peut se résoudre en redirigeant la sortie vers un
journal de traces.
Installez le paquet :
make install
Beaucoup d'utilisateurs sont habitués à utiliser vi au lieu de vim. Pour permettre l'exécution de vim quand les utilisateurs saisissent habituellement vi, créez un lien symbolique :
ln -s vim /usr/bin/vi
Si un système X Window va être installé sur votre système LFS, il pourrait être nécessaire de recompiler Vim après avoir installé X. Vim fournit alors une jolie version GUI de l'éditeur qui requiert X et quelques autres bibliothèques pour s'installer. Pour plus d'informations sur ce processus, référez-vous à la documentation de Vim et à la page d'installation de Vim dans le livre BLFS sur http://www.linuxfromscratch.org/blfs/view/svn/postlfs/editors.html#postlfs-editors-vim.
Par défaut, vim est lancé en mode compatible vi. Ceci pourrait être nouveau pour les personnes qui ont utilisé d'autres éditeurs dans le passé. Le paramètre « nocompatible » est inclus ci-dessous pour surligner le fait qu'un nouveau comportement est en cours d'utilisation. Il rappelle aussi à ceux qui voudraient le changer en mode « compatible » qu'il devrait être le premier paramètre dans le fichier de configuration. Ceci est nécessaire car il modifie d'autres paramètres et la surcharge doit survenir après ce paramètre. Créez un fichier de configuration vim par défaut en lançant ce qui suit :
cat > /etc/vimrc << "EOF" " Début /etc/vimrc set nocompatible set backspace=2 syntax on if (&term == "iterm") || (&term == "putty") set background=dark endif " Fin /etc/vimrc EOF
L'option set
nocompatible
change le comportement de
vim d'une façon
plus utile que le comportement compatible vi. Supprimez
« no » pour conserver le
comportement de l'ancien vi. Le paramètre set backspace=2
permet le
retour en arrière après des sauts de ligne, l'indentation
automatique et le début de l'insertion. L'instruction
syntax on
active la
coloration syntaxique. Enfin, l'instruction if avec set background=dark
corrige
l'estimation de vim concernant la couleur du fond
de certains émulateurs de terminaux. Ceci permet d'utiliser
de meilleurs gammes de couleurs pour la coloration
syntaxique, notamment avec les fonds noirs de ces programmes.
La documentation pour les autres options disponibles peut être obtenue en lançant la commande suivante :
vim -c ':options'
Le paquet M4 contient un processeur de macros.
Préparez la compilation de M4 :
./configure --prefix=/usr
Compilez le paquet :
make
Pour tester les résultats, lancez : make check
.
Installez le paquet :
make install
Le paquet Bison contient un générateur d'analyseurs.
Préparez la compilation de Bison :
./configure --prefix=/usr
Compilez le paquet :
make
Pour tester les résultats, lancez : make check
.
Installez le paquet :
make install
Le paquet Less contient un visualisateur de fichiers texte.
Préparez la compilation de Less :
./configure --prefix=/usr --bindir=/bin --sysconfdir=/etc
Voici la signification de l'option de configure :
--sysconfdir=/etc
:
cette option indique aux programmes créés par le paquet
de chercher leurs fichiers de configuration dans
/etc
.
--sysconfdir=/etc
Cette option indique aux programmes créés par le paquet
de chercher leurs fichiers de configuration dans
/etc
.
Compilez le paquet :
make
Installez le paquet :
make install
Le paquet Groff contient des programmes de formattage de texte.
Groff s'attend à ce que la variable d'environnement
PAGE
contienne la taille par
défaut du papier. Pour les habitants des États-Unis,
PAGE=letter
est
approprié. Ailleurs, PAGE=A4
est préférable.
Préparez la compilation de Groff :
PAGE=[taille_papier] ./configure --prefix=/usr
Compilez le paquet :
make
Installez le paquet :
make install
Quelques programmes de documentation, comme xman, ne fonctionnent pas correctement sans les liens symboliques suivants :
ln -s soelim /usr/bin/zsoelim ln -s eqn /usr/bin/geqn ln -s tbl /usr/bin/gtbl
Le paquet Sed contient un éditeur de flux.
Préparez la compilation de Sed :
./configure --prefix=/usr --bindir=/bin
Compilez le paquet :
make
Pour tester les résultats, lancez : make check
.
Installez le paquet:
make install
Le paquet Flex contient un outil de génération de programmes reconnaissant des modèles de texte.
Flex contient quelques bogues connus. Corrigez-les avec le correctif suivant :
patch -Np1 -i ../flex-2.5.31-debian_fixes-3.patch
GNU autotools détecte que le code source de Flex a été modifié par le correctif précédent et essaie de mettre à jour la page man en accord. Ceci ne fonctionne pas sur beaucoup de systèmes et la page par défaut est bonne, donc assurez-vous qu'elle ne soit pas regénérée :
touch doc/flex.1
Préparez la compilation de Flex :
./configure --prefix=/usr
Compilez le paquet :
make
Pour tester les résultats, lancez : make check
.
Installez le paquet :
make install
Quelques paquets s'attendent à trouver la bibliothèque
lex
dans /usr/lib
. Créez un lien symbolique pour en
tenir compte :
ln -s libfl.a /usr/lib/libl.a
Quelques programmes ne connaissent pas encore
flex et
essaient de lancer son prédecesseur lex. Pour supporter ces programmes,
créez un script d'emballage nommé lex
appelant flex
en mode d'émulation
lex :
cat > /usr/bin/lex << "EOF" #!/bin/sh # Begin /usr/bin/lex exec /usr/bin/flex -l "$@" # End /usr/bin/lex EOF chmod 755 /usr/bin/lex
Le paquet Gettext contient des outils pour l'internationalisation et la localisation. Ceci permet aux programmes d'être compilés avec le support des langages natifs (Native Language Support ou NLS), leur permettant d'afficher des messages dans la langue native de l'utilisateur.
Préparez la compilation de Gettext :
./configure --prefix=/usr
Compilez le paquet :
make
Pour tester les résultats, lancez : make check
. Ceci peut
prendre beaucoup de temps, pratiquement 7 SBU.
Installez le paquet :
make install
Le paquet Inetutils contient des programmes réseau basiques.
Inetutils a quelques soucis avec la série 2.6 du noyau Linux. Corrigez-les en appliquant le correctif suivant :
patch -Np1 -i ../inetutils-1.4.2-kernel_headers-1.patch
Les programmes venant avec Inetutils ne seront pas tous installés. Néanmoins, le système de construction d'Inetutils insistera malgré tout sur l'installation de toutes les pages man. Le correctif suivant corrigera cette situation :
patch -Np1 -i ../inetutils-1.4.2-no_server_man_pages-1.patch
Préparez la compilation d'Inetutils :
./configure --prefix=/usr --libexecdir=/usr/sbin \ --sysconfdir=/etc --localstatedir=/var \ --disable-logger --disable-syslogd \ --disable-whois --disable-servers
Voici la signification des options de configure :
--disable-logger
Cette option empêche l'installation du programme logger par Inetutils. Ce programme est utilisé par les scripts pour passer des messages au démon des traces système. Nous ne l'installons pas car Util-linux livre une version bien meilleure après.
--disable-syslogd
Cette option empêche l'installation du démon de traces système par Inetutils car il est installé avec le paquet Sysklogd.
--disable-whois
cette option désactive la construction du client whois d'Inetutils qui est vraiment obsolète. Les instructions pour un meilleur client whois sont dans le livre BLFS.
--disable-servers
Ceci désactive l'installation des différents serveurs réseau inclus dans le paquet Inetutils. Ces serveurs semblent inappropriés dans un système LFS de base. Certains sont non sécurisés et ne sont pas considérés sains sur des réseaux de confiance. Plus d'informations sont disponibles sur http://www.linuxfromscratch.org/blfs/view/svn/basicnet/inetutils.html. Notez que de meilleurs remplacements sont disponibles pour certains de ces serveurs.
Compilez le paquet :
make
Installez le paquet :
make install
Déplacez le programme ping à un emplacement compatible avec FHS :
mv /usr/bin/ping /bin
Le paquet IPRoute2 contient des programmes pour le réseau, basique ou avancé, basé sur IPV4.
Le binaire arpd inclus dans ce paquet est dépendant de Berkeley DB. Comme arpd n'est pas un prérequis commun sur un système Linux de base, supprimez la dépendance sur Berkeley DB en appliquant le correctif avec la commande ci-dessous. Si le binaire arpd est nécessaire, les instructions pour compiler Berkeley DB sont disponibles dans le livre BLFS sur http://www.linuxfromscratch.org/blfs/view/svn/server/databases.html#db.
patch -Np1 -i ../iproute2-2.6.11_050330-remove_db-1.patch
Préparez la compilation d'IPRoute2 :
./configure
Compilez le paquet :
make SBINDIR=/sbin
Voici la signification de l'option de make :
SBINDIR=/sbin
Ceci nous assure que les binaires IPRoute2 seront
installés dans /sbin
.
C'est le bon emplacement suivant la FHS parce que
certains des binaires IPRoute2 sont utilisés dans les
scripts de démarrage.
Installez le paquet :
make SBINDIR=/sbin install
Le paquet Perl contient le langage pratique d'extraction et de rapport (Practical Extraction and Report Language).
Si vous voulez avoir un contrôle total sur la façon dont Perl est configuré, lancez le script interactif Configure et choisissez la façon dont le paquet est construit. Si les valeurs par défaut détectées automatiquement sont convenables, préparez la compilation de Perl ainsi :
./configure.gnu --prefix=/usr -Dpager="/bin/less -isR"
Voici la signification de l'option de configure :
-Dpager="/bin/less
-isR"
Ceci corrige une erreur dans le code de perldoc lors de l'appel du programme less.
Compilez le paquet :
make
Pour exécuter la suite de tests, créez tout d'abord un
fichier /etc/hosts
basique,
nécessaire à quelques tests pour résoudre le nom localhost :
echo "127.0.0.1 localhost $(hostname)" > /etc/hosts
Maintenant, lancez les tests si vous le souhaitez :
make test
Installez le paquet :
make install
Le paquet Texinfo contient des programmes de lecture, écriture et de conversion des pages Info.
Préparez la compilation de Texinfo :
./configure --prefix=/usr
Compilez le paquet :
make
Pour tester les résultats, lancez : make check
.
Installez le paquet :
make install
De manière optionnelle, installez les composants appartenant à une installation TeX :
make TEXMF=/usr/share/texmf install-tex
Voici la signification du paramètre de make :
TEXMF=/usr/share/texmf
La variable TEXMF
du
Makefile contient l'emplacement de la racine de votre
répertoire TeX si, par exemple, un paquet TeX sera
installé plus tard. later.
Le système de documentation Info utilise un fichier texte
pour contenir sa liste des entrées de menu. Le fichier est
situé dans /usr/share/info/dir
.
Malheureusement, à cause de problèmes occasionnels dans les
Makefiles de différents paquets, il peut être non synchronisé
avec les pages info. Si le fichier /usr/share/info/dir
a besoin d'être
re-créé, les commandes suivantes accompliront cette
tâche :
cd /usr/share/info rm dir for f in * do install-info $f dir 2>/dev/null done
Le paquet Autoconf contient des programmes produisant des scripts shell qui configurent automatiquement le code source.
Préparez la compilation d'Autoconf :
./configure --prefix=/usr
Compilez le paquet :
make
Pour tester les résultats, lancez : make check
. Ceci prend du
temps, pratiquement 2 SBU.
Installez le paquet :
make install
Le paquet Automake contient des programmes de génération de Makefile à utiliser avec Autoconf.
Préparez la compilation d'Automake :
./configure --prefix=/usr
Compilez le paquet :
make
Pour tester les résultats, lancez : make check
. Ceci peut
prendre beaucoup de temps, environ 5 SBU.
Installez le paquet :
make install
Le paquet Bash contient le shell Bourne-Again.
Le correctif suivant corrige quelques problèmes, dont celui où Bash ne montre quelque fois que 33 caractères sur une ligne puis passe à la suivante :
patch -Np1 -i ../bash-3.0-fixes-3.patch
Bash a aussi des problèmes lorsqu'il est compilé avec les dernières versions de Glibc. Le correctif suivant résout ce problème :
patch -Np1 -i ../bash-3.0-avoid_WCONTINUED-1.patch
Préparez la compilation de Bash :
./configure --prefix=/usr --bindir=/bin \ --without-bash-malloc --with-installed-readline
Voici la signification de l'option de configure :
--with-installed-readline
Ce commutateur indiqué à Bash d'utiliser la
bibliothèque readline
qui
est déjà installée sur le système plutôt que d'utiliser
sa propre version de readline.
Compilez le paquet :
make
Pour tester les résultats, lancez : make tests
.
Installez le paquet :
make install
Lancez le programme bash nouvellement compilé (en remplaçant celui en cours d'exécution) :
exec /bin/bash --login +h
Les paramètres utilisés font que bash lance un shell de connexion interactif et désactive le hachage, de façon à ce que les nouveaux programme soient découverts au fur et à mesure de leur disponibilité.
Le paquet File contient un outil pour déterminer le type d'un fichier ou des fichiers donnés.
Préparez la compilation de File :
./configure --prefix=/usr
Compilez le paquet :
make
Installez le paquet :
make install
Le paquet Libtool contient le script de support de bibliothèques génériques GNU. Il emballe la complexité d'utilisation de bibliothèques partagées dans une interface cohérente et portable.
Préparez la compilation de Libtool :
./configure --prefix=/usr
Compilez le paquet :
make
Pour tester les résultats, lancez : make check
.
Installez le paquet :
make install
Le paquet Bzip2 contient des programmes de compression et décompression de fichiers. Compresser des fichiers texte avec bzip2 permettent d'atteindre un taux de compression bien meilleur qu'avec l'outil gzip traditionnel.
Préparez la compilation de Bzip2 avec :
make -f Makefile-libbz2_so make clean
Le commutateur -f
fera que Bzip2 sera construit en utilisant un fichier
Makefile
différent, dans ce cas
le fichier Makefile-libbz2_so
,
qui crée une bibliothèque libbz2.so
dynamique et lie les outils Bzip2
avec.
Compilez le paquet :
make
Pour tester les résultats, lancez : make test
En cas de réinstallation de Bzip2, effectuez un
rm -f
/usr/bin/bz*
en premier, sinon les prochains
make install
échoueront.
Installez les programmes :
make install
Installez le binaire dynamique bzip2 dans le répertoire
/bin
, créez les liens
symboliques nécessaires et nettoyez :
cp bzip2-shared /bin/bzip2 cp -a libbz2.so* /lib ln -s ../../lib/libbz2.so.1.0 /usr/lib/libbz2.so rm /usr/bin/{bunzip2,bzcat,bzip2} ln -s bzip2 /bin/bunzip2 ln -s bzip2 /bin/bzcat
Le paquet Diffutils contient les programmes montrant les différences entre fichiers ou répertoires.
Préparez la compilation de Diffutils :
./configure --prefix=/usr
Compilez le paquet :
make
Ce paquet ne fournit pas de suite de tests.
Installez ce paquet :
make install
Le paquet Kbd contient les fichiers de plan de codage et des outils pour le clavier.
Préparez la compilation de Kbd :
./configure
Compilez le paquet :
make
Maintenant, installez-le :
make install
Le paquet E2fsprogs contient les outils de gestion du système
de fichiers ext2
. Il supporte
aussi le système de fichiers journalisé ext3
.
Corrigez une erreur de compilation dans la suite de tests d'E2fsprogs :
sed -i -e 's/-DTEST/$(ALL_CFLAGS) &/' lib/e2p/Makefile.in
Il est recommandé de construire E2fsprogs dans un sous-répertoire du répertoire source :
mkdir build cd build
Préparez la compilation d'E2fsprogs :
../configure --prefix=/usr --with-root-prefix="" \ --enable-elf-shlibs --disable-evms
Voici la signification des options de configure :
--with-root-prefix=""
Certains programmes (comme e2fsck) sont considérés
essentiels. Quand, par exemple, /usr
n'est pas monté, ces programmes
essentiels doivent encore être disponibles. Ils
appartiennent aux répertoires comme /lib
et /sbin
. Si cette option n'est pas
passée au configure d'E2fsprogs, les programmes sont
placés dans le répertoire /usr
.
--enable-elf-shlibs
Ceci crée les bibliothèques partagées que certains programmes de ce paquet utilisent.
--disable-evms
Ceci désactive la construction du plugin EVMS (Enterprise Volume Management System). Ce plugin n'est pas à jour abec les dernières interfaces internes d'EVMS et EVMS n'est pas installé comme partie intégrante d'un système LFS de base, donc ce plugin n'est pas requis. Voir le site web d'EVMS sur http://evms.sourceforge.net/ pour plus d'informations concernant EVMS.
Compilez le paquet :
make
Pour tester les résultats, lancez : make check
.
Installez les binaires et la documentation :
make install
Installez aussi les bibliothèques partagées :
make install-libs
Le paquet Grep contient des programmes de recherche à l'intérieur de fichiers.
Préparez la compilation de Grep :
./configure --prefix=/usr --bindir=/bin
Compilez le paquet :
make
Pour tester les résultats, lancez : make check
.
Installez le paquet :
make install
Le paquet Grub contient un chargeur de démarrage, le GRand Unified Bootloader.
Ce paquet est connu pour avoir des soucis quand les options
d'optimisation par défaut (en incluant les options -march
et -mcpu
) sont modifiées. Donc, si
des variables d'environnement qui surchargent les
optimisations par défaut, telles que CFLAGS
et CXXFLAGS
,
ont été définies, supprimez cette initialisation pour la
construction de Grub.
Préparez la compilation de Grub :
./configure --prefix=/usr
Compilez le paquet :
make
Pour tester les résultats, lancez : make check
.
Notez que les résultats des tests afficheront toujours l'erreur « ufs2_stage1_5 is too big ». Ceci est dû à un problème du compilateur mais peut être ignoré sauf si vous plannifiez de démarrer à partir d'une partition LFS. Normalement, les partitions sont uniquement utilisées par les stations de travail Sun.
Installez le paquet :
make install mkdir /boot/grub cp /usr/lib/grub/i386-pc/stage{1,2} /boot/grub
Remplacez i386-pc
par le
répertoire adéquat pour le matériel utilisé.
Le répertoire i386-pc
contient
aussi un certain nombre de fichiers *stage1_5
, différents suivant les
différents systèmes de fichiers. Jetez un œil aux
fichiers disponibles et copiez les bons dans le répertoire
/boot/grub
. La plupart des
utilisateurs copieront les fichiers e2fs_stage1_5
et/ou reiserfs_stage1_5
.
Le paquet Gzip contient des programmes de compression et décompression de fichiers.
Gzip a deux vulnérabilités connues. Le correctif suivant s'occupe des deux problèmes :
patch -Np1 -i ../gzip-1.3.5-security_fixes-1.patch
Préparez la compilation de Gzip :
./configure --prefix=/usr
Le script gzexe contient, codé en dur, l'emplacement du binaire gzip. Comme l'emplacement de ce binaire changera plus tard, la commande suivante nous assure que le nouvel emplacement sera placé dans le script :
sed -i 's@"BINDIR"@/bin@g' gzexe.in
Compilez le paquet :
make
Installez le paquet :
make install
Déplacez les programmes dans le répertoire /bin
et créez quelques liens symboliques
couramment utilisés :
mv /usr/bin/gzip /bin rm /usr/bin/{gunzip,zcat} ln -s gzip /bin/gunzip ln -s gzip /bin/zcat ln -s gzip /bin/compress ln -s gunzip /bin/uncompress
Le paquetage Hotplug contient des scripts qui réagissent aux
événements hotplug générés par le noyau. De tels événements
correspondent à chaque modification de l'état du noyau,
visible dans le système de fichiers sysfs
, c'est-à-dire l'ajout et la
suppression de matériels. Ce paquetage détecte aussi le
matériel existant lors du démarrage et insère les modules
adéquats dans le noyau en cours d'exécution.
Installez le paquetage Hotplug :
make install
Copiez un fichier que la cible « install » oublie.
cp etc/hotplug/pnp.distmap /etc/hotplug
Supprimez le script de démarrage qu'Hotplug installe car nous allons utiliser le script inclus dans le paquetage LFS-Bootscripts :
rm -rf /etc/init.d
La découverte via Hotplug des périphériques réseau n'est pas encore supportée par le paquetage LFS-Bootscripts. Pour cette raison, supprimez l'agent hotplug pour le réseau :
rm -f /etc/hotplug/net.agent
Créez un répertoire pour stocker les firmware pouvant être chargés par hotplug :
mkdir /lib/firmware
Le paquet Man contient des programmes de recherche et de visualisation de pages man.
Deux ajustements doivent être effectués sur les sources de Man.
Le premier est une substitution sed pour ajouter l'option
-R
à la variable
PAGER
de façon à ce que les
séquences d'échappement soient correctement gérées par
Less :
sed -i 's@-is@&R@g' configure
La seconde est aussi une substitution sed décommentant la ligne
« MANPATH /usr/man »
dans le fichier man.conf
pour
supprimer les résultats redondants lors de l'utilisation de
programmes comme whatis :
sed -i 's@MANPATH./usr/man@#&@g' src/man.conf.in
Préparez la compilation de Man :
./configure -confdir=/etc
Voici la signification des options de configure :
-confdir=/etc
Ceci indique au programme man de rechercher le fichier
de configuration man.conf
dans le répertoire /etc
.
Compilez le paquet :
make
Installez-le :
make install
Si vous travaillez sur un terminal qui ne supporte pas
les attributs de texte comme la couleur ou l'emphase,
vous pouvez désactiver les séquences d'échappement
« Select Graphic Rendition
(SGR) » en modifiant le fichier man.conf
et en ajoutant l'option
-c
à la variable
NROFF
. Si vous utilisez
plusieurs types de terminaux pour un ordinateur, il
serait mieux d'ajouter de façon sélective la variable
d'environnement GROFF_NO_SGR
pour les terminaux qui ne supportent pas SGR.
Si l'ensemble de caractères de la locale utilise les
caractères 8 bits, recherchez la ligne commençant avec
« NROFF » dans
/etc/man.conf
et vérifiez
qu'elle correspond à la suivante :
NROFF /usr/bin/nroff -Tlatin1 -mandoc
Notez que « latin1 »
devrait être utilisé même s'il ne s'agit pas de l'ensemble de
caractères de la locale. La raison en est que, suivant la
spécification, groff n'a aucun moyen de présenter
les caractères en dehors de l'ISO 8859-1 sans quelques codes
d'échappement étranges. En formatant les pages man,
groff pense
qu'elles sont dans le codage ISO 8859-1 et le commutateur
-Tlatin1
indique à
groff
d'utiliser le même codage pour la sortie. Comme
groff ne recode
pas les caractères en entrée, le résultat formaté est
réellement dans le même codage qu'en entrée et est, du coup,
utilisable en entrée par un paginateur.
Ceci ne résout pas le problème du programme bogué man2dvi pour les pages man localisés dans des locales autres que ISO 8859-1. De plus, cela ne fonctionne pas avec des ensembles de caractères multi-octets. Le premier problème n'a pas de solution. Le second n'a pas d'importance car l'installation LFS ne supporte pas les ensembles de caractères multi-octets.
Des informations supplémentaires concernant la compression des pages man et info sont disponibles dans le livre BLFS sur http://www.linuxfromscratch.org/blfs/view/cvs/postlfs/compressdoc.html.
Le paquet Make contient un programme pour compiler des paquetages.
Préparez la compilation de Make :
./configure --prefix=/usr
Compilez le paquet :
make
Pour tester les résultats, lancez : make check
.
Installez le paquet :
make install
Le paquet Module-Init-Tools contient des programmes de gestion des modules des noyaux Linux pour les versions 2.5.47 et ultérieures.
Module-Init-Tools tente de ré-écrire sa page man modprobe.conf
lors de la construction. Ceci
n'est pas nécessaire et repose aussi sur la commande
docbook2man
— qui n'est pas installé dans LFS. Lancez la commande
suivante pour éviter ceci :
touch modprobe.conf.5
Préparez la compilation de Module-Init-Tools :
./configure --prefix="" --enable-zlib
Voici la signification des options de configure :
--enable-zlib
Ceci permet au paquetage Module-Init-Tools de gérer les modules noyau compressés.
Compilez le paquet :
make
Pour tester les résultats, lancez : make check
.
Installez le paquet :
make install
Le paquet Patch contient un programme permettant de modifier et de créer des fichiers en appliquant un fichier correctif (appelé généralement « patch ») créé généralement par le programme diff.
Préparez la compilation de Patch. Le commutateur -D_GNU_SOURCE
du préprocesseur
est seulement nécessaire pour les PowerPC. Pour les autres
machines, il est inutile) :
CPPFLAGS=-D_GNU_SOURCE ./configure --prefix=/usr
Compilez le paquet :
make
Ce paquet ne fournit pas de suite de tests.
Installez le paquet :
make install
Le paquet Procps contient des programmes pour surveiller les processus.
Le paquet Psmisc contient des programmes pour afficher des informations sur les processus en cours d'exécution.
Préparez la compilation de Psmisc pour :
./configure --prefix=/usr --exec-prefix=""
Voici la signification de l'option de configure :
--exec-prefix=""
Ceci nous assure que les binaires de Psmisc sont
installés dans /bin
au
lieu de /usr/bin
. D'après
le FHS? il s'agit du bon emplacement car certaines de
binaires de Psmisc sont utilisés dans des scripts de
démarrage.
Compilez le paquet :
make
Installez le paquet :
make install
Il n'existe aucune raison pour que les programmes
pstree et
pstree.x11
résident dans /bin
. Du coup,
déplaçez-les dans /usr/bin
:
mv /bin/pstree* /usr/bin
Par défaut, le programme pidof de Psmisc n'est pas installé. Généralement, ce n'est pas un problème car le paquet Sysvinit installe une meilleure version de pidof. Mais si Sysvinit ne sera pas utilisé, terminez l'installation de Psmisc en créant le lien symbolique suivant :
ln -s killall /bin/pidof
Le paquet Shadow contient des programmes de gestion de mots de passe d'une façon sécurisée.
Préparez la compilation de Shadow :
./configure --libdir=/lib --enable-shared
Supprimez l'installation du programme groups et de sa page man car Coreutils fournit une meilleure version :
sed -i 's/groups$(EXEEXT) //' src/Makefile sed -i '/groups/d' man/Makefile
Compilez le paquet :
make
Installez le paquet :
make install
Shadow utilise deux fichiers pour configurer les paramètrages d'authentification du système. Installez ces deux fichiers de configuration :
cp etc/{limits,login.access} /etc
Au
lieu d'utiliser la méthode crypt par défaut, nous voulons
utiliser la méthode MD5 plus sécurisée pour le
cryptage des mots de passe, qui autorise aussi une taille de
mot de passe de plus de huit caractères. Il est aussi
nécessaire de modifier l'emplacement obsolète /var/spool/mail
des boîtes de courrier
électronique des utilisateurs pour que Shadow utilise par
défaut le nouveau /var/mail
disponible maintenant. Ces deux points se réalisent en
modifiant le fichier de configuration adéquat tout en le
copiant à sa destination :
sed -e's@#MD5_CRYPT_ENAB.no@MD5_CRYPT_ENAB yes@' \ -e 's@/var/spool/mail@/var/mail@' \ etc/login.defs.linux > /etc/login.defs
Déplacez un programme au bon emplacement :
mv /usr/bin/passwd /bin
Déplacez les bibliothèques de Shadow dans des emplacements plus appropriés :
mv /lib/libshadow.*a /usr/lib rm /lib/libshadow.so ln -sf ../../lib/libshadow.so.0 /usr/lib/libshadow.so
L'option -D
du
programme useradd
requiert le
répertoire /etc/default
pour
fonctionner correctement :
mkdir /etc/default
Ce paquet contient des outils pour ajouter, modifier,
supprimer des utilisateurs et des groupes, initialiser et
changer leur mots de passe, et bien d'autres tâches
administratives. Pour une explication complète de ce que
signifie password
shadowing, jetez un œil dans le fichier
doc/HOWTO
à l'intérieur du
répertoire source. Il reste une chose à garder à l'esprit si
vous décidez d'utiliser le support de Shadow : les
programmes qui ont besoin de vérifier les mots de passe
(gestionnaires d'affichage, programmes FTP, démons pop3 et
ainsi de suite) ont besoin d'être compatible avec shadow,
c'est-à-dire qu'ils ont besoin d'être capables de fonctionner
avec des mots de passe shadow.
Pour activer les mots de passe shadow, lancez la commande suivante :
pwconv
Pour activer les mots de passe shadow pour les groupes, lancez :
grpconv
Sous des circonstances normales, vous n'avez pas encore créé de mots de passe. Néanmoins, si vous revenez plus tard dans cette section pour activer les mots de passe shadow, réinitialisez tous les mots de passe des utilisateurs actuels avec la commande passwd et les mots de passe des groupes avec la commande gpasswd.
Choisissez un mot de passe pour l'utilisateur root et configurez-le avec :
passwd root
Le paquet Sysklogd contient des programmes pour les messages de traces système comme ceux donnés par le noyau lorsque des événements inhabituels surviennent.
Sysklogd a quelques soucis avec la série 2.6 du noyau Linux. Corrigez-les en appliquant le correctif suivant :
patch -Np1 -i ../sysklogd-1.4.1-kernel_headers-1.patch
Il existe une condition particulière dans la logique de gestion des signaux et le script de démarrage sysklogd peut quelque fois en souffrir. Corrigez ce bogue en appliquant un autre correctif :
patch -Np1 -i ../sysklogd-1.4.1-signal-1.patch
Compilez le paquet :
make
Installez le paquet :
make install
Créez un nouveau fichier /etc/syslog.conf
en lançant ce qui
suit :
cat > /etc/syslog.conf << "EOF" # Begin /etc/syslog.conf auth,authpriv.* -/var/log/auth.log *.*;auth,authpriv.none -/var/log/sys.log daemon.* -/var/log/daemon.log kern.* -/var/log/kern.log mail.* -/var/log/mail.log user.* -/var/log/user.log *.emerg * # End /etc/syslog.conf EOF
Le paquet Sysvinit contient des programmes de contrôle du démarrage, de l'exécution et de l'arrêt de votre système.
Lorsque les niveaux d'exécution changent (par exemple, lors de l'arrêt du système), init envoit des signaux de fin aux processus qu'init a lui-même lancé et qui ne devraient plus s'exécuter dans le nouveau niveau d'exécution. En faisant ceci, init affiche des messages comme « Sending processes the TERM signal » (NdT : Envoi du signal TERM aux processus) ce qui semble impliquer qu'il envoie ce signal à tous les processus en cours d'exécution. Pour éviter cette mauvaise interprétation, modifiez les sources pour que ce message soit remplacé par « Sending processes started by init the TERM signal » (NdT : Envoi du signal TERM aux processus lancés par init) :
sed -i 's@Sending processes@& started by init@g' \ src/init.c
Compilez le paquet :
make -C src
Puis, installez le paquet :
make -C src install
Créez un nouveau fichier /etc/inittab
en lançant ce qui suit :
cat > /etc/inittab << "EOF" # Début /etc/inittab id:3:initdefault: si::sysinit:/etc/rc.d/init.d/rc sysinit l0:0:wait:/etc/rc.d/init.d/rc 0 l1:S1:wait:/etc/rc.d/init.d/rc 1 l2:2:wait:/etc/rc.d/init.d/rc 2 l3:3:wait:/etc/rc.d/init.d/rc 3 l4:4:wait:/etc/rc.d/init.d/rc 4 l5:5:wait:/etc/rc.d/init.d/rc 5 l6:6:wait:/etc/rc.d/init.d/rc 6 ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now su:S016:once:/sbin/sulogin 1:2345:respawn:/sbin/agetty -I '\033(K' tty1 9600 2:2345:respawn:/sbin/agetty -I '\033(K' tty2 9600 3:2345:respawn:/sbin/agetty -I '\033(K' tty3 9600 4:2345:respawn:/sbin/agetty -I '\033(K' tty4 9600 5:2345:respawn:/sbin/agetty -I '\033(K' tty5 9600 6:2345:respawn:/sbin/agetty -I '\033(K' tty6 9600 # Fin /etc/inittab EOF
L'option -I '\033(K'
indique à agetty d'envoyer cette séquence
d'échappement au terminal avant de faire quoi que ce soit
d'autres. Cette séquence d'échappement bascule l'ensemble de
caractères de la console sur un défini par l'utilisateur, qui
peut être modifié en exécutant le programme
setfont. L
script de démarrage console du paquet LFS-Bootscripts
appelle le programme setfont au lancement du système.
L'envoi de cette séquence d'échappement est nécessaire pour
les personnes utilisant des polices autres qu'ISO 8859-1 mais
n'a aucun effet sur les personnes de langue anglaise.
Le paquet Tar contient un programme d'archivage.
Tar a un bogue quand l'option -S
est utilisée avec des
fichiers de plus de 4 Go. Le correctif suivant corrige
proprement ce problème :
patch -Np1 -i ../tar-1.15.1-sparse_fix-1.patch
Préparez la compilation de Tar :
./configure --prefix=/usr --bindir=/bin --libexecdir=/usr/sbin
Compilez le paquet :
make
Pour tester les résultats, lancez : make check
.
Installez le paquet :
make install
Le paquet Udev contient des programmes pour créer dynamiquement des nœuds périphériques.
Compilez le paquet :
make udevdir=/dev
udevdir=/dev
Ceci indique à udev le répertoire où les nœuds seront créés.
Pour tester les résultats, lancez :make test
.
Installez le paquet :
make udevdir=/dev install
La configuration par défaut d'Udev est loin d'être idéale, donc installez les fichiers de configuration maintenant :
cp ../udev-config-3.rules /etc/udev/rules.d/25-lfs.rules
Exécutez les programme udevstart pour créer notre complément des nœuds de périphériques.
/sbin/udevstart
The Util-linux package contains miscellaneous utility programs. Among them are utilities for handling file systems, consoles, partitions, and messages.
Le paquet Util-linux contient différents outils. Parmi eux se trouvent des outils de gestion des systèmes de fichiers, de consoles, de partitions et des messages.
Le FHS recommande d'utiliser /var/lib/hwclock
au lieu de l'habituel
/etc
comme emplacement du
fichier adjtime
. Pour rendre
hwclock
compatible avec le FHS, lancez ce qui suit :
sed -i 's@etc/adjtime@var/lib/hwclock/adjtime@g' \ hwclock/hwclock.c mkdir -p /var/lib/hwclock
Util-linux échoue lors de sa compilation avec les nouvelles versions de Linux-Libc-Headers. Le correctif suivant corrige proprement ce problème :
patch -Np1 -i ../util-linux-2.12q-cramfs-1.patch
Préparez la compilation d'Util-linux :
./configure
Compilez le paquet :
make HAVE_KILL=yes HAVE_SLN=yes
Voici la signification des paramètres de make :
HAVE_KILL=yes
Ceci empêche le programme kill (déjà installé par Procps) d'être construit et installé de nouveau.
HAVE_SLN=yes
Ceci empêche le programme sln (un ln lié statiquement déjà installé par Glibc) d'être construit et installé de nouveau.
Ce paquetage ne vient pas avec une suite de tests.
Installez le paquetage et déplacez le binaire
logger dans
/bin
car il est nécessaire pour
le paquetage LFS-Bootscripts :
make HAVE_KILL=yes HAVE_SLN=yes install mv /usr/bin/logger /bin
La plupart des programmes et des bibliothèques sont compilés,
par défaut, en incluant les symboles de déboguage (avec
l'option -g
de
gcc). Ceci
signifie que, lors du déboguage d'un programme ou d'une
bibliothèque compilé avec les informations de déboguage, le
débogueur peut vous donner non seulement les adresses mémoire
mais aussi les noms des routines et variables.
Néanmoins, l'intégration de ces symboles de déboguage font grossir le programme ou la bibliothèque de façon significative. Ce qui suit est un exemple de l'espace occupé par ces symboles :
un binaire bash avec les symboles de déboguage : 1200 Ko
un binaire bash sans les symboles de déboguage : 480 Ko
les fichiers Glibc et GCC (/lib
et /usr/lib
) avec les symboles de
déboguage : 87 Mo
les fichiers Glibc et GCC sans les symboles de déboguage : 16 Mo
Les tailles peuvent varier suivant le compilateur et la bibliothèque C utilisés mais, lors d'une comparaison de programmes avec et sans symboles de déboguages, la différence sera généralement d'un facteur de deux à cinq.
Comme la plupart des gens n'utiliseront jamais un débogueur sur leur système, beaucoup d'espace disque peut être gagné en supprimant ces symboles. La prochaine section montre comment supprimer tous les symboles de déboguage des programmes et bibliothèques. Des informations supplémentaires sur l'optimisation du système sont disponibles sous forme d'astuce sur http://www.linuxfromscratch.org/hints/downloads/files/optimization.txt.
Si l'utilisateur initial n'est pas un développeur et ne pense pas faire de débogage sur les logiciels du système, la taille du système peut être diminué d'environ 200 Mo en supprimant les symboles de débogage contenus dans les binaires et dans les bibliothèques. Ceci ne pose pas de problème autre que le fait de ne plus pouvoir les déboguer.
La plupart des personnes qui utilisent la commande mentionnée ci-dessous ne rencontrent aucune difficulté. Néanmoins, il est facile de faire une erreur de saisie et rendre le nouveau système complètement inutilisable, donc avant d'exécuter la commande strip, il est recommandé de faire une sauvegarde de l'état actuel.
Avant d'exécuter la suppression de ces symboles, faites particulièrement attention qu'aucun des binaires concernés ne sont en cours d'exécution. Si vous n'êtes pas sûr que l'utilisateur est entré dans chroot avec la commande donnée dans la section intitulée « Entrer dans l'environnement chroot » quittez le chroot :
logout
Puis, retournez-y :
chroot $LFS /tools/bin/env -i \ HOME=/root TERM=$TERM PS1='\u:\w\$ ' \ PATH=/bin:/usr/bin:/sbin:/usr/sbin \ /tools/bin/bash --login
Maintenant, les binaires et les bibliothèques peuvent être traitées en toute sécurité :
/tools/bin/find /{,usr/}{bin,lib,sbin} -type f \ -exec /tools/bin/strip --strip-debug '{}' ';'
Un grand nombre de fichiers seront rapportés comme ayant un format non reconnu. Ces messages d'avertissement indiquent que ces fichiers sont des scripts et non pas des binaires.
SI l'espace disque devient très restreint, l'option --strip-all
peut être utilisée
sur les binaires compris dans /{,usr/}{bin,sbin}
pour gagner quelques
mégaoctets de plus. N'utilisez pas cette option sur les
bibliothèques —cela les détruirait.
À partir de maintenant, en rentrant dans l'environnement chroot après l'avoir quitté, utilisez la commande chroot suivante :
chroot "$LFS" /usr/bin/env -i \ HOME=/root TERM="$TERM" PS1='\u:\w\$ ' \ PATH=/bin:/usr/bin:/sbin:/usr/sbin \ /bin/bash --login
La raison en est que les programmes dans /tools
ne sont plus nécessaires. Comme ils ne
sont plus nécessaires, vous pouvez supprimer le répertoire
/tools
si vous le voulez ou
l'archiver dans un fichier tar et le conserver pour construire
un autre système.
Supprimer /tools
effacera
aussi les copies temporaires de Tcl, Expect and DejaGnu,
qui ont été utilisé pour lancer les tests de l'ensemble des
outils. Si vous avez besoin de ces programmes plus tard,
vous devrez les recompiler et les ré-installer. Le livre
BLFS a les bonnes instructions pour le faire.
Ce chapitre montre comment installer et configurer les scripts de démarrage LFS. La plupart de ces scripts fonctionne sans modification mais quelques-uns nécessitent des fichiers de configuration supplémentaires car ils utilisent des informations dépendant du matériel.
Les scripts de démarrage compatibles System-V sont utilisés dans ce livre simplement parce qu'ils sont largement utilisés. Pour d'autres options, une astuce détaillant les scripts compatibles BSD est disponible sur http://www.linuxfromscratch.org/hints/downloads/files/bsd-init.txt. Rechercher dans les listes de diffusion LFS vous offrira aussi d'autres choix.
Si vous utilisez un autre style de scripts de démarrage, passez ce chapitre et allez directement sur le Chapitre 8.
Le paquet LFS-Bootscripts contient un ensemble de scripts de démarrage pour démarrer/arrêter le système LFS.
Linux utilise un service de démarrage spécial nommé SysVinit qui est basé sur un concept de niveaux d'exécution. Cela peut être bien différent d'un système à un autre, du coup, il ne peut pas être supposé que, parce que cela fonctionne dans une distribution Linux particulière, cela fonctionnera de la même façon dans LFS. LFS a sa propre façon de le faire mais il respecte généralement les standards établis.
SysVinit (qui sera nommé par la suite « init ») fonctionne en utilisant un schéma
de niveaux d'exécution. Ils sont au nombre de sept (numérotés
de 0 à 6). En fait, il en existe plus mais ils sont pour des
cas spéciaux et ne sont généralement pas utilisés. Voir
init(8)
pour plus de détails.
Chacun d'entre eux correspond à des actions que l'ordinateur
est supposé effectuer lorsqu'il démarre. Le niveau d'exécution
par défaut est 3. Voici les descriptions sur l'implémentation
des différents niveaux d'exécution :
0: arrête l'ordinateur
1: mode simple utilisateur
2: mode multi-utilisateur sans réseau
3: mode multi-utilisateur avec réseau
4: réservé pour la personnalisation, sinon identique à 3
5: identique à 4, il est habituellement utilisé pour la connexion GUI (comme
xdm de X ou kdm de KDE)
6: redémarre l'ordinateur
La commande utilisée pour modifier le niveau d'exécution est
init [niveau_exécution]
,
où [niveau_exécution]
est le niveau d'exécution cible. Par exemple, pour redémarrer
l'ordinateur, un utilisateur devra lancer la commande
init 6 qui est un
alias de la commande reboot. De la même façon,
init 0 est un
alias de la commande halt.
Il existe un certain nombre de répertoires sous /etc/rc.d
qui ressemble à rc?.d
(où ? est le numéro du niveau
d'exécution) et rcsysinit.d
, tous
contenant un certain nombre de liens symboliques. Certains
commencent avec un K,
les autres avec un S, et
tous ont deux nombres après la lettre initiale. Le K signifie
l'arrêt (kill) d'un service et le S son lancement (start). Les
nombres déterminent l'ordre dans lequel les scripts sont
exécutés, de 00 à 99—plus ce nombre est petit, plus tôt
le script correspondant sera exécuté. Quand init bascule sur un
autre niveau d'exécution, les services appropriés sont soit
lancés soit tués, suivant le niveau d'exécution choisi.
Les vrais scripts sont dans /etc/rc.d/init.d
. Ils font le vrai boulot et
les liens symboliques pointent tous vers eux. Les liens d'arrêt
et de lancement pointent vers le même script dans /etc/rc.d/init.d
. Ceci est dû au fait que les
scripts peuvent être appelés avec différents paramètres comme
start
, stop
, restart
, reload
et status
. Quand un lien K est
rencontré, le script approprié est lancé avec l'argument
stop
. Quand un lien S
est rencontré, le script approprié est lancé avec l'argument
start
argument.
Il existe une exception à cette explication. Les liens
commençant avec un S
dans les répertoires rc0.d
et
rc6.d
ne lanceront aucun service.
Ils seront appelés avec l'argument stop
pour arrêter quelque chose.
La logique derrière ceci est que, quand un utilisateur va
redémarrer ou arrêter le système, rien ne doit être lancé. Le
système a seulement besoin d'être stoppé.
Voici des descriptions de ce que font les arguments des scripts :
start
Le service est lancé.
stop
Le service est stoppé.
restart
Le service est stoppé puis de nouveau lancé.
reload
La configuration du service est mise à jour. Ceci est utilisé apr_s que le fichier de configuration d'un service a été modifié, quand le service n'a pas besoin d'être redémarré.
status
Indique si le service est en cours d'exécution ainsi que les PID associés.
Vous êtes libre de modifier la façon dont le processus de démarrage fonctionne (après tout, c'est votre système LFS). Les fichiers donnés ici sont un exemple d'une façon de faire.
Dans Chapter 6, nous avons installé le paquet Udev. Avant d'aller dans les détails concernant son fonctionnement, un bref historique des méthodes précédentes de gestion des périphériques est nécessaire.
Les systèmes Linux en général utilisent traditionellement une
méthode de création de périphériques statiques avec laquelle un
grand nombre de nœuds périphériques est créé sous
/dev
(quelque fois des milliers
de nœuds ), quel le matériel correspondant existe ou pas.
Ceci se fait typiquement avec un script MAKEDEV, qui contient des appels au
programme mknod
avec les numéros de périphériques majeurs et mineurs pour
chaque périphérique possible qui pourrait exister dans le
monde. En utilisant la méthode udev, seuls les périphériques
détectés par le noyau obtiennent des nœuds périphériques
créés pour eux. Comme ces nœuds périphériques seront
créés à chaque lancement du système, ils seront stockés dans un
tmpfs
(un système de fichiers
qui réside entièrement en mémoire). Les nœuds
périphériques ne requièrent pas beaucoup d'espace disque, donc
la mémoire utilisée est négligable.
En février 2000, un nouveau système de fichiers appelé
devfs
a été intégré au noyau
2.3.46 et rendu disponible pour la série 2.4 des noyaux
stables. Bien qu'il soit présent dans le source du noyau,
cette méthode de création dynamique de périphérique n'a
jamais reçu un support inconditionnel des développeurs du
noyau.
Le principal problème de l'approche adopté par devfs
était la façon dont il gérait la
détection, la création et le nommage des périphériques. Ce
dernier problème, le nommage des périphériques, était
peut-être le plus critique. Il est généralement accepté que
s'il est possible de configurer les noms des périphériques,
alors la politique de nommage des périphériques revient à
l'administrateur du système, et du coup n'est pas imposée par
un développeur particulier. Le système de fichiers
devfs
souffre aussi de
conditions particulières inhérentes à son concept et ne peut
pas être corrigé sans une revue importante du noyau. Il a
aussi été marqué comme obsolète à cause d'un manque de
maintenance.
Avec le développement du noyau instable 2.5, sorti ensuite en
tant que la série 2.6 des noyaux stables, un nouveau système
de fichiers virtuel appelé sysfs
est arrivé. Le travail de
sysfs
est d'exporter une vue
de la configuration matérielle du système pour les processus
en espace utilisateur. Avec cette représentation visible de
l'espace utilisateur, la possibilité de voir une remplacement
de l'espace utilisateur pour devfs
est devenu beaucoup plus réaliste.
Le système de fichiers sysfs
a été brièvement mentionné ci-dessus. On pourrait se demander
comment sysfs
connait les
périphériques présents sur un système et quels numéros de
périphériques devraient être utilisés. Les pilotes qui ont
été compilés directement dans le noyau enregistrent leur
objet avec sysfs
quand ils
sont détectés par le noyau. Pour les pilotes compilés en tant
que modules, cet enregistrement surviendra quand le module
sera chargé. Une fois que le système de fichiers sysfs
est monté (sur /sys
), les données enregistrées par les
pilotes internes avec sysfs
sont disponibles pour les processus en espace utilisateur
ainsi qu'à udev
pour la création des nœuds périphériques.
Le script de démarrage S10udev fait attention à créer les
nœuds périphériques au lancement de Linux. Ce script
commence en enregistrant /sbin/udevsend comme gestionnaire
d'événements de montage à chaud. Ces événements (discutés
plus bas) ne sont généralement pas générés lors de cette
étape mais udev
est enregistré juste au cas où cela se passerait quand même.
Le programme udevstart parcourt le système de
fichiers /sys
et crée les
périphériques sous /dev
correspondant à ces descriptions. Par exemple, /sys/class/tty/vcs/dev
contient la chaîne
« 7:0 ». Cette chaîne
est utilisée par udevstart pour créer /dev/vcs
avec le nombre majeur 7 et le nombre mineur 0. Les noms et droits des
nœuds créés sous le répertoire /dev
sont configurés suivant les règles
spécifiées dans les fichiers du répertoire /etc/udev/rules.d/
. Ils sont numérotés
d'une façon similaire au paquetage LFS-Bootscripts. Si
udev ne peut as
trouver une règle pour le périphérique en cours de création,
celui-ci aura les droits par défaut (660) et son propriétaire sera
root:root.
Une fois l'étape ci-dessus terminée, tous les périphériques qui étaient déjà présents et ont des pilotes intégrés au noyau seront disponibles pour utilisation. Ceci nous amène aux périphériques qui ont des pilotes sous forme de modules.
Plus tôt, nous avons mentionné le concept d'un
« gestionnaire d'événements de
montage à chaud ». Quand la connexion d'un
nouveau périphérique est détectée par le noyau, le noyau
génèrera un événement de montage à chaud et regardera dans le
fichier /proc/sys/kernel/hotplug
pour trouver le
programme en espace utilisateur qui gère la connexion du
périphérique. Le script de démarrage udev a enregistré
udevsend comme
gestionnaire. Quand ces événements sont générés, le noyau
indiquera à udev de vérifier le système de
fichiers /sys
pour des
informations sur le nouveau périphérique et pour créer son
entrée /dev
.
Ceci nous amène au problème d'udev, mais aussi avec devfs
. Il est habituellement référencé
comme le « problème de l'oelig;uf et
de la poule ». La plupart des distributions Linux
gère le chargement des modules via des entrées dans
/etc/modules.conf
. L'accès à un
nœud périphérique implique le chargement du module du
noyau. Avec udev, cette méthode ne fonctionnera
pas car le nœud périphérique n'existe pas tant que le
module n'est pas chargé. Pour résoudre ceci, le script de
démarrage S05modules a été ajouté au paquet
lfs-bootscripts, avec le fichier /etc/sysconfig/modules
. En ajoutant les
noms de modules au fichier modules
, ces modules seront chargés lorsque
l'ordinateur démarrera. Ceci permet à udev de détecter les périphériques
et de créer les nœuds périphériques appropriés.
Notez que sur les machines lentes ou pour les pilotes qui créent un grand nombre de nœuds périphériques, le processus de création des périphériques pourrait prendre quelques secondes pour se terminer. Ceci signifie que certains nœuds périphériques pourraient ne pas être accessibles immédiatement.
Lorsque vous connectez un périphérique, comme un lecteur MP3
USB, le noyau reconnaît que le périphérique est maintenant
connecté et génère un événement de montage à chaud. Si le
pilote a déjà été chargé (soit parce qu'il était compilé dans
le noyau soit parce qu'il a été chargé via le script de
démarrage S05modules), udev sera appelé pour créer le(s)
nœud(s) périphérique correspondant suivant les données
de sysfs
disponibles dans
/sys
.
Si le pilote du périphérique tout juste connecté est disponible comme module mais actuellement non chargé, le paquetage Hotplug chargera les modules appropriés et rendra ce périphérique disponible en créant le(s) nœud(s) périphérique(s) qui le concernent.
Il existe quelques problèmes connus pour la création automatique des nœuds périphériques :
1) Un pilote du noyau pourrait ne pas exporter ses données
dans sysfs
.
Ceci est plus fréquent avec les pilotes de tierces parties, à
l'extérieur du noyau. Udev ne sera pas capable de créer
automatiquement les nœuds périphériques pour de tels
pilotes. Utilisez le fichier de configuration /etc/sysconfig/createfiles
pour créer
manuellement les périphériques. Consultez le fichier
devices.txt
dans la
documentation du noyau ou la documentation pour trouver les
bons numéros majeurs et mineurs pour ce périphérique.
2) Un périphérique non matériel est requis. Ceci est plus fréquent avec le module de compatibilité OSS (acronyme de Open Sound System) du projet ALSA (Advanced Linux Sound Architecture). Ces types de périphériques peuvent être gérés de deux façons différentes :
Ajouter les noms des modules à /etc/sysconfig/modules
Utiliser une ligne « install » dans /etc/modprobe.conf
. Ceci indique à la
commande modprobe « au chargement du module, de charger aussi cet
autre module, au même moment. » Par
exemple :
install snd-pcm modprobe -i snd-pcm ; modprobe \ snd-pcm-oss ; true
Ceci fera que le système charge à la fois les modules snd-pcm et snd-pcm-oss quand toute requête est faite pour charger le pilote snd-pcm.
Des documentations supplémentaires sont disponibles sur les sites suivants :
A Userspace Implementation of devfs
http://www.kroah.com/linux/talks/ols_2003_udev_paper/Reprint-Kroah-Hartman-OLS2003.pdf
(NdT : Une implémentation en espace utilisateur de
devfs)
FAQ udev http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev-FAQ
The Linux Kernel Driver Model http://public.planetmirror.com/pub/lca/2003/proceedings/papers/Patrick_Mochel/Patrick_Mochel.pdf (NdT : Le modèle du pilote pour le noyau Linux)
Le script setclock lit le temps sur l'horloge
matérielle, aussi connu sous le nom d'horloge BIOS or CMOS
(Complementary Metal Oxide Semiconductor). Si l'horloge
matérielle est configurée en UTC, le script convertira le temps
de l'horloge matérielle en temps local en utilisant le fichier
/etc/localtime
(indiquant au
programme hwclock
le fuseau horaire où se situe l'utilisateur. Il n'existe pas de
moyens de détecter si l'horloge matérielle est configurée en
UTC, donc elle doit être configurée manuellement.
Si vous ne vous rappeler pas si l'horloge matérielle est
configurée en UTC, découvrez-le en exécutant hwclock --localtime --show
.
Ceci affichera l'heure courante suivant l'horloge matérielle.
Si l'heure correspond à ce qui vous dit votre montre, alors
l'horloge matérielle est configurée sur l'heure locale. Si la
sortie de hwclock
n'est pas l'heure locale, il y a des chances qu'elle soit
configurée en UTC. Vérifiez ceci en ajoutant ou en soustrayant
le bon nombre d'heures pour votre fuseau horaire à l'heure
affichée par hwclock. Par exemple, si vous être
actuellement dans le fuseau horaire MST, aussi connu en tant
que GMT -0700, ajoutez sept heures à l'heure locale.
Modifiez la valeur de la variable UTC
ci-dessous par une valeur 0
(zéro) si l'horloge matérielle
n'est pas configurée en
temps UTC.
Créez un nouveau fichier /etc/sysconfig/clock
en lançant ce qui
suit :
cat > /etc/sysconfig/clock << "EOF" # Début /etc/sysconfig/clock UTC=1 # Fin /etc/sysconfig/clock EOF
Une bonne astuce expliquant comment gérer l'horloge sur LFS est
disponible sur
http://www.linuxfromscratch.org/hints/downloads/files/time.txt.
Il explique certains concepts comme les fuseaux horaires, UTC
et la variable d'environnement TZ
.
Cette section discute de la configuration du script de démarrage console, initialisant le plan de codage du clavier et la police de la console. Si des caractères non ASCII (par exemple, la livre anglaise et le caractère Euro) ne seront pas utilisés et que le clavier est un clavier US, passez cette section. Sans le fichier de configuration, le script de démarrage console ne fera rien.
Le script console
lit le fichier /etc/sysconfig/console
pour des informations
de configuration. Il décide du plan de codage et de la police
de la console à utiliser. Différents guides pratiques
spécifiques aux langues peuvent aussi être d'une grande aide
(voir http://www.tldp.org/HOWTO/HOWTO-index/other-lang.html).
Un fichier /etc/sysconfig/console
déjà rempli avec des paramètrages déjà connus pour différents
pays a été installé avec la paquet LFS-Bootscripts, pour que la
section adéquate puisse être décommentée si le pays est
supporté. Si vous avez toujours des doutes, jetez un œil
dans le répertoire /usr/share/kbd
pour des plans de codage valides et des polices pour écran.
Lisez les pages man de loadkeys(1)
et setfont(8)
pour déterminer les bons arguments
pour ces programmes. Une fois décidé, créez le fichier de
configuration avec les commandes suivantes :
cat >/etc/sysconfig/console <<"EOF" KEYMAP="[arguments pour loadkeys]" FONT="[arguments pour setfont]" EOF
Par exemple, pour les utilisateurs espagnols qui souhaitent aussi utiliser le caractère Euro (accessible avec la combinaison de touches AltGr+E), les paramètrages suivants sont corrects :
cat >/etc/sysconfig/console <<"EOF" KEYMAP="es euro2" FONT="lat9-16 -u iso01" EOF
La ligne FONT
ci-dessus est
correct seulement pour l'ensemble de caractères ISO
8859-15. Si vous utilisez ISO 8859-1 et, du coup, un
symbole de livre à la place de l'Euro, la ligne
FONT
correcte devrait
être :
FONT="lat1-16"
Si la variable KEYMAP
ou
FONT
n'est pas configurée, le script
de démarrage console n'exécutera pas le programme
correspondant.
Dans certains plans de codage, les touches Backspace et Delete envoient des caractères différents de ceux du plan de codage par défaut intégré au noyau. Ceci est une source de confusion pour certaines applications. Par exemple, Emacs affiche son aide (au lieu de supprimer le caractère situé avant le curseur) lors d'un appui sur Backspace. Pour vérifier si le plan de codage utilisé est pris en compte (ceci ne fonctionne qu'avec les plans de codage i386) :
zgrep '\W14\W' [/path/to/your/keymap]
Si le code de touche 14 est Backspace au lieu de Delete, créez le code supplémentaire suivant au plan de codage pour corriger ce problème :
mkdir -p /etc/kbd && cat > /etc/kbd/bs-sends-del <<"EOF" keycode 14 = Delete Delete Delete Delete alt keycode 14 = Meta_Delete altgr alt keycode 14 = Meta_Delete keycode 111 = Remove altgr control keycode 111 = Boot control alt keycode 111 = Boot altgr control alt keycode 111 = Boot EOF
Indiquez au script console de charger ce code après le plan de codage principal :
cat >>/etc/sysconfig/console <<"EOF" KEYMAP_CORRECTIONS="/etc/kbd/bs-sends-del" EOF
Pour compiler le plan de codage directement dans le noyau au
lieu de le configurer à chaque fois avec le script de démarrage
console, suivez
les instructions données dans la section intitulée
« Linux-2.6.11.12 ». Le faire vous assure que le
plan de codage fonctionnera toujours comme attendu, même si
vous démarrez en mode maintenance (en passant init=/bin/sh
au noyau), parce que
le script de démarrage console ne sera pas lancé dans cette
situation. De plus, le noyau ne configurera plus la police de
l'écran automatiquement. Ceci ne devrait pas poser beaucoup de
problèmes car les caractères ASCII seront gérés correctement et
il est improbable qu'un utilisateur aura besoin de caractères
non ASCII en mode maintenance.
Comme le noyau configurera le plan de codage, il est possible
d'omettre la variable KEYMAP
à
partir du fichier de configuration /etc/sysconfig/console
. Il peut aussi aussi
être laissé à sa place, si désiré, sans conséquence. Le garder
pourrait être bénéfique si vous utilisez différents noyaux et
qu'il est difficile d'être sûr que le plan de codage est bien
compilé dans chacun d'entre eux.
Le script sysklogd
invoque le
programme syslogd
avec l'option -m
. Cette
option désactive la marque périodique que syslogd écrit sur les
journaux système toutes les vingt minutes par défaut. Si vous
voulez l'activer, éditez le script sysklogd et faites les changements
adéquats. Voir la page de manuel man syslogd
pour plus
d'informations.
Le fichier inputrc
gère les
fichiers de correspondance du clavier pour les situations
spécifiques. Ce fichier est le fichier de démarrage utilisé par
Readline — la bibliothèque relative aux entrées —
utilisée par Bash et la plupart des autres shells.
La plupart des personnes n'ont pas besoin de fichiers de
correspondance spécifiques, donc la commande ci-dessous crée un
fichier /etc/inputrc
utilisé par
tous ceux qui se connectent. Si vous décidez plus tard que vous
avez besoin de surcharger les valeurs par défaut utilisateur
par utilisateur, vous pouvez créer un fichier .inputrc
dans le répertoire personnel de
l'utilisateur avec les correspondances modifiées.
Pour plus d'informations sur l'édition du fichier inputrc
, voir la section Readline Init File dans
info bash.
info readline est
aussi une bonne source d'informations.
Ci-dessous se trouve un fichier inputrc
générique avec des commentaires
expliquant l'utilité des différentes options. Notez que les
commentaires ne peuvent pas être sur la même ligne que les
commandes. Créez le fichier en utilisant la commande
suivante :
cat > /etc/inputrc << "EOF" # Début /etc/inputrc # Modifié par Chris Lynn <roryo@roryo.dynup.net> # Autorise l'invite de commande de passer à la ligne suivant set horizontal-scroll-mode Off # Active la saisie 8bit set meta-flag On set input-meta On # Désactive la suppression du 8ème bit set convert-meta Off # Conserve le 8ème bit pour l'affichage set output-meta On # aucun, visible ou audible set bell-style none # Tout ce qui suit fait correspondre la séquence d'échappement de la valeur # contenue à l'intérieur du premier argument aux fonctions spécifiques de # readline "\eOd": backward-word "\eOc": forward-word # pour la console linux "\e[1~": beginning-of-line "\e[4~": end-of-line "\e[5~": beginning-of-history "\e[6~": end-of-history "\e[3~": delete-char "\e[2~": quoted-insert # pour les xterm "\eOH": beginning-of-line "\eOF": end-of-line # pour Konsole "\e[H": beginning-of-line "\e[F": end-of-line # Fin /etc/inputrc EOF
Le programme shell /bin/bash (dénommé ci-après
« le shell ») utilise une
collection de fichiers de démarrage pour aider à la création
d'un environnement d'exécution. Chaque fichier a une
utilisation spécifique et pourrait avoir des effets différents
sur les environnements de connexion et interactif. Les fichiers
du répertoire /etc
fournissent un
paramètrage global. Si un fichier équivalent existe dans le
répertoire personnel, il pourrait surcharger les paramètrages
globaux.
Un shell interactif de connexion est lancé après une connexion
réussie, en utilisant /bin/login, par la lecture du fichier
/etc/passwd
. Un shell interactif
sans connexion est lancé en ligne de commande (c'est-à-dire
[invite]$
/bin/bash). Un shell non interactif
est habituellement présent quand un script shell est en cours
d'exécution. Il est non interactif parce qu'il traite un script
et n'attend pas une saisie de l'utilisateur entre les
commandes.
Pour plus d'informations, voir info bash sous la section Bash Startup Files and Interactive Shells.
Les fichiers /etc/profile
et
~/.bash_profile
sont lus quand le
shell est appelé en tant que shell interactif de connexion.
Le fichier /etc/profile
de base,
ci-dessous, configure quelques variables d'environnement
nécessaire au support des langues natives. Les configurer
proprement résulte en ce qui suit :
La sortie des programmes traduite dans le langage natif
Correction de la classification des caractères en lettres, chiffres et autres classes. Ceci est nécessaire pour que bash accepte proprement les caractères non ASCII dans les lignes de commandes pour les locales autres qu'anglais
L'ordre de tri alphabetique correct pour le pays
Taille de papier par défaut appropriée
Bon formatage des valeurs monétaires, de l'heure et des dates
Ce script configure aussi la variable d'environnement
INPUTRC
qui fait que Bash et Readline utilisent le fichier /etc/inputrc
créé précédemment.
Remplacez [ll]
ci-dessous avec le code à deux lettres de la langue désirée
(par exemple, « en ») et
[CC]
avec le code à
deux lettres du pays approprié (par exemple,
« GB »). [charmap]
devra être remplacé
avec le charmap canonique de votre locale.
La liste de toutes les locales supportées par Glibc peut être obtenue en exécutant la commande suivante :
locale -a
Les locales peuvent avoir plusieurs synonymes. Par exemple,
« ISO-8859-1 » est aussi
appelée « iso8859-1 » et
« iso88591 ». Quelques
applications ne peuvent pas gérer les différents synonymes
correctement, donc il est plus sûr de choisir le nom canonique
pour une locale particulière. Pour déterminer le nom canonique,
lancez la commande suivante, où [nom locale]
est l'affichage
donnée par locale
-a pour votre locale préférée
(« en_GB.iso88591 » dans
notre exemple).
LC_ALL=[nom locale] locale charmap
Pour la locale « en_GB.iso88591 », la commande ci-dessus affichera :
ISO-8859-1
Ceci résulte en un paramètrage final de locale avec « en_GB.ISO-8859-1 ».
Une fois que les bons paramètres de locale ont été déterminés,
créez le fichier /etc/profile
:
cat > /etc/profile << "EOF" # Début /etc/profile export LANG=[ll]_[CC].[charmap] export INPUTRC=/etc/inputrc # Fin /etc/profile EOF
Les locales « C » (par défaut) et « en_US » (celle recommandée pour les utilisateurs de langue anglaise vivant aux États-Unis) sont différentes.
Initialiser le plan de codage du clavier, la police de la console et les variables d'environnement relatives à la locale sont les seules étapes d'internationalisation nécessaires pour supporter les locales qui utilisent habituellement les codages à un seul octet et la direction d'écriture de la gauche vers la droite. Les cas plus complexes (incluant les locales basées sur UTF-8) nécessitent des étapes et des correctifs supplémentaires parce qu'un grand nombre d'applications ont tendance à ne pas fonctionner corrctement dans de telles conditions. Ces étapes et correctifs ne sont pas inclus dans le livre LFS et de telles locales ne sont pas supportées par LFS.
Une partie du boulot de ce script est de configurer le nom du
système. Ce nom doit être indiqué dans le fichier /etc/sysconfig/network
.
Créez le fichier /etc/sysconfig/network
et entrez le nom du
système en lançant :
echo "HOSTNAME=[lfs]" > \ /etc/sysconfig/network
[lfs]
doit être
remplacé par le nom de l'ordinateur. Ne saisissez pas le FQDN
(Fully Qualified Domain Name, nom de domaine pleinement
qualifié) ici. Cette information sera rentrée dans le fichier
/etc/hosts
dans la prochaine
section.
Si une carte réseau doit être configurée, choisissez l'adresse
IP, le nom de domaine pleinement qualifié et les alias
possibles à déclarer dans le fichier /etc/hosts
. La syntaxe est la suivante :
<adresse IP> mon-hôte.mon-domaine.org aliases
À moins que votre ordinateur ne doit être visible à partir d'Internet (c'est-à-dire que vous avez enregistré un domaine et un bloc valide d'adresses IP qui vous est affecté, la plupart des utilisateurs n'a pas ceci), vous devez vous assurer que l'adresse IP se trouve dans la plage d'adresses réservée aux réseaux privés. Les plages valides sont :
Classes Réseaux A 10.0.0.0 B 172.16.0.0 à 172.31.0.255 C 192.168.0.0 à 192.168.255.255
Une adresse IP valide pourrait être 192.168.1.1. Un nom de domaine pleinement qualifié pour cette adresse IP pourrait être www.linuxfromscratch.org (ceci n'est pas recommandé car il s'agit d'un nom de domaine valide enregistré et que cela pourrait causer des problèmes à votre serveur).
Même si vous ne possédez pas de carte réseau, un nom de domaine pleinement qualifié est toujours requis. Certains programmes en ont besoin pour fonctionner correctement.
Créez le fichier /etc/hosts
en
lançant la commande :
cat > /etc/hosts << "EOF" # Début de /etc/hosts (version avec carte réseau) 127.0.0.1 localhost [192.168.1.1] [<nom d'hôte>.exemple.org] [nom d'hôte] # Fin de /etc/hosts (version avec carte réseau) EOF
Les valeurs [192.168.1.1]
et [<nom
d'hôte>.exemple.org]
doivent être remplacées
suivant les contraintes/besoins des utilisateurs (si la machine
se voit affectée une adresse IP par un administrateur
réseau/système et que cette machine est connectée à un réseau
existant).
Si vous n'avez pas de carte réseau, créez le fichier
/etc/hosts
en lançant la
commande :
cat > /etc/hosts << "EOF" # Début /etc/hosts (version sans carte réseau) 127.0.0.1 [<nom d'hôte>.exemple.org] [nom d'hôte] localhost # Fin /etc/hosts (version sans carte réseau) EOF
Cette section s'applique seulement si une carte réseau doit être configurée.
Si une carte réseau ne sera pas utilisée, il n'y a aucun besoin
de créer des fichiers de configuration relatifs aux cartes
réseau. Si c'est le cas, supprimez les liens symboliques
network
de tous les répertoires
des niveaux d'exécution (/etc/rc.d/rc*.d
).
Les interfaces activées et désactivées par le script network
dépendent des fichiers et des répertoires compris dans le
répertoire /etc/sysconfig/network-devices
. Ce
répertoire doit contenir un sous-répertoire pour chaque
interface à configurer, comme ifconfig.xyz
, avec « xyz » le nom de l'interface réseau. Dans
ce répertoire se trouvent des fichiers définissant les
attributs de cette interface, comme le(s) adresse(s) IP,
masque de sous-réseau et ainsi de suite.
La commande suivante crée un fichier ipv4
d'exemple pour le périphérique
eth0 :
Les nouveaux fichiers sont créés dans ce répertoire. La
commande suivan te crée un fichier d'exemple ipv4
pour le périphérique eth0 :
cd /etc/sysconfig/network-devices && mkdir ifconfig.eth0 && cat > ifconfig.eth0/ipv4 << "EOF" ONBOOT=yes SERVICE=ipv4-static IP=192.168.1.1 GATEWAY=192.168.1.2 PREFIX=24 BROADCAST=192.168.1.255 EOF
Les valeurs de ces variables doivent être modifiées dans
chaque fichier pour correspondre à la bonne configuration. Si
la variable ONBOOT
est configurée
à « yes », le script
network configurera la carte réseau (NIC) pendant le
démarrage du système. S'il est configuré avec toute auter
valeur que « yes »,
l'interface réseau sera ignorée par le script network et non
montée.
La variable SERVICE
définit la
méthode utilisée pour obtenir une adresse IP. Les scripts de
démarrage LFS ont un format d'affectation IP modulaire. Créer
les fichier supplémentaires dans le répertoire /etc/sysconfig/network-devices/services
autorise d'autres méthodes d'affectation. Ceci est
habituellement utilisé pour le DHCP, qui est adressé dans le
livre BLFS.
La variable GATEWAY
devrait
contenir l'adresse IP par défaut de la passerelle, si elle
existe. Sinon, mettez entièrement en commentaire la variable.
La variable PREFIX
a besoin de
contenir le nombre de bits utilisé dans le sous-réseau.
Chaque octet dans une adresse IP est sur huit bits. Si le
masque réseau du sous-réseau est 255.255.255.0, alors il est
en train d'utiliser les trois premiers octets (24 bits) pour
spécifier le numéro réseau number. Si le masque réseau est is
255.255.255.240, il utiliserait les 128 premiers bits. Les
préfixes plus longs que 24 bits sont habituellement u tilisés
par les fournisseurs d'accès à Internet DSL et cable. Dans
cet exemple (PREFIX=24), le masque réseau est 255.255.255.0.
Ajustez la variable PREFIX
en
concordance avec votre sous-réseau spécifique.
Si le système a besoin d'être connecté à Internet, il aura
besoin de la résolution de noms proposée par le DNS (Domain
Name Service) pour résoudre les noms de domaines Internet, et
vice-versa. Ceci se fait en plaçant les adresses IP du
serveur DNS, disponibles auprès du FAI ou de l'administrateur
système, dans /etc/resolv.conf
.
Créez le fichier en lançant ce qui suit :
cat > /etc/resolv.conf << "EOF" # Début /etc/resolv.conf domain {[Votre nom de domaine]} nameserver [adresse IP de votre DNS principal] nameserver [adresse IP de votre DNS secondaire] # Fin /etc/resolv.conf EOF
Remplacez [adresse IP du
DNS]
avec l'adresse IP du DNS le plus approprié
pour la configuration. Il y aura souvent plus d'une entrée
(les conseils recommandent des serveurs DNS disposant de
capacité de prise en charge. Si vous avez seulement besoin ou
si vous voulez uniquement le serveur DNS, supprimez la
seconde ligne serveur de
noms à partir du fichier. L'adresse IP pourrait
aussi être un routeur sur le réseau local.
Bien joué ! Le nouveau système LFS est installé. Nous vous souhaitons de bien vous amuser avec votre nouveau système Linux rutilant.
Une bonne idée serait de créer un fichier /etc/lfs-release
. Avec ce fichier, il vous
est très facile (ainsi que pour nous si vous avez besoin de
demander de l'aide) de savoir quelle version de LFS vous avez
installé sur votre système. Créez ce fichier en lançant :
echo 6.1 > /etc/lfs-release
Maintenant que vous avez terminé le livre, voulez-vous être enregistré comme utilisateur de LFS ? Allez directement sur http://www.linuxfromscratch.org/cgi-bin/lfscounter.cgi et enregistrez-vous comme utilisateur LFS en entrant votre nom et la première version de LFS que vous ayez utilisée.
Replongeons-nous maintenant dans LFS.
Maintenant que tous les logiciels ont été installés, il est temps de redémarrer votre ordinateur. Néanmoins, vous devez savoir certaines choses. Le système que vous avez créé dans ce livre est vraiment minimal et a toutes les chances de ne pas avoir les fonctionnalités dont vous aurez besoin pour continuer. En installant quelques autres paquetages à partir du livre BLFS en restant dans l'environnement chroot actuel, vous serez dans une bien meilleure position pour continuer une fois que vous aurez redémarré votre nouvelle installation LFS. Installer un navigateur web en mode texte, comme Lynx, vous permettra de lire facilement le livre BLFS dans un terminal virtuel tout en construisant des paquetages dans un autre. Le paquetage GPM vous permettra aussi de réaliser des actions de copier/coller dans vos terminaux virtuels. Enfin, si vous êtes dans une situation où la configuration IP statique ne correspond pas à vos besoins en terme de réseau, installer des paquetages comme Dhcpcd ou PPP pourrait aussi être utile.
Maintenant que nous vous avons prévenu, démarrons notre toute nouvelle installation LFS pour la première fois ! Tout d'abord, quittez l'environnement chroot :
logout
Puis, démontez les systèmes de fichiers virtuels :
umount $LFS/dev/pts umount $LFS/dev/shm umount $LFS/dev umount $LFS/proc umount $LFS/sys
Démontez le système de fichiers LFS :
umount $LFS
Si plusieurs partitions ont été créées, démontez les autres partitions avant de démonter la principale, comme ceci :
umount $LFS/usr umount $LFS/home umount $LFS
Maintenant, redémarrez le système avec :
shutdown -r now
En supposant que le chargeur de démarrage Grub a été initialisé comme indiqué plus tôt, le menu est préparé pour démarrer LFS 6.1 automatiquement.
À la fin du redémarrage, le système LFS est prêt à être utilisé et des logiciels peuvent enfin être installés pour satisfaire vos besoins.
Merci d'avoir lu le livre LFS. Nous espérons que vous avez ce livre trouvé utile et que vous avez appris des choses sur la création d'un système.
Maintenant que le système LFS est installé, vous êtes peut-être en train de vous demander « Et maintenant ? » Pour répondre à cette question, nous vous avons préparé une liste de ressources.
Maintenance
Les bogues et informations de sécurité sont rapportés régulièrement pour tous les logiciels. Comme un système LFS est compilé à partir des sources, c'est à vous de prendre en compte ces rapports. Il existe plusieurs ressources en ligne pour garder trace de tels rapports, certains d'entre eux sont indiqués ci-dessous :
Freshmeat.net (http://freshmeat.net/)
Freshmeat peut vous prévenir (par email) des nouvelles versions des paquetages installés sur votre système.
CERT (Computer Emergency Response Team)
CERT a une liste de diffusion plubilant les alertes de sécurité concernant différents systèmes d'exploitation et applications. Les informations de souscription sont disponibles sur http://www.us-cert.gov/cas/signup.html.
Bugtraq
Bugtraq est une liste de diffusion pour révéler complètement les problèmes de sécurité. Elle publie les problèmes de sécurité qui viennent d'être découverts et, occasionnellement, des corrections potentiels. Les informations de souscription sont disponibles sur http://www.securityfocus.com/archive.
Beyond Linux From Scratch
Le livre Beyond Linux From Scratch couvre les procédures d'installation d'un grand nombre de logiciels en dehors du livre LFS. Le projet BLFS est disponible sur http://www.linuxfromscratch.org/blfs/.
Astuces LFS (LFS Hints)
Les astuces LFS sont une collection de documents éducatifs soumis par des volontaires à la communauté LFS. Ces astuces sont disponibles sur http://www.linuxfromscratch.org/hints/list.html.
Listes de diffusion
Il existe plusieurs listes de diffusion auxquelles vous pouvez vous abonner si vous cherchez de l'aide, voulez rester à jour avec les derniers développements, voulez contribuer au projet et plus. Voir Chapitre 1 - Listes de diffusion pour plus d'informations.
Le projet de documentation Linux (Linux Documentation Project)
Le but du TLDP est de collaborer à tous les problèmes relatifs à la documentation sur Linux. Le TLDP offre une large collection de guides pratiques, livres et pages man. Il est disponible sur http://www.tldp.org/.
Il est temps de rendre amorçable le système LFS. Ce chapitre
traite de la création d'un fichier fstab
, de la construction d'un noyau pour le
nouveau système LFS et de l'installation du chargeur de
démarrage Grub afin que le système LFS puisse être sélectionné
au démarrage.
Le fichier /etc/fstab
est utilisé
par quelques programmes pour déterminer les partitions à monter
par défaut, dans quel ordre, et quels systèmes de fichiers sont
à vérifier (pour des erreurs d'intégrité). Créez une nouvelle
table des systèmes de fichiers comme ceci :
cat > /etc/fstab << "EOF" # Début /etc/fstab # système point type options dump order pour fsck # de fichiers de montage /dev/[xxx] / [fff] defaults 1 1 /dev/[yyy] swap swap pri=1 0 0 proc /proc proc defaults 0 0 sysfs /sys sysfs defaults 0 0 devpts /dev/pts devpts gid=4,mode=620 0 0 shm /dev/shm tmpfs defaults 0 0 # Fin /etc/fstab EOF
Bien sûr, remplacez [xxx]
, [yyy]
et [fff]
avec les valeurs
appropriées pour votre système -- par exemple hda2
, hda5
et
reiserfs
. Pour tous les détails
sur les six champs de cette table, voir man 5 fstab.
Lors de l'utilisation d'un système de fichiers journalisé, le
1 1
à la fin de la
ligne doit être remplacé par 0
0
car une telle partition ne doit pas être
« dumpée » ou vérifiée.
Le point de montage /dev/shm
pour
tmpfs
est inclus pour permettre
l'activation de la mémoire partagée POSIX. Le noyau doit
disposer du support requis en interne pour fonctionner (plus
d'informations là-dessus dans la prochaine section). Merci de
noter qu'actuellement très peu de logiciels utilise la mémoire
partagée POSIX. Donc, vous pouvez considérer le point de
montage /dev/shm
optionnel. Pour
plus d'informations, voir Documentation/filesystems/tmpfs.txt
dans le
répertoire des sources du noyau.
Il existe d'autres lignes qui pourraient être ajoutées à votre
fichier /etc/fstab
. Un exemple
entre autres est la ligne pour les périphériques USB :
usbfs /proc/bus/usb usbfs devgid=14,devmode=0660 0 0
Cette option fonctionnera seulement si « Support for Host-side USB » et
« USB device filesystem »
sont configuré dans le noyau, et non pas en tant que module. Si
« Support for Host-side
USB » est compilé comme module, alors usbcore
doit être indiqué dans /etc/sysconfig/modules
.
Le paquet Linux contient le noyau Linux.
Construire le noyau implique un certain nombre
d'étapes : configuration, compilation et installation.
Lisez le fichier README
contenu
dans les sources du noyau pour d'autres méthodes.
Préparez la compilation en lançant la commande suivante :
make mrproper
Ceci nous assure que le répertoire du noyau est complètement nettoyé. L'équipe du noyau recommande que cette commande soit lancée avant chaque compilation du noyau. Vous ne devez pas penser que le répertoire des sources soit propre juste après avoir été déballé.
S'il a été décidé dans la section intitulée « Configurer la console Linux » de compiler le plan de codage dans le noyau, lancez la commande ci-dessous :
loadkeys -m /usr/share/kbd/keymaps/[path to keymap] > \ drivers/char/defkeymap.c
Par exemple, pour utiliser un clavier hollandais, utilisez
/usr/share/kbd/keymaps/i386/qwerty/nl.map.gz
.
Configurez le noyau via une interface par menu. BLFS a quelques informations concernant les besoins particuliers du noyau en terme de configuration pour les paquetages en dehors de LFS sur http://www.linuxfromscratch.org/blfs/view/svn/longindex.html#kernel-config-index :
make menuconfig
Sinon, make
oldconfig peut être plus approprié dans
certaines situations. Voir le fichier README
pour plus d'informations.
Sinon, make
oldconfig pourrait être plus approprié dans
certaines situations. Voir le fichier README
pour plus d'informations.
Si désiré, passez la configuration du noyau en copiant le
fichier de configuration, .config
, à partir du système hôte (en
supposant qu'il est disponible) dans le répertoire
linux-2.6.11.12
tout juste
déballé. Néanmoins, nous ne recommandons pas cette option. Il
est souvent mieux d'explorer tous les menus de configuration
et de créer la configuration du noyau à partir de rien.
NPTL requiert que le noyau soit compilé avec GCC 3.x, dans ce cas 3.4.3. Il n'est pas recommandé de compiler le noyau avec GCC-2.95.x car ceci est la cause d'échec dans la suite de tests de Glibc. Normalement, ceci ne devrait pas être mentionné car LFS ne construit pas GCC-2.95.x. Malheureusement, la documentation du noyau est obsolète et indique toujours que GCC-2.95.3 est le compilateur recommandé.
Compilez l'image du noyau et les modules :
make
Si vous utilisez des modules avec le noyau, un fichier
/etc/modprobe.conf
pourrait
être nécessaire. Les Informations concernant les modules et
la configuration du noyau sont situées dans la documentation
du noyau disponible dans le répertoire linux-2.6.11.12/Documentation
. De plus, la
page man modprobe.conf(5)
pourrait aussi avoir de l'intérêt.
Faites attention lors de la lecture d'autres documentations
relatives aux modules du noyau parce qu'elles s'appliquent
généralement seulement aux noyaux 2.4.x. D'après nos
connaissances, les problèmes spécifiques de configuration du
noyau pour Hotplug (le montage à chaud) et Udev se sont pas
documentés. Le problème est que Udev créera un nœud de
périphérique seulement si Hotplug ou un script écrit par
l'utilisateur insère le module correspondant dans le noyau et
tous les modules ne sont pas détectables par Hotplug. Notez
que les instructions comme celle ci-dessous, compris dans le
fichier /etc/modprobe.conf
, ne
fonctionnent pas avec Udev :
alias char-major-XXX some-module
À cause des complications avec Hotplug, Udev et les modules, nous recommandons fortement de commencer avec une configuration complètement non modulaire du noyau, spécialement si c'est la première fois que vous utilisez Udev.
Installez les modules si la configuration du noyau les utilise :
make modules_install
Une fois la compilation du noyau terminée, des étapes
supplémentaires sont requises pour terminer l'installation.
Certains fichiers ont besoin d'être copiés dans le répertoire
/boot
.
Le chemin vers l'image du noyau pourrait varier suivant la plateforme d'utilisation. La commande suivante suppose qu'elle se trouve sur une architecture x86 :
cp arch/i386/boot/bzImage /boot/lfskernel-2.6.11.12
System.map
est un fichier de
symboles pour le noyau. Il cartographie les points d'entrées
de chaque fonction dans l'API du noyau, ainsi que les
adresses des structures de données du noyau pour le noyau en
cours d'exécution. Lancez la commande suivante pour installer
le fichier carte :
cp System.map /boot/System.map-2.6.11.12
Le fichier de configuration du noyau .config
produit à l'étape
make menuconfig
ci-dessus contient toutes les sélections de configuration
pour le noyau tout juste compilé. Conserver ce fichier est
une bonne idée pour pouvoir s'y référer plus tard :
cp .config /boot/config-2.6.11.12
Il est important de noter que les fichiers du répertoire des sources du noyau n'appartiennent pas à root. À chaque fois qu'un paquet est déballé par l'utilisateur root (comme nous l'avons fait à l'intérieur du chroot), les fichiers conservent les identifiants utilisateur et groupe de celui qui a préparé le paquet. Ceci n'est habituellement pas un problème pour tout autre paquet installé car le répertoire des sources est supprimé après installation. Néanmoins, le répertoire des sources de Linux est souvent conservé assez lontemps. À cause de cela, il existe une chance pour que l'identifiant utilisateur soit affecté à quelqu'un sur la machine. Cette personne aurait alors les droits d'écriture sur les sources du noyau.
Si le répertoire des sources du noyau est conservé, lancez
chown -R 0:0
sur le répertoire linux-2.6.11.12
pour vous assurez que tous
les fichiers sont bien possédés par l'utilisateur
root.
Certaines documentation du noyau recommandent de créer un
lien symbolique à partir de /usr/src/linux
vers le répertoire des
sources du noyau. Ceci est spécifique aux noyaux
antérieurs à la série 2.6 et ne doit pas être réalisé sur
un système LFS car il peut poser des problèmes pour les
paquetages que vous souhaitez construire une fois que
votre système LFS de base est complet.
De plus, les en-têtes compris dans le répertoire système
include
devraient
toujours être ceux
avec lesquels Glibc a été compilé et, du coup, ne
devraient jamais
être remplacés par les en-têtes du noyau.
Votre nouveau système LFS est pratiquement fini. Une des dernières choses à faire est de vous assurer que le système peut démarrer proprement. Les instructions ci-dessous s'appliquent seulement aux ordinateurs de l'architecture IA-32, c'est-à-dire les PC standards. Des informations sur le « chargement au démarrage » pour les autres architectures devraient être disponibles aux emplacements habituelles des ressources pour ces architectures.
Le chargement au démarrage est un domaine complexe. Tout d'abord, quelques mots de mise en garde sont nécessaires. Vous devez vraiment connaitre le chargeur actuel et tout autre système d'exploitation présent sur le disque dur amorçable. Assurez-vous d'avoir une disquette de démarrage de façon à pouvoir réparer l'ordinateur si, par malheur, celui-ci devenait inutilisable (non amorçable).
Plus tôt, nous avons compilé et installé le chargeur de démarrage Grub pour cette étape. La procédure implique l'écriture de quelques fichiers spéciaux de Grub en des endroits spécifiques sur le disque dur. Nous recommandons fortement la création d'une disquette de démarrage Grub comme sauvegarde. Insérez une disquette de démarrage vierge et lancez les commandes suivantes :
dd if=/boot/grub/stage1 of=/dev/fd0 bs=512 count=1 dd if=/boot/grub/stage2 of=/dev/fd0 bs=512 seek=1
Enlevez la disquette et rangez-la dans un endroit sûr. Maintenant, lancez le shell grub :
grub
Grub utilise sa propre structure de nommage des disques et
partitions, de la forme (hdn,m), où n est le numéro du disque dur et
m le numéro de la
partition, tout deux commençant à zéro. Par exemple, la
partition hda1
est (hd0,0) pour Grub alors que
hdb3
est (hd1,2). Contrairement à Linux, Grub
ne considère pas les lecteurs de CDRoms comme des disques durs.
Par exemple, si un CD se trouve sur hdb
et un second disque dur sur hdc
, ce dernier disque sera malgré tout
(hd1).
En utilisant les informations ci-dessus, déterminez la
désignation appropriée pour votre partition root (ou votre
partition de démarrage si celle que vous utilisez est séparée).
Pour l'exemple suivant, il est supposé que votre partition root
(ou votre partition séparée) est hda4
.
Indiquez à Grub où chercher ses fichiers stage{1,2}
. La touche tabulation est
utilisable partout pour que Grub vous affiche les
alternatives :
root (hd0,3)
La commande suivante écrasera votre chargeur de démarrage
actuel. Ne lancez pas cette commande si ce n'est pas
désiré, par exemple, lors de l'utilisation d'un autre
gestionnaire de démarrage pour gérer votre MBR (Master Boot
Record). Dans ce cas, il serait probablement plus sensé
d'installer Grub dans le « secteur
de boot » de la partition LFS, auquel cas la
prochaine commande deviendrait : setup (hd0,3)
.
Ensuite, indiquez à Grub de s'installer dans le MBR de
hda
:
setup (hd0)
Si tout va bien, Grub indiquera avoir trouvé ses fichiers dans
/boot/grub
. C'est tout ce qu'il y
a à faire. Quitter le shell grub :
quit
Créez un fichier « liste de menus » définissant le menu de démarrage de Grub :
cat > /boot/grub/menu.lst << "EOF" # Début de /boot/grub/menu.lst # Par défaut, lance la première entrée du menu. default 0 # Attends 30 secondes avant de lancer le noyau par défaut. timeout 30 # Utilise de jolies couleurs. color green/black light-green/black # La première entrée concerne LFS. title LFS 6.1 root (hd0,3) kernel /boot/lfskernel-2.6.11.12 root=/dev/hda4 EOF
Ajoutez une entrée pour votre distribution hôte si vous le souhaitez. Cela pourrait ressembler à ceci :
cat >> /boot/grub/menu.lst << "EOF" title Red Hat root (hd0,2) kernel /boot/kernel-2.6.5 root=/dev/hda3 initrd /boot/initrd-2.6.5 EOF
Dans le cas d'une machine avec plusieurs systèmes d'exploitation, l'entrée suivante devrait le permettre :
cat >> /boot/grub/menu.lst << "EOF" title Windows rootnoverify (hd0,0) chainloader +1 EOF
Si info grub ne fournit pas toutes les données nécessaires, plus d'informations concernant Grub sont disponibles sur le site web, situé sur http://www.gnu.org/software/grub/.
Le FHS stipule que le fichier menu.lst
de GRUB doit être un lien symbolique
vers /etc/grub/menu.lst
. Pour
satisfaire ce pré-requis, lancez la commande suivante :
mkdir /etc/grub && ln -s /boot/grub/menu.lst /etc/grub
ABI |
Application Binary Interface |
ALFS |
Automated Linux From Scratch |
ALSA |
Advanced Linux Sound Architecture |
API |
Application Programming Interface |
ASCII |
American Standard Code for Information Interchange |
BIOS |
Basic Input/Output System |
BLFS |
Beyond Linux From Scratch |
BSD |
Berkeley Software Distribution |
chroot |
change root |
CMOS |
Complementary Metal Oxide Semiconductor |
COS |
Class Of Service |
CPU |
Central Processing Unit |
CRC |
Cyclic Redundancy Check |
CVS |
Concurrent Versions System |
DHCP |
Dynamic Host Configuration Protocol |
DNS |
Domain Name Service |
EGA |
Enhanced Graphics Adapter |
ELF |
Executable and Linkable Format |
EOF |
End of File |
EQN |
equation |
EVMS |
Enterprise Volume Management System |
ext2 |
second extended file system |
FAQ |
Frequently Asked Questions |
FHS |
Filesystem Hierarchy Standard |
FIFO |
First-In, First Out |
FQDN |
Fully Qualified Domain Name |
FTP |
File Transfer Protocol |
GB |
Gibabytes |
GCC |
GNU Compiler Collection |
GID |
Group Identifier |
GMT |
Greenwich Mean Time |
GPG |
GNU Privacy Guard |
HTML |
Hypertext Markup Language |
IDE |
Integrated Drive Electronics |
IEEE |
Institute of Electrical and Electronic Engineers |
IO |
Input/Output |
IP |
Internet Protocol |
IPC |
Inter-Process Communication |
IRC |
Internet Relay Chat |
ISO |
International Organization for Standardization |
ISP |
Internet Service Provider |
KB |
Kilobytes |
LED |
Light Emitting Diode |
LFS |
Linux From Scratch |
LSB |
Linux Standards Base |
MB |
Megabytes |
MBR |
Master Boot Record |
MD5 |
Message Digest 5 |
NIC |
Network Interface Card |
NLS |
Native Language Support |
NNTP |
Network News Transport Protocol |
NPTL |
Native POSIX Threading Library |
OSS |
Open Sound System |
PCH |
Pre-Compiled Headers |
PCRE |
Perl Compatible Regular Expression |
PID |
Process Identifier |
PLFS |
Pure Linux From Scratch |
PTY |
pseudo terminal |
QA |
Quality Assurance |
QOS |
Quality Of Service |
RAM |
Random Access Memory |
RPC |
Remote Procedure Call |
RTC |
Real Time Clock |
SBU |
Standard Build Unit |
SCO |
The Santa Cruz Operation |
SGR |
Select Graphic Rendition |
SHA1 |
Secure-Hash Algorithm 1 |
SMP |
Symmetric Multi-Processor |
TLDP |
The Linux Documentation Project |
TFTP |
Trivial File Transfer Protocol |
TLS |
Thread-Local Storage |
UID |
User Identifier |
umask |
user file-creation mask |
USB |
Universal Serial Bus |
UTC |
Coordinated Universal Time |
UUID |
Universally Unique Identifier |
VC |
Virtual Console |
VGA |
Video Graphics Array |
VT |
Virtual Terminal |
Nous aimerions remercier les personnes et organisations suivantes pour leur contributions au projet Linux From Scratch.
Gerard Beekmans <gerard@linuxfromscratch.org> – initiateur de Linux From, organisateur du projet LFS
Christine Barczak <theladyskye@linuxfromscratch.org> – éditeur du livre LFS
Matthew Burgess <matthew@linuxfromscratch.org> – Co-leader du projet LFS, mainteneur du paquet général LFS, rédacteur technique LFS.
Craig Colton <meerkats@bellsouth.net> – créateur des logos pour les projets LFS, Automated Linux From Scratch (ALFS), BLFS et des astuces
Nathan Coulson <nathan@linuxfromscratch.org> – mainteneur des scripts de démarrage LFS
Jeroen Coumans <jeroen@linuxfromscratch.org> – Développeur du site web, mainteneur de la FAQ
Bruce Dubbs <bdubbs@linuxfromscratch.org> – Leader de l'équipe d'assurance qualité LFS, éditeur du livre BLFS
Manuel Canales Esparcia <manuel@linuxfromscratch.org> – Mainteneur XML/XSL pour LFS
Jim Gifford <jim@linuxfromscratch.org> – Rédacteur technique LFS, mainteneur des correctifs
Nicholas Leippe <nicholas@linuxfromscratch.org> – Mainteneur du Wiki
Anderson Lizardo <lizardo@linuxfromscratch.org> – Mainteneur des scripts du serveur Web
Scot Mc Pherson <scot@linuxfromscratch.org> – Mainteneur de la passerelle NNTP pour LFS
Ryan Oliver <ryan@linuxfromscratch.org> – Leader de l'équipe de tests, mainteneur de l'ensembles d'outils, co-créateur de Pure LFS (PLFS)
Alexander Patrakov <semzx@newmail.ru> – Ancien rédacteur technique pour
James Robertson <jwrober@linuxfromscratch.org> – Mainteneur Bugzilla, développeur wiki, rédacteur technique pour LFS
Tushar Teredesai <tushar@linuxfromscratch.org> – Éditeur du livre BLFS, mainteneur des projets des actuces et des correctifs
Jeremy Utley <jeremy@linuxfromscratch.org> – Rédacteur technique LFS, mainteneur de Bugzilla, mainteneur des scripts de démarrage LFS, co-administrateur du serveur LFS
Zack Winkles <zwinkles@gmail.com> – Ancien rédacteur technique LFS
Un nombre illimité de personnes sur les différentes listes de discussion LFS et BLFS qui ont aidé à rendre ce livre possible en donnant des suggestions, en restant le livre et en soumettant des rapports de bogues, des instructions et en parlant de leurs expériences lors de l'installation des différents paquets.
Manuel Canales Esparcia <macana@lfs-es.org> – projet de traduction espagnol
Johan Lenglet <johan@linuxfromscratch.org> – projet de traduction français
Anderson Lizardo <lizardo@linuxfromscratch.org> – projet de traduction portugais
Thomas Reitelbach <tr@erdfunkstelle.de> – projet de traduction allemand
Scott Kveton <scott@osuosl.org> – miroir lfs.oregonstate.edu
Mikhail Pastukhov <miha@xuy.biz> – miroir lfs.130th.net
William Astle <lost@l-w.net> – miroir ca.linuxfromscratch.org
Jeremy Polen <jpolen@rackspace.com> – miroir us2.linuxfromscratch.org
Tim Jackson <tim@idge.net> – miroir linuxfromscratch.idge.net
Jeremy Utley <jeremy@linux-phreak.net> – miroir lfs.linux-phreak.net
Manuel Canales Esparcia <manuel@linuxfromscratch.org> – miroir lfsmirror.lfs-es.org
Andres Meggiotto <sysop@mesi.com.ar> – miroir lfs.mesi.com.ar
Eduardo B. Fonseca <ebf@aedsolucoes.com.br> – miroir br.linuxfromscratch.org
Barna Koczka <barna@siker.hu> – miroir hu.linuxfromscratch.org
UK Mirror Service – miroir linuxfromscratch.mirror.ac.uk
Martin Voss <Martin.Voss@ada.de> – miroir lfs.linux-matrix.net
Guido Passet <guido@primerelay.net> – miroir nl.linuxfromscratch.org
Bastiaan Jacques <baafie@planet.nl> – miroir lfs.pagefault.net
Roel Neefs <lfs-mirror@linuxfromscratch.rave.org> – miroir linuxfromscratch.rave.org
Justin Knierim <justin@jrknierim.de> – miroir www.lfs-matrix.de
Stephan Brendel <stevie@stevie20.de> – miroir lfs.netservice-neuss.de
Antonin Sprinzl <Antonin.Sprinzl@tuwien.ac.at> – miroir at.linuxfromscratch.org
Fredrik Danerklint <fredan-lfs@fredan.org> – miroir se.linuxfromscratch.org
Parisian sysadmins <archive@doc.cs.univ-paris8.fr> – miroir www2.fr.linuxfromscratch.org
Alexander Velin <velin@zadnik.org> – miroir bg.linuxfromscratch.org
Dirk Webster <dirk@securewebservices.co.uk> – miroir lfs.securewebservices.co.uk
Thomas Skyt <thomas@sofagang.dk> – miroir dk.linuxfromscratch.org
Simon Nicoll <sime@dot-sime.com> – miroir uk.linuxfromscratch.org
Pui Yong <pyng@spam.averse.net> – miroir sg.linuxfromscratch.org
Stuart Harris <stuart@althalus.me.uk> – miroir lfs.mirror.intermedia.com.sg
Jason Andrade <jason@dstc.edu.au> – miroir au.linuxfromscratch.org
Dean Benson <dean@vipersoft.co.uk> pour plusieurs contributions financières
Hagen Herrschaft <hrx@hrxnet.de> pour le don d'un système P4 2.2 GHz, fonctionnant actuellement sous le nom de Lorien
VA Software qui, sous le titre de Linux.com, a donné une station de travail VA Linux 420 (ancien StartX SP2)
Mark Stone pour le don de Belgarath, le serveur linuxfromscratch.org