В този раздел разглеждам част от възможностите за персонализация, от които имах нужда. Това не е пълен списък на това, което предлага buildroot, но те са напълно работещи и не изискват намеса в самите файлове на buildroot.
Използване на EXTERNAL механизъм за персонализация
беше разгледан прост пример за добавяне на собствена конфигурация, чрез добавяне на defconfig файл за платка и необходимите файлове директно в каталога на Buildroot.
Но този метод не е много удобен, особено при актуализиране на buildroot. За решение на този проблем има механизъм external tree. Идеята му е, че в отделен каталог можете да съхранявате каталози board, configs, packages и други (например, аз използвам каталог patches за налагане на пачове на пакети, повече подробности в отделен раздел) и buildroot автоматично ще ги добавя към съществуващите в своя каталог.
Забележка: можете да наложите няколко external tree наведнъж, има пример в ръководството на buildroot
Създаваме каталог my_tree, разположен до каталога на buildroot и прехвърляме там нашата конфигурация. На изхода трябва да получим следната структура на файловете:
[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Както се вижда, общата структура повтаря структурата на buildroot.
Директория board съдържа файлове, специфични за всяка платка в нашия случай:
- bef_cr_fs_img.sh — скрипт, който ще се изпълни след изграждането на target файловата система, но преди опаковането ѝ в изображения. Впоследствие ще го използваме
- linux.config — конфигурация на ядрото
- rootfs_overlay — каталог за налагане върху target файловата система
- users.txt — файл с описание на създадените потребители
Директория configs съдържа defconfig файловете на нашите платки. Имаме само един.
Package — каталог с нашите пакети. Първоначално buildroot съдържа описания и правила за изграждане на ограничен брой пакети. По-късно ще добавим тук мениджъра на прозорци icewm и мениджъра за графичен вход в системата Slim.
Patches — позволява удобно съхранение на нашите пачове за различни пакети. Повече подробности в отделен раздел по-долу.
Сега е необходимо да добавим файловете с описание на нашето external-tree. За това отговарят 3 файла: external.desc, Config.in, external.mk.
external.desc съдържа самото описание:
[alexey@alexey-pc my_tree]$ cat external.desc
name: my_tree
desc: Моя простая внешняя деревоподобная структура для статьиПървият ред е името. По-късно buildroot ще създаде променлива $(BR2_EXTERNAL_MY_TREE_PATH), която трябва да се използва при конфигуриране на сборката. Например, пътят до файла с потребители може да бъде зададен по следния начин:
$(BR2_EXTERNAL_my_tree_PATH)/board/my_x86_board/users.txtВторият ред е кратко, ясно описание.
Config.in, external.mk — файлове за описание на добавените пакети. Ако не добавяте свои пакети, тези файлове могат да останат празни. За сега ще постъпим точно така.
Сега имаме готово наше external-tree, съдържащо defconfig на нашата платка и нужните файлове. Да преминем към каталога buildroot и да укажем да използваме external-tree:
[alexey@alexey-pc buildroot]$ make BR2_EXTERNAL=../my_tree/ my_x86_board_defconfig
#
# конфигурацията е записана в /home/alexey/dev/article/ramdisk/buildroot/.config
#
[alexey@alexey-pc buildroot]$ make menuconfigВ първата команда използваме аргумента BR2_EXTERNAL=../my_tree/, който указва използването на external tree. Може да зададете няколко external-tree за употреба, като това се прави само веднъж, след което се създава файл output/.br-external.mk, съхраняващ информацията за използваното external-tree:
[alexey@alexey-pc buildroot]$ cat output/.br-external.mk
#
# Автоматично генериран файл; НЕ ГО РЕДАКТИРАЙТЕ.
#
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 = Моята проста външна структура за статияВажно! В този файл пътищата ще бъдат абсолютни!
В менюто се появи точка External options:

В това подменю ще се съдържат нашите пакети от нашето external-tree. В момента този раздел е празен.
Сега ни е по-важно да пренапишем нужните пътища да използват external-tree.
Обърнете внимание, че в раздела Build options → Location to save buildroot config, ще има абсолютен път към запазения defconfig. Той се оформя в момент на посочване на използването на external_tree.
Също така в раздела System configuration ще коригираме пътищата. За таблицата с създадените потребители:
$(BR2_EXTERNAL_my_tree_PATH)/board/my_x86_board/users.txtВ раздела Kernel променяме пътя към конфигурацията на ядрото:
$(BR2_EXTERNAL_my_tree_PATH)/board/my_x86_board/linux.configСега при сборката ще се използват нашите файлове от нашето external-tree. При прехвърлям в друг каталог или обновяване на buildroot, ще имаме минимум проблеми.
Добавяне на root fs overlay:
Този механизъм позволява лесно добавяне/замяна на файлове в target-файловата система.
Ако файлът съществува в overlay на root fs, но не и в target, той ще бъде добавен.
Ако файлът съществува и в overlay на root fs, и в target, той ще бъде заменен.
Първо, ще зададем пътя към директорията на overlay на root fs. Това се прави в секцията System configuration → Root filesystem overlay directories:
$(BR2_EXTERNAL_my_tree_PATH)/board/my_x86_board/rootfs_overlay/Сега ще създадем два файла.
[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Първият файл (my_tree/board/my_x86_board/rootfs_overlay/etc/hosts) ще замени файла /etc/hosts в готовата система. Вторият файл (cat my_tree/board/my_x86_board/rootfs_overlay/new_file.txt) ще бъде добавен.
Сглобяваме и проверяваме:

Изпълнение на кастомизационни скриптове на различни етапи от сборката на системата
Често е необходимо да извършите определени действия вътре в target-файловата система преди тя да бъде опакована в образи.
Това може да се направи в секцията System configuration:

Първите два скрипта се изпълняват след сглобяване на target-файловата система, но преди опаковането ѝ в образи. Разликата е, че скриптът fakeroot се изпълнява в контекста на fakeroot, т.е. имитира работата от потребител root.
Последният скрипт се изпълнява след създаването на образите на системата. В него могат да се извършват допълнителни действия, например, да се копират нужни файлове на nfs-сървър или да се създаде образ на вашия фърмуер за устройство.
За пример ще създам скрипт, който ще записва версията и датата на сборката в /etc/.
Първо ще посоча пътя към този файл в моя external-tree:

А сега самият скрипт:
[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След сглобяването можете да видите този файл в системата.
На практика, скриптът може да стане голям. Затова в реален проект предприех по-напреднал подход:
- Създадох директория (my_tree/board_my_x86_board/inside_fakeroot_scripts), в която се намират скриптове за изпълнение с редови номера. Например, 0001-add-my_small_linux-version.sh, 0002-clear-apache-root-dir.sh
- Написах скрипт (my_tree/board_my_x86_board/run_inside_fakeroot.sh), който преминава през тази директория и последователно изпълнява скриптовете в нея.
- Посочих този скрипт в настройките на дъската в секцията System configuration -> Custom scripts to run inside the fakeroot environment ($(BR2_EXTERNAL_my_tree_PATH)/board/my_x86_board/run_inside_fakeroot.sh)
Източник: habr.com
