Buildroot - partie 2. Création de la configuration de votre carte ; en utilisant une arborescence externe, une superposition rootfs, des scripts de post-construction

Dans cette section, j'examine certaines des options de personnalisation dont j'avais besoin. Ce n'est pas une liste complète de ce que propose buildroot, mais ils sont tout à fait fonctionnels et ne nécessitent pas d'intervention dans les fichiers de buildroot lui-même.

Utilisation du mécanisme EXTERNE pour la personnalisation

Dans un article précédent Nous avons examiné un exemple simple d'ajout de votre propre 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. Il existe un mécanisme pour résoudre ce problème arbre externe. Son essence est que vous pouvez stocker la carte, les configurations, les packages et autres répertoires dans un répertoire séparé (par exemple, j'utilise le répertoire patches pour appliquer des correctifs aux packages, plus de détails dans une section séparée) et buildroot lui-même les ajoutera à ceux de son répertoire.

Remarque : vous pouvez superposer plusieurs arborescences externes à la fois, il y a un exemple dans le manuel buildroot

Créons un répertoire my_tree, situé à côté du répertoire buildroot et transférons-y notre configuration. Le résultat doit être la structure de fichier 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 directories, 7 files

Comme vous pouvez le voir, en général, la structure répète la structure de buildroot.

annuaire planche contient des fichiers spécifiques à chaque carte dans notre cas :

• bef_cr_fs_img.sh est un script qui sera exécuté après la construction du système de fichiers cible, mais avant de l'empaqueter en images. Nous l'utiliserons à l'avenir
• linux.config - configuration du noyau
• rootfs_overlay - répertoire à superposer au-dessus du système de fichiers cible
• users.txt - un fichier décrivant les utilisateurs à créer

annuaire configs contient defconfig de nos cartes. Nous n'en avons qu'un.

Forfait - catalogue avec nos forfaits. Initialement, buildroot contient des descriptions et des règles pour construire un nombre limité de packages. Plus tard, nous ajouterons ici le gestionnaire de fenêtres icewm et le gestionnaire de connexion graphique Slim.
Patches - vous permet de stocker facilement vos correctifs pour différents packages. Plus de détails dans une section distincte ci-dessous.
Nous devons maintenant ajouter les fichiers de description de notre arborescence externe. Il y a 3 fichiers responsables de cela : external.desc, Config.in, external.mk.

externe.desc contient la description réelle :

[alexey@alexey-pc my_tree]$ cat external.desc 
name: my_tree
desc: My simple external-tree for article

La première ligne est le titre. Dans le futur, buildroot crée une variable $(BR2_EXTERNAL_MY_TREE_PATH), qui doit être utilisé lors de la configuration de l’assembly. Par exemple, le chemin d'accès au fichier utilisateur peut être défini comme suit :

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

La deuxième ligne est une courte description lisible par l’homme.

Config.in, externe.mk - des 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 arborescence externe prête, contenant la configuration def de notre carte et les fichiers dont elle a besoin. Allons dans le répertoire buildroot et spécifions d'utiliser external-tree :

[alexey@alexey-pc buildroot]$ make BR2_EXTERNAL=../my_tree/ my_x86_board_defconfig
#
# configuration written to /home/alexey/dev/article/ramdisk/buildroot/.config
#
[alexey@alexey-pc buildroot]$ make menuconfig

Dans la première commande, nous utilisons l'argument BR2_EXTERNAL=../mon_arbre/, indiquant l'utilisation d'une arborescence externe. Vous pouvez spécifier plusieurs arborescences externes à utiliser en même temps. Dans ce cas, vous ne devez le faire qu'une seule fois, après quoi un fichier output/.br-external.mk est créé qui stocke des informations sur l'arborescence externe utilisée :

[alexey@alexey-pc buildroot]$ cat output/.br-external.mk 
#
# Automatically generated file; DO NOT EDIT.
#

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 = My simple external-tree for article

Important! Les chemins dans ce fichier seront absolus !

Un élément Options externes est apparu dans le menu :

Ce sous-menu contiendra nos packages de notre arborescence externe. Cette section est actuellement vide.

Il est maintenant plus important pour nous de réécrire les chemins nécessaires pour utiliser l'arborescence externe.

Veuillez noter que dans la section Options de construction → Emplacement pour enregistrer la configuration buildroot, il y aura un chemin absolu vers la configuration defconfig enregistrée. Il est formé au moment de spécifier l'utilisation de extgernal_tree.

Nous corrigerons également les chemins dans la section Configuration du système. Pour une table avec des utilisateurs créés :

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

Dans la section Kernel, modifiez le chemin d'accès à la configuration du noyau :

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

Désormais, nos fichiers de notre arborescence externe seront utilisés lors de l'assemblage. Lors du déplacement vers un autre répertoire ou de la mise à jour du buildroot, nous aurons un minimum de problèmes.

Ajout de la superposition root fs :

Ce mécanisme vous permet d'ajouter/remplacer facilement des fichiers dans le système de fichiers cible.
Si le fichier est dans la superposition root fs, mais pas dans la cible, alors il sera ajouté
Si le fichier est dans la superposition root fs et dans la cible, il sera remplacé.
Tout d’abord, définissons le chemin vers le répertoire de superposition root fs. Cela se fait dans la section Configuration du système → Répertoires de superposition du système de fichiers racine :

$(BR2_EXTERNAL_my_tree_PATH)/board/my_x86_board/rootfs_overlay/

Créons maintenant 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 
This is new file from overlay

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

Nous collectons et vérifions :

Exécution de scripts de personnalisation à différentes étapes de l'assemblage du système

Souvent, vous devez effectuer certains travaux à l'intérieur du système de fichiers cible avant qu'il ne soit empaqueté en images.

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

Les deux premiers scripts sont exécutés après la création du système de fichiers cible, mais avant qu'il ne soit conditionné en images. La différence est que le script fakeroot est exécuté dans le contexte de fakeroot, qui simule le travail en tant qu'utilisateur root.

Le dernier script est exécuté après la création des images système. Vous pouvez y effectuer des actions supplémentaires, par exemple copier les fichiers nécessaires sur un serveur NFS ou créer une image du micrologiciel de votre appareil.

À titre d'exemple, je vais créer un script qui écrira la version et la date de build dans /etc/.
Je vais d'abord indiquer le chemin de ce fichier dans mon arborescence externe :

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 pre alpha" > output/target/etc/mysmalllinux-release
date >> output/target/etc/mysmalllinux-release

Après l'assemblage, vous pouvez voir ce fichier sur le système.

En pratique, le script peut devenir volumineux. Par conséquent, dans le projet réel, j’ai emprunté une voie plus avancée :

1. J'ai créé un répertoire (my_tree/board_my_x86_board/inside_fakeroot_scripts) dans lequel se trouvent des scripts à exécuter, avec des numéros de série. 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 séquentiellement les scripts qu'il contient
3. Spécifié ce script dans les paramètres de la carte dans la section Configuration 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