Nesta seção, considero alguns dos recursos de personalização necessários. Esta não é uma lista completa do que o buildroot oferece, mas eles estão funcionando bem e não requerem intervenção nos arquivos do próprio buildroot.
Usando o mecanismo EXTERNO para customização
No artigo anterior, consideramos um exemplo simples de adição de sua configuração, adicionando o defconfig da placa e os arquivos necessários diretamente ao diretório Buildroot.
Mas esse método não é muito conveniente, especialmente ao atualizar o buildroot. Para resolver esse problema, existe um mecanismo de árvore externa . Sua essência é que você pode armazenar quadros, configurações, pacotes e outros diretórios em um diretório separado (por exemplo, eu uso o diretório patches para aplicar patches aos pacotes, mais em uma seção separada) e o buildroot os adicionará aos de seu próprio diretório.
Nota: você pode aplicar várias árvores externas ao mesmo tempo; há um exemplo no manual do buildroot
Crie o diretório my_tree localizado próximo ao diretório buildroot e transfira nossa configuração para lá. A saída deve ser a seguinte estrutura de arquivo:
[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 você pode ver, em geral, a estrutura segue a estrutura do buildroot.
O diretório do quadro contém arquivos específicos para cada quadro no nosso caso:
- bef_cr_fs_img.sh - um script que será executado após a construção do sistema de arquivos de destino, mas antes de compactá-lo em imagens. No futuro, vamos usá-lo
- linux.config - configuração do kernel
- rootfs_overlay - diretório para sobrepor sobre o sistema de arquivos de destino
- users.txt - arquivo com uma descrição dos usuários criados
O diretório configs contém os defconfigs de nossas placas. Nós temos apenas um.
Pacote - um catálogo com nossos pacotes. Inicialmente, o buildroot contém descrições e regras para criar um número limitado de pacotes. Mais tarde, adicionaremos o gerenciador de janelas icewm e o gerenciador de logon Slim aqui.
Patches - permite armazenar convenientemente seus patches para diferentes pacotes. Mais detalhes em uma seção separada abaixo.
Agora precisamos adicionar os arquivos de descrição da nossa árvore externa. 3 arquivos são responsáveis por isso: external.desc, Config.in, external.mk.
external.desc contém a descrição real:
[alexey@alexey-pc my_tree]$ cat external.desc name: my_tree desc: My simple external-tree for article
A primeira linha é o nome. No futuro, a buildroot criará a variável $ (BR2_EXTERNAL_MY_TREE_PATH) , que deve ser usada ao configurar a montagem. Por exemplo, o caminho para o arquivo com usuários pode ser definido da seguinte maneira:
$(BR2_EXTERNAL_my_tree_PATH)/board/my_x86_board/users.txt
A segunda linha é uma descrição breve e legível por humanos.
Config.in, external.mk - arquivos para a descrição dos pacotes adicionados. Se você não adicionar seus pacotes, esses arquivos poderão ser deixados em branco. Até agora, faremos isso.
Agora temos nossa árvore externa pronta, contendo o defconfig da nossa placa e os arquivos necessários. Iremos para o diretório buildroot, especificaremos o uso da árvore externa:
[alexey@alexey-pc buildroot]$ make BR2_EXTERNAL=../my_tree/ my_x86_board_defconfig
No primeiro comando, usamos o argumento BR2_EXTERNAL = .. / my_tree / , indicando o uso de uma árvore externa. É possível especificar várias árvores externas para uso ao mesmo tempo. Basta fazer isso uma vez, após o qual é criado um arquivo de saída / .br-external.mk que armazena informações sobre a árvore externa usada:
[alexey@alexey-pc buildroot]$ cat output/.br-external.mk
Importante! Neste arquivo, os caminhos serão absolutos!
O item de menu Opções externas apareceu:
Este submenu conterá nossos pacotes da nossa árvore externa. Agora esta seção está vazia.
Agora é mais importante reescrever os caminhos necessários para usar uma árvore externa.
Observe que na seção Opções de construção → Local para salvar a configuração do buildroot, haverá um caminho absoluto para o defconfig salvo. É formado no momento de especificar o uso de extgernal_tree.
Também na seção Configuração do sistema, corrija os caminhos. Para uma tabela com o usuário criado:
$(BR2_EXTERNAL_my_tree_PATH)/board/my_x86_board/users.txt
Na seção Kernel, altere o caminho para a configuração do kernel:
$(BR2_EXTERNAL_my_tree_PATH)/board/my_x86_board/linux.config
Agora, a montagem usará nossos arquivos da nossa árvore externa. Ao transferir para outro diretório, atualizar o buildroot, teremos um mínimo de problemas.
Adicionando sobreposição de raiz fs:
Esse mecanismo facilita a adição / substituição de arquivos no sistema de arquivos de destino.
Se o arquivo estiver na sobreposição raiz fs, mas não no destino, ele será adicionado
Se o arquivo estiver na sobreposição raiz fs e no destino, ele será substituído.
Primeiro, defina o caminho como root fs overlay dir. Isso é feito na seção Configuração do sistema → Diretórios raiz da sobreposição do sistema de arquivos:
$(BR2_EXTERNAL_my_tree_PATH)/board/my_x86_board/rootfs_overlay/
Agora vamos criar dois arquivos.
[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
O primeiro arquivo (my_tree / board / my_x86_board / rootfs_overlay / etc / hosts) substituirá o arquivo / etc / hosts no sistema finalizado. Um segundo arquivo (cat my_tree / board / my_x86_board / rootfs_overlay / new_file.txt) será adicionado.
Coletamos e verificamos:
Execução de scripts de customização em diferentes estágios de montagem do sistema
Freqüentemente, é necessário executar algumas ações dentro do sistema de arquivos de destino antes que ele seja compactado em imagens.
Isso pode ser feito na seção de configuração do sistema:
Os dois primeiros scripts são executados após a construção do sistema de arquivos de destino, mas antes de compactá-lo em imagens. A diferença é que o script fakeroot é executado no contexto do fakeroot, eles simulam o trabalho do usuário root.
O último script é executado após a criação das imagens do sistema. Você pode executar ações adicionais, por exemplo, copiar os arquivos necessários para um servidor nfs ou criar uma imagem do firmware do dispositivo.
Como exemplo, vou criar um script que escreverá a versão e construirá a data em / etc /.
Primeiro, indicarei o caminho para esse arquivo na minha árvore externa:
E agora o próprio script:
[alexey@alexey-pc buildroot]$ cat ../my_tree/board/my_x86_board/bef_cr_fs_img.sh
Após a montagem, você pode ver este arquivo no sistema.
Na prática, um script pode se tornar grande. Portanto, em um projeto real, fui de uma maneira mais avançada:
- Criou um diretório (my_tree / board_my_x86_board / inside_fakeroot_scripts), no qual estão os scripts para execução, com números de série. Por exemplo, 0001-add-my_small_linux-version.sh, 0002-clear-apache-root-dir.sh
- Eu escrevi um script (my_tree / board_my_x86_board / run_inside_fakeroot.sh) que passa por esse diretório e executa os scripts nele sequencialmente
- Esse script indicado nas configurações da placa na configuração do sistema -> scripts personalizados para execução no ambiente do fakeroot ($ (BR2_EXTERNAL_my_tree_PATH) /board/my_x86_board/run_inside_fakeroot.sh)