Guide de construction

Pour les intégrateurs : compiler LFSi depuis les sources et produire vos propres images.

Le principe

LFSi est livrée avec sa chaîne de fabrication complète : un dépôt Git contenant les manifestes (versions, empreintes, signatures), les patchs, les recettes de compilation et l'orchestrateur. À partir de là, tout se reconstruit : la toolchain, le système de base, l'ISO, les paquets — pour chaque architecture supportée (x86-64, ARM64, ARMv7, RISC-V).

Deux builds réalisés à partir du même état du dépôt et du même cache de sources produisent des artefacts équivalents : c'est la reproductibilité.

Préparer la machine de build

• Une machine Linux propre (une VM ou un conteneur dédié conviennent très bien) — la chaîne vérifie elle-même que les outils requis sont présents, et refuse de démarrer sinon, avec un message explicite.
• De l'espace disque (compter large : sources + compilation + artefacts) et des cœurs CPU (la compilation est parallélisée).
• Si l'architecture de l'hôte diffère de l'architecture cible (ex. construire du x86-64 sur une machine ARM64) : qemu-user + binfmt, pour exécuter les binaires cible que certains configure lancent pendant la compilation (et le chroot). Sur Debian/Ubuntu : sudo apt-get install -y qemu-user-static binfmt-support. Inutile si hôte et cible partagent la même architecture.
• Un accès au dépôt des sources https://sources.lfsi.sourcitec.com/sources-0.x — ou un cache pré-rempli pour construire entièrement hors ligne (air-gap).
• Une racine de build /mnt/lfsi (valeur LFS_PREFIX de config/build.conf), préparée en une commande :

make prepare-root

C'est le seul geste root de tout le processus (création sous /mnt + attribution au compte de build) ; la compilation se déroule ensuite en utilisateur non privilégié. La cible est idempotente et n'utilise pas sudo si LFS_PREFIX pointe un emplacement que vous possédez déjà. Si la racine n'est pas prête, make toolchain / make base s'arrêtent immédiatement en renvoyant vers make prepare-root.

Récupérer la chaîne

git clone https://git.sourcitec.com/lfsi.git
cd lfsi

La configuration se fait dans config/build.conf : architecture cible (ARCH), mode de toolchain, parallélisme, chemins du cache. Aucune valeur n'est à modifier dans les scripts eux-mêmes.

Les modes de toolchain (B / A / auto)

La toolchain (compilateur, bibliothèque C…) peut être obtenue de deux façons, au choix dans la configuration :

• Mode A — pré-empaquetée : vous téléchargez (ou réutilisez) une toolchain déjà construite, archivée avec sa version et son empreinte. Avantages : moins d'exigences sur la machine de build, gain de temps important.
• Mode B — intégrée : la toolchain est compilée dans le même flux que le système. Plus long, mais entièrement autonome.
• Mode auto : prend l'artefact (mode A) s'il est récupérable — cache local ou miroir —, sinon construit (mode B). Idéal pour un build all : on construit la première fois (puis make toolchain-pack), on récupère ensuite, sans rien changer dans build.conf.

Dans tous les cas, la toolchain est croisée et indépendante de votre distribution hôte : ce que vous construisez ne dépend pas de la machine qui construit.

Produire et publier un artefact (mode A)

Après un premier build en mode B, empaquetez la toolchain pour la réutiliser ailleurs (ou accélérer un futur build all) :

make toolchain ARCH=x86_64        # construit (mode B), puis la valide
make toolchain-pack ARCH=x86_64   # → artifacts/x86_64/toolchain/lfsi-toolchain-….tar.zst (+ .sha256, + .toml)
scp -r artifacts/x86_64/toolchain/* <hôte>:/srv/.../toolchains-0.x/x86_64/   # publication (scp : pas de rsync sur le miroir)

L'artefact est allégé (strip des sections de debug, sur une copie — la toolchain installée n'est pas modifiée), déterministe, porte son empreinte sha256 et un manifeste de provenance (composants/versions) qui garantit qu'un système de base donné provient bien d'une toolchain donnée (traçabilité).

Réutiliser l'artefact (mode A)

Sur une autre machine, ou pour éviter de recompiler, basculez TOOLCHAIN_MODE="A" dans config/build.conf puis :

make prepare-root ARCH=x86_64
make toolchain    ARCH=x86_64     # télécharge depuis TOOLCHAIN_URL, vérifie le sha256, déballe — sans recompiler
make toolchain-check ARCH=x86_64

Construire, étape par étape

make toolchain ARCH=x86_64     # la cross-toolchain (ou son téléchargement, mode A)
make base      ARCH=x86_64     # le système de base durci
make iso       ARCH=x86_64     # l'image amorçable
make apps PKGS="nginx"         # des paquets applicatifs
make audit                     # le scan de conformité + rapport

Quelques propriétés utiles au quotidien :

• Reprise sur erreur : un échec sur un paquet ne perd pas le travail accompli — corrigez, relancez, la chaîne reprend où elle s'était arrêtée (fichiers-témoins *.stamp).
• Journaux : un fichier de log horodaté par étape et par architecture (logs/<arch>/), plus un résumé global.
• Intégrité d'abord : aucune archive source n'est extraite ni compilée avant validation de son empreinte sha256 (et de sa signature lorsqu'une clé est fournie).

Les artefacts sont rangés par architecture dans artifacts/<arch>/ : toolchain, base, ISO, paquets — chacun avec son manifeste d'empreintes signé et sa SBOM.

Construire pour une autre architecture

C'est un paramètre, pas un chantier :

make toolchain base iso ARCH=aarch64

Les définitions par architecture (triplets, drapeaux, configuration du noyau) vivent dans config/arch/. Particularités d'amorçage : UEFI+BIOS pour x86-64, UEFI pour ARM64, U-Boot/OpenSBI pour ARMv7 et RISC-V (images testables sous QEMU).

Construire l'ISO

Une fois le système bâti et configuré, l'image ISO amorçable (UEFI + BIOS) s'obtient ainsi :

sudo make system && sudo make sysconfig    # système final + /etc par défaut
sudo make kernel                            # noyau (FS/pilotes « live » en built-in)
sudo make initramfs                         # initramfs live (cpio.gz)
sudo make iso                               # → artifacts/<arch>/iso/lfsi-<arch>.iso

make iso assemble un squashfs du système (hors toolchain temporaire et sources), y ajoute le noyau, l'initramfs maison et le menu GRUB, puis produit une ISO hybride amorçable BIOS et UEFI via grub-mkrescue, avec son empreinte sha256.

Modèle « hors appliance » (CDC §13.9) : le système livré (squashfs + le GRUB compilé par le projet, posé sur disque par l'installeur) est 100 % construit depuis les sources ; seuls les outils de fabrication de l'image proviennent de la machine de build. À installer sur l'hôte (Debian/Ubuntu) :

sudo apt-get install -y grub-common xorriso mtools squashfs-tools

Les modules GRUB (i386-pc + x86_64-efi) embarqués dans l'ISO sont ceux compilés par le projet (superposés au /usr/lib/grub de l'hôte par bind-mount temporaire), pas ceux de l'hôte : inutile d'installer grub-pc-bin/grub-efi-amd64-bin — souvent indisponibles sur un hôte non-x86 (ex. une machine de build ARM64) — et le bootloader de l'ISO reste from-source.

L'initramfs est maison (make/initramfs.sh, pas de dracut/kmod) : il monte le média (label LFSI) → le squashfs → un overlay tmpfs → switch_root vers le système.

Faire évoluer la toolchain

La toolchain (binutils, gcc, glibc, en-têtes du noyau) n'est pas un paquet comme les autres : c'est le socle figé d'une édition, dont dérivent tous les artefacts. La règle « dernières versions amont » qui s'applique aux paquets autonomes ne s'y applique pas — elle reste alignée sur LFS 12.4 et n'évolue que sur déclencheur explicite :

• CVE d'exécution dans glibc / libstdc++ / libgcc (priorité : glibc, liée à tout le système) ;
• fin de maintenance amont (EOL) de la série gcc ou glibc utilisée ;
• contrainte de compatibilité : un paquet exige une toolchain plus récente, ou l'on veut exposer aux programmes des API noyau plus récentes (→ relèvement des en-têtes) ;
• réalignement de jalon sur une nouvelle édition LFS stable.

Bon à savoir : grâce à la stabilité de l'ABI de glibc/libstdc++, un relèvement de maintenance (CVE, même série) se limite à reconstruire ce composant — les binaires existants restent valides, pas de reconstruction complète. Et le noyau d'exécution doit rester ≥ aux en-têtes ayant servi à compiler glibc : tant que c'est le cas, un noyau plus récent n'oblige à rien côté toolchain.

La doctrine normative complète (criticité par composant, déclencheurs, traçabilité) est l'annexe C.16.1 du cahier des charges.

Construire en environnement isolé (air-gap)

1. Sur une machine connectée : remplissez le cache (make télécharge et vérifie tout dans cache/).
2. Transférez dépôt + cache sur la machine isolée.
3. Construisez : aucun accès réseau n'est nécessaire — toutes les vérifications d'intégrité restent actives.

Aller plus loin

• Créer vos propres paquets : voir la structure d'un port source dans Gestion des paquets et les recettes existantes (recipes/apps/).
• La spécification complète de la chaîne fait partie du dépôt (docs/).

LFSi — Linux From SourcITEC. © SourcITEC — LFSi team.