introduction
Dans cette série d'articles, je souhaite examiner le système de build de la distribution buildroot et partager mon expérience dans sa personnalisation. Il y aura une expérience pratique dans la création d'un petit système d'exploitation avec une interface graphique et des fonctionnalités minimales.
Tout d’abord, il ne faut pas confondre le système de build et la distribution. Buildroot peut construire un système à partir d'un ensemble de packages qui lui sont proposés. Buildroot est construit sur des makefiles et possède donc d'énormes capacités de personnalisation. Remplacer un package par une autre version, ajouter votre propre package, modifier les règles de construction d'un package, personnaliser le système de fichiers après avoir installé tous les packages ? buildroot peut faire tout cela.
En Russie, buildroot est utilisé, mais à mon avis, il existe peu d'informations en russe pour les débutants.
Le but du travail est d'assembler un kit de distribution avec téléchargement en direct, interface icewm et navigateur. La plateforme cible est virtualbox.
Pourquoi créer votre propre distribution ? Des fonctionnalités souvent limitées sont nécessaires avec des ressources limitées. Encore plus souvent, en automatisation, vous devez créer un firmware. Adapter une distribution à usage général en nettoyant les paquets inutiles et en la transformant en micrologiciel demande plus de travail que de créer une nouvelle distribution. Utiliser Gentoo a aussi ses limites.
Le système Buildroot est très puissant, mais il ne fera rien pour vous. Il ne peut qu'activer et automatiser le processus d'assemblage.
Les systèmes de build alternatifs (yocto, open build system et autres) ne sont ni pris en compte ni comparés.
Où l'obtenir et comment commencer
Site Web du projet - . Ici, vous pouvez télécharger la version actuelle et lire le manuel. Là, vous pouvez contacter la communauté, il y a un outil de suivi des bogues, des listes de diffusion et un canal IRC.
Buildroot exploite les defconfigs pour la carte cible de la build. Defconfig est un fichier de configuration qui stocke uniquement les options qui n'ont pas de valeurs par défaut. C'est lui qui détermine ce qui sera collecté et comment. Dans ce cas, vous pouvez configurer séparément les configurations des chargeurs de démarrage busybox, linux-kernel, uglibc, u-boot et barebox, mais tous seront liés à la carte cible.
Après avoir décompressé l'archive téléchargée ou cloné depuis git, nous obtenons un buildroot prêt à l'emploi. Vous pouvez en savoir plus sur la structure des répertoires dans le manuel ; je vais vous parler des plus importants :
planche — un répertoire avec des fichiers spécifiques à chaque carte. Il peut s'agir de scripts pour former des images système (iso, sdcart, cpio et autres), d'un répertoire de superposition, d'une configuration du noyau, etc.
configs — la configuration réelle de la carte. Defconfig est une configuration de carte incomplète. Il stocke uniquement les paramètres qui diffèrent des paramètres par défaut
dl — répertoire avec les codes sources/fichiers téléchargés pour l'assemblage
sortie/cible — le système de fichiers assemblé du système d'exploitation résultant. Par la suite, des images sont créées à partir de celui-ci pour le téléchargement/l'installation
sortie/hôte - utilitaires hôtes pour l'assemblage
sortie/construction - colis assemblés
L'assemblage est configuré via KConfig. Le même système est utilisé pour construire le noyau Linux. Liste des commandes les plus couramment utilisées (exécutées dans le répertoire buildroot) :
- make menuconfig - appelle la configuration de construction. Vous pouvez également utiliser l'interface graphique (make nconfig, make xconfig, make gconfig)
- make linux-menuconfig - appelle la configuration du noyau.
- make clean - nettoie les résultats de la construction (tout ce qui est stocké dans la sortie)
- make - construire un système. Cela ne réassemble pas les processus déjà assemblés.
- make defconfig_name - bascule la configuration vers un defconfig spécifique
- make list-defconfigs - afficher une liste de defconfigs
- make source - téléchargez simplement les fichiers d'installation, sans construire.
- make help - liste les commandes possibles
Notes importantes et conseils utiles
Buildroot ne reconstruit pas les packages déjà construits ! Par conséquent, une situation peut survenir où un remontage complet est nécessaire.
Vous pouvez reconstruire un package séparé avec la commande make packagename-rebuild. Par exemple, vous pouvez reconstruire le noyau Linux :
make linux-rebuildBuildroot stocke l'état de n'importe quel package en créant des fichiers .stamp dans le répertoire output/build/$packagename :
Par conséquent, vous pouvez reconstruire les fichiers root et les images sans reconstruire les packages :
rm output/build/host-gcc-final-*/.stamp_host_installed;rm -rf output/target;find output/ -name ".stamp_target_installed" |xargs rm -rf ; makeVariables utiles
buildroot a un ensemble de variables pour une configuration facile
- $TOPDIR - répertoire buildroot
- $BASEDIR - Répertoire de SORTIE
- $HOST_DIR, $STAGING_DIR, $TARGET_DIR — répertoires de construction du fs hôte, fs intermédiaire, fs cible.
- $BUILD_DIR - répertoire avec les packages décompressés et construits
Visualisation
buildroot a une fonctionnalité de visualisation. Vous pouvez créer un diagramme de dépendances, un graphique du temps de construction et un graphique de la taille des packages dans le système final. Les résultats sont sous forme de fichiers pdf (vous pouvez choisir parmi svn, png) dans le répertoire output/graph.
Exemples de commandes de visualisation :
make graph-dependsconstruire un arbre de dépendancesmake <pkg>-graph-dependscréer un arbre de dépendances pour un package spécifiqueBR2_GRAPH_OUT=png make graph-buildtemps de construction du tracé avec sortie PNGmake graph-sizetaille du paquet de tracé
Scripts utiles
Il y a un sous-répertoire dans le répertoire buildroot utils avec des scripts utiles. Par exemple, il existe un script qui vérifie l'exactitude des descriptions des packages. Cela peut être utile lors de l'ajout de vos propres packages (je le ferai plus tard). Le fichier utils/readme.txt contient une description de ces scripts.
Construisons une distribution de stock
Il est important de se rappeler que toutes les opérations sont effectuées au nom d'un utilisateur régulier et non de root.
Toutes les commandes sont exécutées dans le buildroot. Le package buildroot comprend déjà un ensemble de configurations pour de nombreuses cartes et virtualisations courantes.
Regardons la liste des configurations :
Basculez vers la configuration qemu_x86_64_defconfig
make qemu_x86_64_defconfigEt nous commençons l'assemblage
makeLa construction se termine avec succès, regardez les résultats :
Buildroot a compilé des images que vous pouvez exécuter dans Qemu et vérifier qu'elles fonctionnent.
qemu-system-x86_64 -kernel output/images/bzImage -hda output/images/rootfs.ext2 -append "root=/dev/sda rw" -s -SLe résultat est un système fonctionnant dans qemu :
Créer votre propre configuration de carte
Ajout de fichiers de carte
Regardons la liste des configurations :
Dans la liste, nous voyons pc_x86_64_efi_defconfig. Nous allons créer notre propre tableau en le copiant depuis la configuration :
cp configs/pc_x86_64_bios_defconfig configs/my_x86_board_defconfigCréons immédiatement un répertoire board pour stocker nos scripts, rootfs-overlay et autres fichiers nécessaires :
mkdir board/my_x86_boardBasculez vers ce defconfig :
make my_x86_board_defconfigAinsi, la configuration de build (stockée dans .config à la racine du répertoire buildroot) correspond désormais à la machine cible de démarrage x86-64 (bios).
Copions la configuration du noyau Linux (utile plus tard) :
cp board/pc/linux.config board/my_x86_board/Définition des paramètres de construction via KConfig
Commençons la configuration :
make menuconfig La fenêtre KConfig s'ouvrira. Il est possible de configurer avec une interface graphique (make nconfig, make xconfig, make gconfig) :
Nous entrons dans la première section Options cibles. Ici, vous pouvez sélectionner l'architecture cible pour laquelle la construction sera effectuée.
Options de construction - il existe différents paramètres de construction ici. Vous pouvez spécifier des répertoires avec les codes sources, le nombre de threads de construction, des miroirs pour télécharger les codes sources et d'autres paramètres. Laissons les paramètres par défaut.
Chaîne d'outils – les outils de construction eux-mêmes sont configurés ici. En savoir plus sur lui.
Type de chaîne d'outils – type de chaîne d'outils utilisée. Il peut s'agir d'une chaîne d'outils intégrée à buildroot ou externe (vous pouvez spécifier le répertoire avec celui déjà construit ou l'URL de téléchargement). Il existe des options supplémentaires pour différentes architectures. Par exemple, pour arm, vous pouvez simplement sélectionner la version Linaro de la chaîne d'outils externe.
Bibliothèque C – sélection de la bibliothèque C. Le fonctionnement de l’ensemble du système en dépend. Généralement, la glibc est utilisée, qui prend en charge toutes les fonctionnalités possibles. Mais il peut être trop volumineux pour un système embarqué, c'est pourquoi uglibc ou musl sont souvent choisis. Nous sélectionnerons la glibc (cela sera nécessaire plus tard pour utiliser systemd).
Séries Kernel Headers et Custom Kernel Headers – doivent correspondre à la version du noyau qui sera dans le système assemblé. Pour les en-têtes du noyau, vous pouvez également spécifier le chemin d'accès à l'archive tar ou au référentiel git.
VERSIONS DU COMPILATEUR GCC – sélectionnez la version du compilateur à utiliser pour la construction
Activer la prise en charge C++ – sélectionnez pour créer avec la prise en charge des bibliothèques C++ dans le système. Cela nous sera utile à l'avenir.
Options gcc supplémentaires – vous pouvez définir des options supplémentaires du compilateur. Nous n’en avons pas besoin pour l’instant.
La configuration du système vous permet de définir les futurs paramètres du système créé :
La plupart des points ressortent clairement du titre. Faisons attention aux points suivants :
Chemin d'accès aux tables des utilisateurs - table avec les utilisateurs à créer ().
Exemple de fichier. L'utilisateur sera créé avec le mot de passe admin, automatiquement gid/uid, /bin/sh shell, utilisateur de groupe par défaut, racine du membre du groupe, commentaire Foo user
[alexey@alexey-pc buildroot ]$ cat board/my_x86_board/users.txt
user -1 user -1 =admin /home/user /bin/sh root Foo userRépertoires de superposition du système de fichiers racine - répertoire superposé au-dessus du fs cible assemblé. Ajoute de nouveaux fichiers et remplace ceux existants.
Scripts personnalisés à exécuter avant de créer des images du système de fichiers : Scripts exécutés immédiatement avant de plier le système de fichiers en images. Laissons le script vide pour l'instant.
Passons à la section Kernel
Les paramètres du noyau sont définis ici. Le noyau lui-même est configuré via make linux-menuconfig.
Vous pouvez définir la version du noyau de différentes manières : sélectionnez parmi celles proposées, saisissez la version manuellement, spécifiez un référentiel ou une archive tar prête à l'emploi.
Configuration du noyau — chemin d'accès à la configuration du noyau. Vous pouvez sélectionner la configuration par défaut pour l'architecture sélectionnée ou defocnfig depuis Linux. La source Linux contient un ensemble de configurations def pour différents systèmes cibles. Vous pouvez trouver celui dont vous avez besoin . Par exemple, pour un tableau noir en os de beagle, vous pouvez .
La section Packages cibles vous permet de sélectionner les packages qui seront installés sur le système en cours de construction. Laissons cela inchangé pour l'instant. Nous ajouterons nos forfaits à cette liste plus tard.
Images du système de fichiers : une liste d’images du système de fichiers qui seront collectées. Ajouter une image iso
Bootloaders - sélection de bootloaders à collecter. Choisissons isolinix
Configuration de Systemd
Systemd devient l'un des piliers de Linux, aux côtés du noyau et de la glibc. Par conséquent, j'ai déplacé son paramètre vers un élément distinct.
Configuré via make menuconfig, puis Packages cibles → Outils système → systemd. Ici, vous pouvez spécifier quels services systemd seront installés et démarrés au démarrage du système.
Sauvegarde de la configuration du système
Nous sauvegardons cette configuration via KConfig.
Enregistrez ensuite notre defconfig :
make savedefconfigConfiguration du noyau Linux
La configuration du noyau Linux est invoquée avec la commande suivante :
make linux-menuconfigAjoutons la prise en charge de la carte vidéo Virtualbox
Ajoutons la prise en charge de l'intégration Virtualbox Guest
Sauvegarder et quitter. IMPORTANT: la configuration sera enregistrée dans output/build/linux-$version/config, mais pas dans board/my_x86_board/linux.config
Par conséquent, vous devez copier manuellement la configuration vers un emplacement de stockage :
cp output/build/linux-4.19.25/.config board/my_x86_board/linux.configAprès quoi nous procéderons à un remontage complet de l’ensemble du système. buildroot ne reconstruit pas ce qui a déjà été construit, vous devez spécifier manuellement les packages à reconstruire. Afin de ne pas perdre de temps et de nerfs, il est plus facile de reconstruire entièrement un petit système) :
make clean;makeUne fois le build terminé, lancez VirtualBox (testé sur les versions 5.2 et 6.0) en démarrant à partir du CD. Paramètres système :
Exécuté à partir de l'iso assemblé :
Liste des matériaux utilisés
- Manuel de construction de Root
Source: habr.com