Buildroot — partie 2. Création de la configuration de votre carte ; utilisation de l'arbre externe, rootfs-overlay, scripts post-build

Dans cette section, je discute des options de personnalisation qui m'ont été nécessaires. Ce n'est pas une liste exhaustive de ce que propose buildroot, mais elles sont toutes fonctionnelles et ne nécessitent pas d'intervention dans les fichiers de buildroot.

Utilisation du mécanisme EXTERNAL pour la personnalisation

Dans l'article précédent Nous avons examiné un exemple simple d'ajout de notre configuration, en ajoutant le defconfig de la carte et les fichiers nécessaires directement dans le répertoire Buildroot.

Mais cette méthode n'est pas très pratique, surtout lors de la mise à jour de buildroot. Pour résoudre ce problème, il existe un mécanisme external tree. Son principe est qu'il est possible de stocker dans un répertoire distinct les répertoires board, configs, packages et autres (par exemple, j'utilise un répertoire patches pour appliquer des correctifs aux paquets, plus de détails dans une section séparée) et buildroot les ajoutera lui-même à ceux existants dans son répertoire.

Remarque : plusieurs external trees peuvent être appliqués simultanément, un exemple est donné dans le guide buildroot

Créons un répertoire my_tree, situé à côté du répertoire de buildroot, et déplaçons-y notre configuration. Nous devons obtenir la structure de fichiers suivante :

[alexey@alexey-pc my_tree]$ tree
.
├── board
│   └── my_x86_board
│       ├── bef_cr_fs_img.sh
│       ├── linux.config
│       ├── rootfs_overlay
│       └── users.txt
├── Config.in
├── configs
│   └── my_x86_board_defconfig
├── external.desc
├── external.mk
├── package
└── patches

6 répertoires, 7 fichiers

Comme on peut le voir, la structure imite globalement la structure de buildroot.

Le répertoire board contient des fichiers spécifiques à chaque carte dans notre cas :

• bef_cr_fs_img.sh — script qui sera exécuté après la construction du système de fichiers cible, mais avant de l'emballer dans des images. Nous l'utiliserons plus tard
• linux.config — configuration du noyau
• rootfs_overlay — répertoire pour superposer sur le système de fichiers cible
• users.txt — fichier décrivant les utilisateurs créés

Le répertoire configs contient les defconfig de nos cartes. Nous n'en avons qu'un.

Package — répertoire avec nos paquets. Initialement, buildroot contient des descriptions et des règles de construction pour un nombre limité de paquets. Plus tard, nous ajouterons ici le gestionnaire de fenêtres icewm et le gestionnaire de connexion graphique Slim.
Patches — permet de stocker facilement vos correctifs pour différents paquets. Plus de détails dans une section séparée ci-après.
Nous devons maintenant ajouter les fichiers de description de notre external-tree. Trois fichiers sont responsables de cela : external.desc, Config.in, external.mk.

external.desc contient la description proprement dite :

[alexey@alexey-pc my_tree]$ cat external.desc 
name: my_tree
desc: Mon simple external-tree pour l'article

La première ligne est le nom. Par la suite, buildroot créera une variable $(BR2_EXTERNAL_MY_TREE_PATH), qui devra être utilisée lors de la configuration de la compilation. Par exemple, le chemin vers le fichier contenant les utilisateurs peut être défini de la manière suivante :

$(BR2_EXTERNAL_my_tree_PATH)\/board\/my_x86_board\/users.txt

La deuxième ligne est une description courte et compréhensible.

Config.in, external.mk sont les fichiers pour décrire les packages ajoutés. Si vous n'ajoutez pas vos propres packages, ces fichiers peuvent rester vides. Pour l'instant, c'est ce que nous allons faire.
Nous avons maintenant notre external-tree prêt, contenant le defconfig de notre carte et les fichiers nécessaires. Passons au répertoire de buildroot pour indiquer l'utilisation de l'external-tree :

[alexey@alexey-pc buildroot]$ make BR2_EXTERNAL=..\/my_tree\/ my_x86_board_defconfig
#
# configuration écrite dans \/home\/alexey\/dev\/article\/ramdisk\/buildroot\/.config
#
[alexey@alexey-pc buildroot]$ make menuconfig

Dans la première commande, nous utilisons l'argument BR2_EXTERNAL=..\/my_tree\/, qui indique l'utilisation de l'external tree. On peut spécifier plusieurs external-trees en même temps. Il suffit de le faire une seule fois, après quoi un fichier output\/.br-external.mk est créé, contenant des informations sur l'external-tree utilisé :

[alexey@alexey-pc buildroot]$ cat output\/.br-external.mk 
#
# Fichier généré automatiquement ; NE PAS ÉDITER.
#

BR2_EXTERNAL ?= \/home\/alexey\/dev\/article\/ramdisk\/my_small_linux\/my_tree
BR2_EXTERNAL_NAMES = 
BR2_EXTERNAL_DIRS = 
BR2_EXTERNAL_MKS = 

BR2_EXTERNAL_NAMES += my_tree
BR2_EXTERNAL_DIRS += \/home\/alexey\/dev\/article\/ramdisk\/my_small_linux\/my_tree
BR2_EXTERNAL_MKS += \/home\/alexey\/dev\/article\/ramdisk\/my_small_linux\/my_tree\/external.mk
export BR2_EXTERNAL_my_tree_PATH = \/home\/alexey\/dev\/article\/ramdisk\/my_small_linux\/my_tree
export BR2_EXTERNAL_my_tree_DESC = Mon simple external-tree pour l'article

Important ! Dans ce fichier, les chemins seront absolus !

Une option External options est apparue dans le menu :

Ce sous-menu contiendra nos packages de notre external-tree. Pour l'instant, cette section est vide.

Il est maintenant plus important pour nous de réécrire les chemins nécessaires pour utiliser l'external-tree.

Notez que dans la section Build options → Location to save buildroot config, il y aura un chemin absolu vers le defconfig sauvegardé. Celui-ci se forme au moment de l'indication de l'utilisation de l'external_tree.

Dans la section System configuration, nous corrigerons également les chemins. Pour le tableau des utilisateurs créés :

$(BR2_EXTERNAL_my_tree_PATH)\/board\/my_x86_board\/users.txt

Dans la section Kernel, changez le chemin de la configuration du noyau :

$(BR2_EXTERNAL_my_tree_PATH)\/board\/my_x86_board\/linux.config

Désormais, lors de la construction, nos fichiers de notre external-tree seront utilisés. Lors du déplacement vers un autre répertoire, la mise à jour de buildroot entraînera un minimum de problèmes.

Ajout de l'overlay du système de fichiers racine :

Ce mécanisme permet d'ajouter/remplacer facilement des fichiers dans le système de fichiers cible.
Si un fichier est présent dans l'overlay du système de fichiers racine, mais absent dans la cible, il sera ajouté.
Si un fichier est présent à la fois dans l'overlay du système de fichiers racine et dans la cible, il sera remplacé.
D'abord, définissons le chemin vers le répertoire d'overlay du système de fichiers racine. Cela se fait dans la section Configuration du système → Répertoires d'overlay du système de fichiers racine :

$(BR2_EXTERNAL_my_tree_PATH)/board/my_x86_board/rootfs_overlay/

Nous allons maintenant créer deux fichiers.

[alexey@alexey-pc my_small_linux]$ cat my_tree/board/my_x86_board/rootfs_overlay/etc/hosts 
127.0.0.1   localhost
127.0.1.1   my_small_linux
8.8.8.8     google-public-dns-a.google.com.
[alexey@alexey-pc my_small_linux]$ cat my_tree/board/my_x86_board/rootfs_overlay/new_file.txt 
Ceci est un nouveau fichier de l'overlay.

Le premier fichier (my_tree/board/my_x86_board/rootfs_overlay/etc/hosts) remplacera le fichier /etc/hosts dans le système final. Le deuxième fichier (cat my_tree/board/my_x86_board/rootfs_overlay/new_file.txt) sera ajouté.

Nous construisons et vérifions :

Exécution de scripts de personnalisation à différentes étapes de la construction du système.

Il est souvent nécessaire d'effectuer certaines actions dans le système de fichiers cible avant qu'il ne soit empaqueté dans des images.

Cela peut être fait dans la section Configuration du système :

Les deux premiers scripts s'exécutent après la construction du système de fichiers cible, mais avant son empaquetage dans des images. La différence est que le script fakeroot s'exécute dans le contexte de fakeroot, simulant l'exécution par l'utilisateur root.

Le dernier script s'exécute déjà après la création des images du système. Dans celui-ci, vous pouvez effectuer des actions supplémentaires, comme copier des fichiers nécessaires sur un serveur NFS ou créer une image de votre firmware.

À titre d'exemple, je vais créer un script qui écrira la version et la date de construction dans /etc/
Tout d'abord, je vais spécifier le chemin vers ce fichier dans mon external-tree :

Et maintenant le script lui-même :

[alexey@alexey-pc buildroot]$ cat ../my_tree/board/my_x86_board/bef_cr_fs_img.sh 
#! /bin/sh
echo "my small linux 1.0 pré-alpha" > output/target/etc/mysmalllinux-release
date >> output/target/etc/mysmalllinux-release

Après la construction, ce fichier peut être vu dans le système.

Dans la pratique, le script peut devenir long. C'est pourquoi, dans un projet réel, j'ai choisi une approche plus avancée :

1. J'ai créé un répertoire (my_tree/board_my_x86_board/inside_fakeroot_scripts) contenant des scripts à exécuter, numérotés. Par exemple, 0001-add-my_small_linux-version.sh, 0002-clear-apache-root-dir.sh.
2. J'ai écrit un script (my_tree/board_my_x86_board/run_inside_fakeroot.sh) qui parcourt ce répertoire et exécute successivement les scripts qui s'y trouvent.
3. J'ai spécifié ce script dans les paramètres de la carte dans la section Configuration du système -> Scripts personnalisés à exécuter dans l'environnement fakeroot ($(BR2_EXTERNAL_my_tree_PATH)/board/my_x86_board/run_inside_fakeroot.sh).

Source : habr.com