Pour bien compartimenter les étapes de création du devkit, on va partir du résultat, et revenir pas à pas jusqu’au début ; cela permettra de bien définir quels sont les besoins à chaque étape, et donc ce qui doit être fait auparavant.

Ce qu’on désire au fond, avoir un ensemble de nbas et peut-être un script qui lancerait Ncooker séquentiellement pour les installer sur le répertoire voulu.

Au final, on aura donc:

• un système console (au minimum, voir si on rajoute X.org) bootable, permettant de compiler de nouveaux nbas
• un ensemble de nbas générés et déjà installés (c’est ce qui compose le système), ces nbas peuvent être réutilisés pour une nouvelle installation de devkit.

Pour obtenir ça, il faut avoir lancé Ncooker pour tous les nbuilds nécessaires, dans le bon ordre.

On a deux possiblités :

• un script lancé par Ngadkm effectue tout ça automatiquement. Il faut alors un script de lancement et un fichier de configuration pour savoir quoi lancer et dans quel ordre (on pourrait se rapprocher de l’idée de Nperso, pour avoir un format de fichier de config en commun)
• un shell classique, et une documentation indiquant quoi lancer et dans quel ordre. Le lancement de Ncooker pour chaque paquet se ferait à la main.

Pour avoir ça, il faut :

• un shell, fournit par les commandes précédentes
• Ncooker ! comme on n’a qu’une version de développement sur subversion, il faut prendre la dernière. Pour cela :
  • soit on récupère le daily-tarball sur le site, mais dans ce cas, on récupère tout le dépot svn, et pas seulement Ncooker
  • soit on a précédemment installé le client subversion dans le système temporaire pour faire un checkout, mais cela implique d’installer subversion et toutes ses dépendances, pas génial
  • soit juste avant de rentrer dans le chroot, Ngadkm récupère la dernière version de Ncooker par subversion depuis le système hôte, et le copie dans le système temporaire, et on rentre alors dans le chroot qui contient Ncooker

Dans tous les cas, Ncooker doit être paramétré avant d’être lancé, il faut donc que le make install fonctionne parfaitement, aussi bien pour un root normal, qu’un un peu particulier (car installé dans le système temporaire pour fabriquer se base de données dans le système final).

• les Nbuilds ! il faudra je pense les mettre sur subversion aussi, pour tout ce qui est paquets officiels. Le même principe que pour Ncooker lui-même doit être décidé (parmi les trois solutions)

Pour récupérer Ncooker, soyons réaliste, on ne va pas compiler subversion et toutes ses dépendances ; il nous reste donc : récupérer dans le chroot le daily tarball ou en-dehors du chroot par subversion.

Le daily tarball est intéressant car on ne se soucie de pas grand chose, et cela peut être vérifié à chaque entrée dans le chroot. La récupération en-dehors du chroot peut être faite si on met un script automatisant le checkout ou update dans un répertoire de la cible. A voir ...

Il faut que le chroot soit utilisable à la fois dans Ngadkm et en-dehors. Cela veut dire qu’en prévision des étapes suivantes, on doit pouvoir lancer un script dans le chroot (utilisation dans le contexte de Ngadkm), ou lancer un simple shell (en dehors de Ngadkm).

Lancer un chroot ne signifie pas seulement exécuter la commande chroot, enfin pas dans notre cas. En effet, il y a quelques montages et fichiers de périphériques à faire, à la fois avant de rentrer et à l’intérieur du chroot. En effet, nous allons utiliser le montage udev, qui n’est pas initialisé dans le système temporaire (pas mal de device nodes son normalement créés à l’init).

Pour cela deux scripts inclus dans la distribution de Ngadkm seront installés dans le chroot. Le premier sera lancé par l’utilisateur (ou Ngadkm lui-même) et préparera le système avant l’entrée réelle dans le chroot. Le deuxième, appelé comme commande à exécuter dans le chroot, finira la préparation au sein même du chroot. Cette approche permet d’avoir une chaine d’entrée et de sortie très claire, et entièrement automatisée.

Je me suis posé la question d’intégrer un éditeur dans le système temporaire. En fait, ce n’est pas du tout obligatoire bien que plus pratique. Les fichiers peuvent être édités à partir du système hôte ; le seul hic est que cela doit être fait en tant que root, et donc faire un su ou un sudo. Avoir un éditeur inplace enlève ce point de détail, et le choix se porte vers un éditeur léger et rapide à construire : nano.

Il y a quelques étapes dans le libre LFS au début du chapitre 6, qui concernent le réajustement de la chaine de compilation, après la construction de la glibc :

• linux-libc-headers, nécessaire pour une compilation propre de glibc.
• man-pages, que je ne compte pas faire à ce moment (la raison de son inclusion avant glibc, puisque ce dernier n’en n’est pas dépendant au moment de la compilation ?)
• glibc, qui doit être le premier paquet installé (après sa dépendance linux-libc-headers of course)
• adjust-toolchain, qui réinstalle le linker de binutils (ld) à partir des sources sauvegardés de binutils, et modifie le fichier SPEC de gcc

Le mieux est d’effectuer ces étapes au sein de Ngadkm, avant de créer l’archive. On aura donc déjà une glibc, qu’on recompilera depuis le chroot final pour en faire un paquet. Cela permet :

• d’une part d’avoir une base utilisable (on ne fait que créer des paquets de manière classique)
• d’autre part de pouvoir ajuster le linker (ld dans binutils) à partir de sources conservées lors le la construction précédente, chose qui n’est pas possible (bien qu’apparemment cela ne pose pas de problème) si on lance les constructions a posteriori (on n’a pas intégré le build de binutils dans l’archive)

Par contre, cela implique de lancer certains builds dans le chroot (ces fameuses étapes du chapitre 6). Un nouveau paramètre dans le fichier de config de préparation du système temporaire est ajouté. En plus des 3 champs existants :

• nom du paquet
• version du paquet (à 0 si pas de notion de version)
• url de la ou des archives sources à télécharger

un champ d’option (avant le champ des urls) pourra prendre les valeurs suivantes :

• “-” aucune option
• “chroot” nécessite d’être exécuté dans le chroot
• “root” nécessite d’être exécuté en tant qu’utilisateur root

La valeur root a été rajoutée pour plus de flexibilité. En effet, avec ce nouveau champ, on peut décider par paquet s’il va être construit dans le chroot ou en tant que root. N’oublions pas qu’en parlant de paquet, on ne parle pas qu’en terme de projet logiciel classique, mais aussi de certaines étapes, comme l’ajustement de la chine de compilation, etc..

La valeur chroot implique bien-entendu un passage en root implicite.

Après avoir effectué toutes les étapes de construction du système temporaire, il faut faire deux choses :

• rajouter quelques trucs. Cela comprend quelques répertoires (dev, etc, proc, root, sys et usr/{bin,lib}), des fichiers de config dans /etc (passwd et group), des liens symboliques dans bin, usr/bin et usr/lib.
• modifier le propriétaire des fichiers pour root:root.

Si le deuxième point doit être effectué avec un su ou sudo, et donc de préférence comme un script (étape) de Ngadkm, le premier point lui pourrait être intégré comme un des scripts de l’étape précédente (construction du système temporaire), puisque de toute manière, par rapport aux permissions des fichiers (dont /etc/passwd et /etc/group), elles seront modifiées.

L’idée initiale de refaire le schéma de construction via make, avec un Makefile par paquet, ne me semble plus aussi intéressante qu’au début. En effet, après avoir vu ce qui se faisait en la matière, j’ai remarqué que ça impliquait une gestion des Makefile assez fine, avec beaucoup de règles et de variables. Je reste donc à mes bons vieux scripts shell.

Je vais tout de même essayer de mettre en place quelques fonctions qui automatisent les commandes récurrentes.

Avant de lancer la construction du système temporaire, il faut paramétrer un environnement clair et net, pour éviter tout effet de bord lié à ce dernier.

Le politique du précédent Ngadkm était de créer un utilisateur dédié sur le système hôte, avec un environnement minimal, et de lancer la construction depuis une session de cet utilisateur. Si ça paraissait pratique à première vue, ça a induit deux phénomènes :

• Ngadkm est trop instrusif dans le système hôte. On crée déjà un lien /tmpsys, l’ajout d’un utilisateur n’est pas foncièrement nickel, surtout si ce n’est pas strictement nécessaire (contrairement au dit lien)
• Les fichiers créés dans le système temporaire appartiennent tous à cet utilisateur. Si on veut y toucher manuellement, il faut ouvrir une session ou faire un su (ou sudo) pour se faire, pas très pratique.

La nouvelle solution vient de LFS lui-même. Lorsqu’on entre dans le chroot, on réduit au minimum les variables d’environnement déclarée en exécutant /tmpsys/bin/env en place d’un shell. On peut réutiliser cette astuce pour exécuter les commandes de construction à partir de la session actuelle (l’utilisateur qui lance Ngadkm), mais en les lançant via /usr/bin/env.

Pour fabriquer le système temporaire, on a besoin de préparer le répertoire cible de Nasgaïa :

• un répertoire tmpsys qui contriendra le système temporaire
• un lien à la racine du système hôte /tmpsys → <cible>/tmpsys qui reproduit sur ce dernier l’emplacement à la racine de ce répertoire

Le nom tmpsys n’est plus paramétrable, contrairement à la version précédente de Ngadkm. L’intérêt était vraiment limité, et cela apportait des problème de ‘compatibilité’ des système générés (le tarball) s’il était modifié.

Le répertoire cible est automatiquement vérifié au lancement de Ngadkm pour donner le statut de propriétaire à l’utilisateur qui le lance. Pour l’instant, il est prévu de mettre à jour les permissions pour le répertoire cible lui-lême, plus les répertoires racine pré-créés par Ngadkm avant le build (ou lors d’une reprise).

On pourra voir pour rajouter une option ou un test pour régler les permissions de tout le contenu du répertoire cible, dans le cas où l’utilisateur qui lance Ngadkm n’est pas le même qu’au précédent lancement. Pour une option, ce sera désactivé. Si on choisi de tester, il faudra trouver un bon test (fiable).

Je ne vais pas rentrer dans le détail des paramètres de Ngadkm, car ceux-ci se présenterons de facto lorsque le besoin se fera sentir. Je vais plutot aborder le problème de la configuration initiale et de la personnalisation pour chacun.

En effet, tout le monde ne souhaite pas construire son système sur le même support. Si la majorité d’entre nous utilisons pour ces tests un système de fichiers monté, d’autres peuvent choisir d’autres solutions :

• un simple répertoire dans son home
• une image disque montée en loopback
• plusieurs systèmes de fichiers montés (comme /boot, /usr, etc..)

Aujourd’hui Ngadkm supporte ces trois méthodes via les options (dans ngadkm.conf) $DK_DEVICE, $DK_DEVICE_FS et $DK_TARGET. Voir la référence des options dans ngadkm.conf pour plus de précisions.

On peut maintenant choisir complètement le programme utilisé pour passer root, via $DK_SUCMD.

• Ngdkm - le script principal
• conf - le répertoire contenant tous les fichiers de configuration
• doc - les docs de l’outil, HOWTO pour l’utiliser et explication des choix par rapport à LFS
• scripts - les scripts appelés par Ngadkm. Ce répertoire contiendra des sous-répertoire correspondant à chaque grande étape de la génération
• work - le répertoire de travail. Il sera copié dans le système temporaire pour plus de souplesse lorsqu’on devra effectuer des constructions dans le chroot. Il contient les sous-répertoires suivants:
  • archives - les tarballs sources téléchargés ou fournis par l’outil
  • build - l’endroit ou le résultat de la construction (avant installation dans le répertoire cible) est placé
  • log - trace de ce qui est fait. Contient aussi la base de données de ngadkm, celle qui lui permet de savoir où il en est
  • sources - archives décompressées (la construction ne se fait pas dans le même répertoire que la décompression, sauf pour les paquets ne nécessitant qu’une copie)

Indique quel est le type de la cible et quel périphérique attaquer. Ngadkm supporte trois type de cibles:

syntaxe : DK_DEVICE=”dir”

description : un simple répertoire, pas besoin d’en dire plus, voir DK_TARGET ci-après.

syntaxe : DK_DEVICE=”part /dev/fd_partition”

description : une partition, prend le nom d’un fichier de périphérique en paramètre. La partition doit bien-sûr exister.

exemple : DK_DEVICE=”part /dev/hdc8”

syntaxe : DK_DEVICE=”loop <fichier image>”

description : un fichier image, prend le nom d’un fichier d’image disque en paramètre. L’image doit bien-sûr avoir été correctement initialisée. Pour créer un fichier image, exécutez dd if=/dev/zero of=/nom/de/votre/fichier/image bs=1024 count=<taille de kilo-octet> (par exemple 2*1024*1024 pour 2Go).

exemple : DK_DEVICE=”loop /home/riri/nasgaia/tests/ngadkm-img.dsk”

Utilisé uniquement pour les types part et loop. Indique le type de système de fichiers dans la cible. Cela permet à Ngadkm de créer ce système de fichiers s’il n’existe pas, et de le monter (en donnant explicitement le type de système de fichiers à mount).

syntaxe : DK_DEVICE_FS=”<type> [<options>]”

Le type est le type de système de fichiers à créer. Ce type doit être supporté par le système hôte (tant au niveau noyau qu’à la présence d’outils pour le gérer). Pour savoir quels types de systèmes de fichiers sont supportés chez vous, lancez : ls /sbin/mkfs.* ; c’est aussi ce que lancera Ngadkm pour déterminer la même chose :-). Le type que vous devez mettre correspond à la partie après /sbin/mkfs. (en bref ls /sbin/mkfs.* | sed -e ‘s@/sbin/mkfs.@@’ ).

Les options sont optionnelles et seront ajoutées aux options passées à mkfs. Cela peut servir par exemple à donner un label ou un pourcentage d’espace réservé différent de 5% pour les système ext2/3.

exemple : DK_DEVICE_FS=”ext3 -m 1 -L ngadkm”

Il s’agit de la cible de Ngadkm (répertoire pour le type dir ou point de montage pour part et loop). Mis à part le lien /tmpsys créé au début, DK_TARGET sera le seul et unique répertoire sur votre système hôte modifié par Ngadkm.

Ngadkm a besoin de passer root pour effectuer certaines actions, comme la préparation de la cible (mkfs, mount, etc..). Pour se faire, il utilisera la commande définie dans cette option et ajoutera le nom d’un script à cette commande (pour exécuter le script sous root). Cela permet de choisir le programme permettant cet accès, ainsi que de choisir les paramètres qui vont bien. Les deux choix les plus courants seront :

• su -c qui utilisera la forme simple de su
• sudo qui utilisera la forme simple de sudo (on peut dire que sudo -P est assez courant également)