En esta sección miro algunas de las opciones de personalización que necesitaba. Esta no es una lista completa de lo que ofrece buildroot, pero son bastante funcionales y no requieren intervención en los archivos del propio buildroot.
Usando el mecanismo EXTERNO para la personalización
Pero este método no es muy conveniente, especialmente al actualizar buildroot. Existe un mecanismo para solucionar este problema. árbol externo. Su esencia es que puede almacenar tableros, configuraciones, paquetes y otros directorios en un directorio separado (por ejemplo, uso el directorio de parches para aplicar parches a los paquetes, más detalles en una sección separada) y el propio buildroot los agregará a los de su directorio.
Nota: puedes superponer varios árboles externos a la vez, hay un ejemplo en el manual de buildroot
Creemos un directorio my_tree, ubicado al lado del directorio buildroot y transfiramos nuestra configuración allí. El resultado debe ser la siguiente estructura de archivos:
[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
Como puede ver, en general la estructura repite la estructura de buildroot.
directorio tablero contiene archivos específicos para cada placa en nuestro caso:
- bef_cr_fs_img.sh es un script que se ejecutará después de crear el sistema de archivos de destino, pero antes de empaquetarlo en imágenes. Lo usaremos en el futuro.
- linux.config - configuración del núcleo
- rootfs_overlay: directorio para superponer sobre el sistema de archivos de destino
- usuarios.txt: un archivo que describe los usuarios que se crearán
directorio configs contiene defconfig de nuestros tableros. Sólo tenemos uno.
Contenido del Paquete - catálogo con nuestros paquetes. Inicialmente, buildroot contiene descripciones y reglas para crear un número limitado de paquetes. Más adelante agregaremos aquí el administrador de ventanas icewm y el administrador de inicio de sesión gráfico Slim.
Parches — le permite almacenar cómodamente sus parches para diferentes paquetes. Más detalles en una sección separada a continuación.
Ahora necesitamos agregar los archivos de descripción para nuestro árbol externo. Hay 3 archivos responsables de esto: external.desc, Config.in, external.mk.
externo.desc contiene la descripción real:
[alexey@alexey-pc my_tree]$ cat external.desc
name: my_tree
desc: My simple external-tree for article
La primera línea es el título. En el futuro buildroot crea una variable $(BR2_EXTERNAL_MY_TREE_PATH), que debe usarse al configurar el ensamblaje. Por ejemplo, la ruta al archivo de usuario se puede configurar de la siguiente manera:
$(BR2_EXTERNAL_my_tree_PATH)/board/my_x86_board/users.txt
La segunda línea es una descripción breve y legible por humanos.
Config.in, externo.mk — archivos para describir paquetes agregados. Si no agrega sus propios paquetes, estos archivos pueden dejarse vacíos. Por ahora, eso es lo que haremos.
Ahora tenemos listo nuestro árbol externo, que contiene la configuración de configuración de nuestra placa y los archivos que necesita. Vayamos al directorio buildroot y especifiquemos usar árbol externo:
[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
En el primer comando usamos el argumento. BR2_EXTERNAL=../mi_árbol/, que indica el uso de un árbol externo. Puede especificar varios árboles externos para su uso al mismo tiempo. En este caso, solo necesita hacer esto una vez, después de lo cual se crea un archivo de salida/.br-external.mk que almacena información sobre el árbol externo utilizado:
[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
¡Importante! ¡Las rutas en este archivo serán absolutas!
Ha aparecido un elemento de Opciones externas en el menú:
Este submenú contendrá nuestros paquetes de nuestro árbol externo. Esta sección está ahora mismo vacía.
Ahora es más importante para nosotros reescribir las rutas necesarias para usar el árbol externo.
Tenga en cuenta que en la sección Opciones de compilación → Ubicación para guardar la configuración de buildroot, habrá una ruta absoluta al defconfig guardado. Se forma en el momento de especificar el uso de extgernal_tree.
También corregiremos las rutas en el apartado de Configuración del sistema. Para una tabla con usuarios creados:
$(BR2_EXTERNAL_my_tree_PATH)/board/my_x86_board/users.txt
En la sección Kernel, cambie la ruta a la configuración del kernel:
$(BR2_EXTERNAL_my_tree_PATH)/board/my_x86_board/linux.config
Ahora nuestros archivos de nuestro árbol externo se utilizarán durante el ensamblaje. Al movernos a otro directorio o actualizar el buildroot, tendremos un mínimo de problemas.
Agregar superposición de root fs:
Este mecanismo le permite agregar/reemplazar archivos fácilmente en el sistema de archivos de destino.
Si el archivo está en la superposición raíz fs, pero no en el destino, se agregará
Si el archivo está en la superposición raíz fs y en el destino, será reemplazado.
Primero, establezcamos la ruta al directorio de superposición raíz de fs. Esto se hace en la sección Configuración del sistema → Directorios de superposición del sistema de archivos raíz:
$(BR2_EXTERNAL_my_tree_PATH)/board/my_x86_board/rootfs_overlay/
Ahora creemos dos archivos.
[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
El primer archivo (my_tree/board/my_x86_board/rootfs_overlay/etc/hosts) reemplazará el archivo /etc/hosts en el sistema terminado. Se agregará el segundo archivo (cat my_tree/board/my_x86_board/rootfs_overlay/new_file.txt).
Recopilamos y comprobamos:
Ejecución de scripts de personalización en diferentes etapas del montaje del sistema.
A menudo es necesario realizar algún trabajo dentro del sistema de archivos de destino antes de empaquetarlo en imágenes.
Esto se puede hacer en la sección de configuración del sistema:
Los dos primeros scripts se ejecutan después de crear el sistema de archivos de destino, pero antes de empaquetarlo en imágenes. La diferencia es que el script fakeroot se ejecuta en el contexto de fakeroot, lo que simula el trabajo como usuario root.
El último script se ejecuta después de crear las imágenes del sistema. Puede realizar acciones adicionales en él, por ejemplo, copiar los archivos necesarios a un servidor NFS o crear una imagen del firmware de su dispositivo.
Como ejemplo, crearé un script que escribirá la versión y la fecha de compilación en /etc/.
Primero indicaré la ruta a este archivo en mi árbol externo:
Y ahora el guión en sí:
[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
Después del ensamblaje, puede ver este archivo en el sistema.
En la práctica, el guión puede llegar a ser grande. Por tanto, en el proyecto real tomé una ruta más avanzada:
- Creé un directorio (my_tree/board_my_x86_board/inside_fakeroot_scripts) en el que hay scripts para ejecutar, con números de serie. Por ejemplo, 0001-add-my_small_linux-version.sh, 0002-clear-apache-root-dir.sh
- Escribí un script (my_tree/board_my_x86_board/run_inside_fakeroot.sh) que recorre este directorio y ejecuta secuencialmente los scripts contenidos en él.
- Se especificó este script en la configuración del tablero en la configuración del sistema -> Scripts personalizados para ejecutar dentro del entorno fakeroot ($(BR2_EXTERNAL_my_tree_PATH)/board/my_x86_board/run_inside_fakeroot.sh)
Fuente: habr.com