LFS et BLFS 5.0

Posté par  (site web personnel) . Modéré par Nÿco.
0
12
nov.
2003
Noyau
La version 5.0 de Linux From Scratch (LFS) est sortie.

Elle contient le noyau Linux version 2.4.22, la GNU C Library (glibc) 2.3.2 et le GNU Compiler Collection (gcc) 3.3.1. De plus, Lilo aurait été remplacé par Grub.

Dans Beyond Linux From Scratch (BLFS), on trouvera XFree86-4.3.0.1, KDE 3.1.4, GNOME 2.2.2, Apache 2.0.47, OpenOffice 1.1.0 et un large panel de bibliothèques en tous genres.

Le livre Linux From Scratch a également été amélioré. Quelques rappels sur LFS: Linux From Scratch (LFS) est un projet qui indique les étapes nécessaires à la construction de son propre système GNU/Linux personnalisé. Le principe est de repartir de la base, et de construire pas à pas à partir des sources un système d'exploitation dont on maîtrise tous les rouages. Bien entendu, LFS sert aussi à apprendre le fonctionnement interne d'un système GNU/Linux.

Le livre LFS est en fait la pièce la plus importante : il indique les étapes à suivre pour créer son système à partir de presque rien.

Notons qu'il existe aussi Beyond Linux From Scratch, un sous-projet qui fournit un véritable support d'installation pour LFS.

Aller plus loin

  • # Re: LFS et BLFS 5.0

    Posté par  . Évalué à 10.

    N'hésitez pas à aider pour la traduction du livre en français :
    http://traduc.lfs.tuxfamily.org/aide.php(...)
  • # Minute francophone

    Posté par  (site web personnel) . Évalué à 10.

    un large panel de librairies en tous genres
    de bibliothèques bien sûr
  • # Re: LFS et BLFS 5.0

    Posté par  . Évalué à -2.

    Le 12/11/2003 @ 08:58, aucun mirroir ne marchait !
    Pour une fois que je m'intéressais à LFS ....
  • # Nouvelle méthode de préparation de la toolchain

    Posté par  (site web personnel) . Évalué à 10.

    Une des améliorations majeures de LFS 5.0 est la nouvelle manière dont est faite la toolchain (c'est-à-dire Binutils + GCC + GlibC principalement).

    Contrairement aux précédentes versions, l'accent est mis sur la "pureté" de cette toolchain : il est fait en sorte qu'elle n'ait strictement aucun lien avec le système hôte (la distribution Linux utilisée comme point de départ). Pour arriver à cela, ces 3 packages sont compilés une première fois, et ce résultat est utilisé pour les recompiler une seconde fois.

    Tout ceci permet d'éviter bien des surprises par la suite : beaucoup de problèmes (bibliothèque qui ne compile pas, programme qui "segfault"...) peuvent surgir bien plus tard (souvent seulement dans BLFS).

    Pour ceux qui sont interessés par ça, il existe un hint "Pure LFS" (à l'origine de cette nouvelle méthode) qui donnera un peu plus de détails techniques que le livre.
    • [^] # Re: Nouvelle méthode de préparation de la toolchain

      Posté par  . Évalué à 9.

      Ayant installé la 4.1, je peux te dire qu'il fallait également recompiler deux fois les trois paquets dont tu parles. Ce n'est d'ailleurs pas un plaisir : 14,71 SBU pour compiler glibc, ca représente 3 heures et demi chez moi.
      On peut aussi rajouter un lien versune liste de 'Trucs et Astuces' sur la LFS : http://www2.fr.linuxfromscratch.org/hints/list.html(...)
      J'ai l'impression que les mirroirs ne sont pas à jour sinon.
      • [^] # Re: Nouvelle méthode de préparation de la toolchain

        Posté par  (site web personnel) . Évalué à 7.

        Je precise que Gentoo recompile egalement ces paquets pour les epurer. Ou devrais je dire compilait car il ne semble plus necessaire de le faire deux fois.

        Sinon j'ai moi meme cree une 4.1 a l'epoque ou seule la 4.0 existait et je l'avais d'ailleurs migre sans documentation vers glibc 2.3.1 et gcc 3.3.1 (passe a 3.3.2 depuis ce week end). La partie compatibilite kernel 2.6 est amusante, ca necessite un peu de retouches.

        Enfin, pour les afficionados de KDE, la 3.2_beta1 compile bien mais il risque de vous manquer les menu de kcontrol (le panneau de configuration), mais bon, c'est un bug connu et y'a un quickfix :
        http://bugs.kde.org/show_bug.cgi?id=67192(...)

        Steph
      • [^] # Re: Nouvelle méthode de préparation de la toolchain

        Posté par  . Évalué à 4.

        ah, c'est p'tits jeunes ... 3 malheureuses heures de compilation et ca rale ...

        Y z'ont pas connu le temps pas si lointain ou il fallait 12 à 15h sur une sparc pour compiller gcc 3 fois ( la premiere avec l'ancien compilo, la deuxieme avec le nouveau , et la troisieme pour verif)

        Quant a kde et ses libs , il fallait 2 jours au moins !
        • [^] # Re: Nouvelle méthode de préparation de la toolchain

          Posté par  . Évalué à 5.

          Désolé, je donnais peut-être effectivement l'impression de râler. Je voulais juste prévenir les personnes motivées qu'il est vraiment frustrant de passer 3 heures et demi, rentrer une ligne de commande, re-attendre 3 heures, etc...
          Ce livre est une beauté pour vraiment comprendre comment marche un système basé sur Linux, mais ca serait encore mieux si la compiilation demandait moins de temps.
          Quant aux p'tit jeune, mes rares cheveux dont pas mal de blancs devrait te rassurer : ca me fait plaisir que tu me dises ça !!!
          • [^] # Re: Nouvelle méthode de préparation de la toolchain

            Posté par  . Évalué à 2.

            Euh, pour ceux qui ne veulent pas rester devant leur machine, il y a ALFS (Automated LFS).
            J'utilise moi-même nALFS pour mon système (basé sur une LFS modifiée), et tous mes profils XML que j'ai fait comme un grand en français, avec gestion de paquetage par installwatch.

            Je recompile la LFS 5.0 de base (avec mes ajouts : Linux-PAM, installwatch, gcc 3.3.2, kernel 2.6 avec supermount-ng, etc) en lançant simplement le tout à partir de nALFS, puis y a qu'à attendre qu'il ait fini :)
  • # Re: LFS et BLFS 5.0

    Posté par  . Évalué à 3.

    J'ai changé de machine récemment et j'ai installé LFS il y a un mois (la 5.0 était en béta). Résultat : tout c'est passé comme un charme, du partitionnement à l'installation des dockapps de WindowMaker je n'ai pas eu le moindre problème. Magique ! :-)
    • [^] # Re: LFS et BLFS 5.0

      Posté par  (site web personnel) . Évalué à 4.

      Maintenant il te reste la pire partie a gerer, la mettre regulierement a jour. Rien que pour la partie openssh/ssl j'en ai bave car il m'a fallu recompiler une petite dizaine d'applications.

      Steph
  • # Re: LFS et BLFS 5.0

    Posté par  (site web personnel) . Évalué à -1.

    Je suis allé faire un tour rapide sur le livre LFS 5.0
    J'ai remarqué qu'ils installent pleins de trucs dans /tools

    Je ne connait pas LFS, mais pourquoi ils ne mettent pasles prog dans /usr/bin ou /usr/local/bin ?
    Il y a t'il beaucoup d'autres differences avec des distrib plus classiques ?
    • [^] # Re: LFS et BLFS 5.0

      Posté par  (site web personnel) . Évalué à 3.

      ca y est, j'ai dit ma connerie ...
      ok c'est que pour un prmier passage, a la seconde compil c'est ok

      je n'y avait pas pensé car je ne me doutai pas qu'on allait compiler ncurses 2 fois


      1000 excuses
      • [^] # Re: LFS et BLFS 5.0

        Posté par  . Évalué à 1.

        Justement ça m'intéresse pour rebondire sur ton "erreur", est-il possible de créer un type d'arborescence personalisée avec LFS?
        Histoire de changer quoi et de faire un truc plus dépouillés niveau profondeur des chemins. Je connais très bien le modèle actu et c'est justement pour ça que j'aimerais faire un autre truc.


        'fin, si vous voyez c'que je veux dire, c'est déjà çà
        • [^] # Re: LFS et BLFS 5.0

          Posté par  . Évalué à 5.

          Oui tu peux (bonjour les options de compil !!) mais c'est loin d'être conseillé d'autant que LFS cherche à être conforme au Linux Standard Base.
        • [^] # Re: LFS et BLFS 5.0

          Posté par  . Évalué à 5.

          C'est possible et ça existe déjà si j'ai bonne mémoire. Et ça s'appelle Gobo Linux. D'ailleurs, toute l'arborescence a été changée pour un truc plus MacOs d'après ce que j'ai vu.

          Par contre, c'est pas prévu pour les débutants sous Linux (là, ça aurait été parfait).
          • [^] # Re: LFS et BLFS 5.0

            Posté par  . Évalué à 1.

            Par contre, c'est pas prévu pour les débutants sous Linux (là, ça aurait été parfait).
            sans prétention aucune, je n'en suis pas :)

            je vais tenter la chose, et y a surement moyen d'automatiser la chose pour chaque compile, je vais jeter un oeil



            merci
            • [^] # Re: LFS et BLFS 5.0

              Posté par  . Évalué à 2.

              et quel est l'intêret d'utiliser une arborescence non standard ? (outre la curiosité légitime que peut éprouver tout bon geek devant un nouveau défi :)
              • [^] # Re: LFS et BLFS 5.0

                Posté par  . Évalué à 1.

                Je me pose la même question depuis quelque temps. A savoir, est-il possible de créer une architecture plus intuitive que la traditionnelle avec des héritages lointains Unix ? Par exemple, /etc ne signifie rien pour moi à priori. Si ca pouvait s'appeler /config, je comprendrais sans à avoir à étudier mon manuel du parfait unixien.
                Il se trouve que je commence à avoir de la bouteille (Dom pérignon) et que par habitude, je sais que pour configurer mon système, il faut aller voir dedans, mais ca n'est en rien intuitif.
                J'imagine que bin voulait dire binaries à une époque, mais ca fait longtemps qu'il n'y pas que des binaires dans ces repertoire (/bin, /usr/bin, /usr/local/bin, etc...). S'il y avait un /program à la place, ca me semblerait plus logique.
                Après, ca doit choquer tous les puristes, mais bon, faut bien innover et laisser de la place à l'innovation et aux expérimentations, non ?
                • [^] # Re: LFS et BLFS 5.0

                  Posté par  . Évalué à 2.

                  en fait en reflechissant un peu on s'apercoit que tout tourne autour de la securité de la machine et du montage des filesystems

                  Il faut ( liste tres imprecise) :
                  - un repertoire que seul root peut utiliser -> /sbin
                  - un repertoire que tout le monde peut utiliser et qui est monté des le demarage ( niveau 1 ) -> /bin permet le demarage en failsafe.
                  - des repertoires que tout le monde peut utiliser, qui sont generalement locaux, mais qui ne sont pas absolument indispensables -> /usr/bin
                  - des repertoires que tout le monde peut utiliser, encore moins indispensables, et qui peuvent etres partages avec d'autres machines
                  -> /usr/local/bin

                  etc ...

                  tout mettre dans /program ou /windows , c'est tres insuffisant . Si tout va bien c'est parfait mais il suffit de voir une machine windows qui a des problemes (de softs de disque ou de securité) pour s'en rendre compte.
                  • [^] # Re: LFS et BLFS 5.0

                    Posté par  . Évalué à 1.

                    Je suis entièrement d'accord avec toi que l'architecture Unix a de gros avantages pour les points que tu cites. Le découpage des applis suivant leur degré d'importance ou au niveau de la sécurité, c'est très bien. Mais un petit renomage, ca pourrait être pas mal. Ce n'est en aucun cas la solution à tout, mais ca pourrait être une piste de reflexion, example :
                    /sbin -> /programs/rootprogs/
                    /bin -> /programs/progs/
                    /usr/bin -> /programs/nonessentialprogs/
                    etc...
                    Après, il faut arrêter de comparer tout effort de simplification avec Windows ou MacOS, mais au contraire trouver sa propre voie...
                    • [^] # Re: LFS et BLFS 5.0

                      Posté par  . Évalué à 1.

                      non, pour moi share, etc, bin, sbin, ... sont assez explicites...

                      Ô horreur sur ce que nous sort Lezardbreton!!!


                      Après, il faut arrêter de comparer tout effort de simplification avec Windows ou MacOS, mais au contraire trouver sa propre voie...
                      tu as raison, mais ton exemple s'y rapporche fortement.


                      Je n'ai aucuns problèmes avec le standard que je trouve de toute façon très bon mais c'est vrai c'est surtout par curiosité que je voudrais faire ça =)

                      ++
                      • [^] # Re: LFS et BLFS 5.0

                        Posté par  (site web personnel) . Évalué à 1.

                        excusez moi de poser une question idote mais puisque ca parait clair et limpide a beaucoup de gens :

                        le etc de /etc ... il veut dire quoi ?
                        ok il sert pour les fichiers de conf mais il signifie quoi ?
                        je n'arrive pas a trouver de lien entre etc et config ( a part peut etre le "c" de config :-/ )
              • [^] # Re: LFS et BLFS 5.0

                Posté par  . Évalué à 2.

                Ça peut être utile pour du matériel embarquée, où on a des besoins
                spécifique.
                Mais garder une arborescence standard permet de ne pas avoir
                de problèmes lors de la compilation et l'utilisation de nouveau
                programmes. L'arbo unix est un peu complexe, mais permet une meilleure
                flexibilité, et puis de toute façon les packages s'occupent de gérer ça
                à notre place (sauf dans le cas de la LFS bien sûr)
  • # 2.6 + NPTL

    Posté par  . Évalué à 4.

    Et pour ceux qui ont le goût du risque, on peut même s'aventurer dans les méandres du noyau 2.6.0test avec le support des NPTL (le remplacant du désormais vieux linuxthreads)
    Il vous faudra vous armer de patience et de ce hint:

    http://linuxfromscratch.rave.org/hints/downloads/files/nptl.txt(...)

    Et surtout, faites partager votre expérience sur la ml lfs-hackers (http://linuxfromscratch.org/mailman/listinfo/lfs-hackers(...) ), l'avenir de LFS est entre vos mains !

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.