Yocto Cooker (3/3) « Christophe Blaess

Yocto Cooker (3/3)

Publié par cpb

Jan 27 2022

Dans les deux premiers articles de cette série, nous avons vu comment écrire un menu assez complet pour Yocto Cooker afin de produire des images pour diverses plateformes.

Pour le moment nous n’avons principalement utilisé que l’action cooker cook. Il est temps de voir les autres possibilités offertes par Yocto Cooker.

Sur la ligne de commande de cooker on peut fournir :

une action qui indique le travail à réaliser (par exemple cook ou clean),
une ou plusieurs options qui préciseront la manière de travailler (par exemple -k),
un ou plusieurs arguments supplémentaires, comme un nom de fichier-menu, ou une liste de builds.

Aide, version et débogage

Tout d’abord il est possible d’appeler cooker avec l’option -h (ou --help) afin d’avoir une liste des actions possibles.

$ cooker -h
usage: cooker [-h] [--debug] [--version] [-v] [-n] {cook,init,update,generate,show,build,shell,clean} ...

positional arguments:
  {cook,init,update,generate,show,build,shell,clean}
                        subcommands of Cooker
    cook                prepare the directories and cook the menu
    init                initialize the project-dir
    update              update source layers
    generate            generate build-configuration
    show                show builds and targets information
    build               build one or more configurations
    shell               run an interactive shell ($SHELL) for the given build
    clean               clean a previously build recipe

optional arguments:
  -h, --help            show this help message and exit
  --debug               activate debug printing
  --version             cooker version
  -v, --verbose         activate verbose printing (of called subcommands)
  -n, --dry-run         print what would have been done (without doing anything)

De même si on choisit l’action cooker cook par exemple, il est possible de lui adjoindre l’option -h pour voir ses options spécifiques.

$ cooker cook -h
usage: cooker cook [-h] [-d] [-k] [-s] menu [builds [builds ...]]

positional arguments:
  menu             filename of the JSON menu
  builds           build-configuration to build

optional arguments:
  -h, --help       show this help message and exit
  -d, --download   download all sources needed for offline-build
  -k, --keepgoing  Continue as much as possible after an error
  -s, --sdk        build also the SDK

Il est également possible d’utiliser l’option --version de cooker pour consulter la version installée :

$ cooker  --version
# 1.1.0

L’option -v (ou --verbose) permettra d’afficher des traces des actions de cooker. Enfin, l’option --debug est encore plus volubile et détaille toutes les activités de cooker y compris les succès et échecs de recherche de fichiers ou de paramètres.

Compilation d’images

Le travail principal de cooker est de préparer l’environnement nécessaire (répertoires et fichiers), puis de réaliser le menu qu’on lui donne en utilisant les recettes des layers indiqués et en sous-traitant la compilation au cuisinier bitbake.

Pour cela le plus simple est de lancer l’action cooker cook ainsi :

$ cooker  cook  menu-001.json
[...]

$

comme nous l’avons fait dès le premier article.

Il est possible de faire suivre le nom de menu d’un ou plusieurs noms de builds pour limiter la compilation à réaliser.

$ cooker cook menu-003.json  rpi4
[...]

$

L’action cooker cook accepte trois options pour ajuster son comportement :

Option « keepgoing«

L’option -k (ou --keepgoing) de cooker cook demande à bitbake de ne pas s’arrêter immédiatement s’il rencontre une erreur, mais de continuer le plus longtemps possible à compiler des packages. Ceci est particulièrement utile lorsqu’on lance un build long pour la première fois, et qu’on laisse le système compiler sans surveillance pendant plusieurs heures.

Si pour une raison quelconque une compilation échoue, il est intéressant de laisser bitbake continuer le plus longtemps possible sur les autres packages afin qu’à notre retour, il n’y ait plus qu’à régler le problème rencontré et que le reste du système soit déjà quasiment terminé.

Option « download«

L’option -d (ou --download) de l’action cooker cook demande à bitbake de télécharger tous les packages sources nécessaires puis de s’arrêter. Ainsi nous pourrons lancer les compilations ultérieurement même si notre machine de production n’est plus reliée à Internet.

Option « sdk«

Si on ajoute l’option -s (ou --sdk) sur la ligne de commande de cooker cook, Yocto Cooker demandera à bitbake (après avoir généré l’image standard) de compiler le Software Development Kit (SDK) c’est à dire un script shell auto-extractible comprenant la chaîne de cross-compilation et l’ensemble des headers des bibliothèques installées dans l’image.

Ceci permettra d’installer (éventuellement sur une machine différente de celle de compilation) l’environnement nécessaire pour développer le code métier applicatif.

Sous-actions de `cooker cook`

En réalité, l’action cooker cook que nous avons utilisée pour faire les compilations est une action-chapeau qui lance successivement quatre autres actions. Il est tout à fait possible de lancer ces dernières manuellement ou de ne relancer que celles nécessaires pour un rebuild.

Ces quatre actions lancées par cooker cook sont cooker init, cooker update, cooker generate, et cooker build.

`cooker init`

La commande cooker init menu-001.json initialise un fichier de configuration nommé .cookerconfig dans le répertoire courant.

Ce fichier contient le nom du fichier-menu et les noms des sous-répertoires à utiliser par la suite.

$ cooker  init  menu-001.json

$  cat .cookerconfig
{
    "menu": "/home/cpb/Lab/cooker-article/menu-001.json",
    "layer-dir": "layers",
    "build-dir": "builds",
    "dl-dir": "downloads"
}

On peut lui passer des options pour modifier certains de ces dossiers :

l’option -l ou --layer-dir permet de préciser le répertoire à utiliser pour stocker les layers,
l’option -d ou --dl-dir indique le répertoire de sauvegarde des fichiers sources téléchargés,
l’option -b ou --build-dir précise le répertoire où créer les builds à venir.

Si le fichier .cookerconfig existe déjà, cooker init n’a pas d’effet sauf si on lui adjoint l’option -f (ou --force).

Il est généralement inutile de lancer manuellement cooker init, il est plus simple d’utiliser cooker cook.

`cooker update`

La deuxième sous-action de cooker cook est cooker update, qui va télécharger les layers nécessaires.

$ cooker  update
# Update layers in project directory
# Downloading source from  git://git.yoctoproject.org/poky
# Updating source /home/cpb/Lab/cooker-article/layers/poky... 

$ ls
layers/  menu-001.json

$ ls layers/
poky/

Le lancement manuel de cooker update peut se justfifier lorsqu’on veut vérifier si des layers personnels sont bien téléchargés et installés avant de lancer un build par exemple.

`cooker generate`

La troisième sous-action de cooker cook est cooker generate. Elle prépare les répertoires de build du menu indiqué dans .cookerconfig avec les fichiers local.conf et bblayers.conf correspondant aux informations provenant du menu.

$ cooker  generate
# Generating dirs for all build-configurations

$ ls
builds  layers  menu-001.json

$ ls  builds/
build-qemuarm

$ ls  builds/build-qemuarm/
conf

$ ls  builds/build-qemuarm/conf/
bblayers.conf  local.conf  templateconf.cfg

Lancer manuellement cooker generate n’a que peu d’intérêt sauf pour valider le contenu d’un fichier-menu fraîchement modifié.

`cooker build`

Une fois les sous-actions cooker init, cooker update et cooker generate exécutées, cooker cook lance la dernière sous-action : cooker build.

Celle-ci réalise véritablement l’exécution de bitbake pour produire les images.

Lorsqu’on est amené à relancer un build plusieurs dizaines de fois par jour, il peut être avantageux d’exécuter directement cooker build (à condition de ne pas avoir modifié le fichier-menu) plutôt que cooker cook car cela permettra de gagner quelques secondes à quelques dizaines de secondes prises par les sous-actions précédentes.

On peut noter que les options --download, --keepgoing et --sdk de l’action cooker cook que nous avons décrites plus haut sont en fait prises en compte par la sous-action cooker build.

C’est également la sous-action cooker build qui prend en argument le ou les noms des builds à produire.

Nettoyage

Il est souvent nécessaire d’effacer le résultat de la compilation d’une recette, par exemple lorsqu’on a modifié les sources d’un projet local avant de le recompiler. Ou encore pour forcer la recompilation complète du noyau après modification de sa configuration.

Pour cela nous disposons de la commande cooker clean que l’on fait suivre du nom de la recette concernée et éventuellement du build ou des builds

En voici un exemple :

$ cooker  clean  virtual/kernel  qemuarm

Informations

La commande cooker show permet d’obtenir des informations sur la configuration préparée par Yocto Cooker, en détaillant les paramètres extraits du fichier-menu.

Cette commande accepte des options indiquant le contenu affiché, suivies éventuellement d’un ou plusieurs noms de builds pour limiter sa portée.

L’option -s affiche la liste des sources à télécharger, -l demande les listes des layers à inclure pour chaque build, -c présente les contenus spécifiques des fichiers local.conf.

$ cooker  show  -s
# source URL: git://git.yoctoproject.org/poky
#   locally:  /home/cpb/Lab/cooker-article/layers/poky
# build: qemuarm (bakes core-image-base)
# build: root

$ cooker  show  -l
# build: qemuarm (bakes core-image-base)
#  used layers
#   - poky/meta (/home/cpb/Lab/cooker-article/layers/poky/meta)
#   - poky/meta-poky (/home/cpb/Lab/cooker-article/layers/poky/meta-poky)
#   - poky/meta-yocto-bsp (/home/cpb/Lab/cooker-article/layers/poky/meta-yocto-bsp)
# build: root
#  used layers
#   - poky/meta (/home/spb/Lab/cooker-article/layers/poky/meta)
#   - poky/meta-poky (/home/cpb/Lab/cooker-article/layers/poky/meta-poky)
#   - poky/meta-yocto-bsp (/home/cpb/Lab/cooker-article/layers/poky/meta-yocto-bsp)

$ cooker  show  -c
# build: qemuarm (bakes core-image-base)
#  local.conf entries
#   - MACHINE = 'qemuarm' 
#   - IMAGE_FEATURES += 'empty-root-password' 
# build: root
#  local.conf entries

Yocto Cooker regroupe les paramètres globaux, ceux qui sont hérités par tous les builds, comme s’ils appartenaient à un build spécifique : root. Ceci permet d’homogénéiser la notion d’héritage.

L’option -t affiche la liste des builds avec leurs héritages, -b indique les commandes exécutées par cooker pour entrer dans les répertoires de build.

$ cooker  show  -t
# build: qemuarm (bakes core-image-base)
# builds ancestors: ['root']
# build: root

$ cooker  show  -b
# build: qemuarm (bakes core-image-base)
#   . layers/poky/oe-init-build-env builds/build-qemuarm
# build: root
# build root has no target

Enfin, l’option -a affiche tous les élements ci-dessus.

$ cooker  show  -a
# source URL: git://git.yoctoproject.org/poky
#   locally:  /home/cpb/Lab/cooker-article/layers/poky
# build: qemuarm (bakes core-image-base)
#  used layers
#   - poky/meta (/home/cpb/Lab/cooker-article/layers/poky/meta)
#   - poky/meta-poky (/home/cpb/Lab/cooker-article/layers/poky/meta-poky)
#   - poky/meta-yocto-bsp (/home/cpb/Lab/cooker-article/layers/poky/meta-yocto-bsp)
#  local.conf entries
#   - MACHINE = 'qemuarm' 
#   - IMAGE_FEATURES += 'empty-root-password' 
#   . layers/poky/oe-init-build-env builds/build-qemuarm
# builds ancestors: ['root']
# build: root
#  used layers
#   - poky/meta (/home/cpb/Lab/cooker-article/layers/poky/meta)
#   - poky/meta-poky (/home/cpb/Lab/cooker-article/layers/poky/meta-poky)
#   - poky/meta-yocto-bsp (/home/cpb/Lab/cooker-article/layers/poky/meta-yocto-bsp)
#  local.conf entries
# build root has no target

Accès au shell

Il peut être parfois nécessaire d’accéder au shell utilisé pour lancer la commande bitbake. Ceci par exemple pour exécuter une commande comme bitbake -c menuconfig busybox ou pour lancer l’émulateur Qemu avec le script runqemu livré avec Poky comme nous l’avions fait dans le premier article de cette série.

Il ne s’agit pas uniquement de se placer dans le bon répertoire, il faut aussi que les variables d’environnement soient correctement renseignées avec les paramètres nécessaires pour bitbake.

Pour cela, Yocto Cooker nous propose une action cooker shell suivie du nom du build considéré.

$ echo  $PATH
/home/cpb/.local/bin:/home/cpb/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin

$ echo  $BBPATH

$ pwd
/home/cpb/Lab/cooker-article

$ cooker  shell  qemuarm

### Shell environment set up for builds. ###

You can now run 'bitbake <target>'

Common targets are:
    core-image-minimal
    core-image-sato
    meta-toolchain
    meta-ide-support

You can also run generated qemu images with a command like 'runqemu qemux86'

Other commonly useful commands are:
 - 'devtool' and 'recipetool' handle common recipe tasks
 - 'bitbake-layers' handles common layer tasks
 - 'oe-pkgdata-util' handles common target package tasks


[build-qemuarm]$

Dans ce nouveau shell de nouvelles variables d’environnement sont disponibles, la variable PATH a été modifiée et nous avons été déplacés dans le répertoire de compilation.

[build-qemuarm]$ echo  $BBPATH
/home/cpb/Lab/cooker-article/builds/build-qemuarm

[build-qemuarm]$ echo  $PATH
/home/cpb/Lab/cooker-article/layers/poky/scripts:/home/cpb/Lab/cooker-article/layers/poky/bitbake/bin:/home/cpb/.local/bin:/home/cpb/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin

[build-qemuarm]$ pwd
/home/cpb/Lab/cooker-article/builds/build-qemuarm

Il ne faut pas oublier de ressortir de ce shell pour retrouver l’environnement et l’emplacement précédents.

[build-qemuarm]$ exit
exit

$

Exécution à vide

Il existe une option --dry-run qui peut être passée à cooker cook pour qu’il s’exécute « à blanc », sans effectuer aucune action réelle, mais en écrivant sur sa sortie standard toutes les actions qu’il aurait normalement réalisées.

Il est intéressant de rediriger cette sortie dans un fichier ainsi :

$ cooker  --dry-run  cook  menu-001.json  >  build-script

Ce script peut être analysé, pour vérifier ce que ferait cooker.

$ cat  build-script
# Update layers in project directory
# Updating source /home/cpb/Lab/cooker-article/layers/poky... 
cd /home/cpb/Lab/cooker-article/layers/poky; git fetch; git checkout yocto-3.1.13 >/dev/null 2>&1
cd /home/cpb/Lab/cooker-article/layers/poky; git submodule update --recursive --init  >/dev/null 2>&1
# Generating dirs for all build-configurations
mkdir /home/cpb/Lab/cooker-article/builds/build-qemuarm
mkdir /home/cpb/Lab/cooker-article/builds/build-qemuarm/conf
cat > /home/cpb/Lab/cooker-article/builds/build-qemuarm/conf/local.conf <<-EOF
        # DO NOT EDIT! - This file is automatically created by cooker.


        COOKER_LAYER_DIR = "\${TOPDIR}/../../layers"
        DL_DIR = "\${TOPDIR}/../../downloads"
        SSTATE_DIR = "\${TOPDIR}/../../sstate-cache"
        MACHINE = 'qemuarm' 
        IMAGE_FEATURES += 'empty-root-password' 
        DISTRO ?= "poky"
        PACKAGE_CLASSES ?= "package_rpm"
        BB_DISKMON_DIRS ??= "\
                STOPTASKS,\${TMPDIR},1G,100K \
                STOPTASKS,\${DL_DIR},1G,100K \
                STOPTASKS,\${SSTATE_DIR},1G,100K \
                STOPTASKS,/tmp,100M,100K \
                ABORT,\${TMPDIR},100M,1K \
                ABORT,\${DL_DIR},100M,1K \
                ABORT,\${SSTATE_DIR},100M,1K \
                ABORT,/tmp,10M,1K"
        CONF_VERSION = "1"
EOF
cat > /home/cpb/Lab/cooker-article/builds/build-qemuarm/conf/bblayers.conf <<-EOF
        # DO NOT EDIT! - This file is automatically created by cooker.


        POKY_BBLAYERS_CONF_VERSION = "2"
        BBPATH = "${TOPDIR}"
        BBFILES ?= ""
        BBLAYERS ?= " \
                \${TOPDIR}/../../layers/poky/meta \
                \${TOPDIR}/../../layers/poky/meta-poky \
                \${TOPDIR}/../../layers/poky/meta-yocto-bsp \
        "

EOF
cat > /home/cpb/Lab/cooker-article/builds/build-qemuarm/conf/templateconf.cfg <<-EOF
        meta-poky/conf

EOF
# Building qemuarm (core-image-base)
env bash -c "source /home/cpb/Lab/cooker-article/layers/poky/oe-init-build-env /home/cpb/Lab/cooker-article/builds/build-qemuarm && bitbake  core-image-base"
$

Le script peut également être lancé pour réaliser le même travail que cooker cook.

$ chmod  +x  build-script

$ ./build-script

Conclusion

Nous avons pu voir dans ces trois articles les différentes possibilités offertes par Yocto Cooker. Il s’agit d’un projet encore en développement, de nouvelles fonctionnalités sont en cours de discussion et de mise au point.

N’hésitez pas à tester les nouvelles versions de cooker ; tous les retours, les remarques et les suggestions sont les bienvenus !

URL de trackback pour cette page

Christophe Blaess

Yocto Cooker (3/3)

Aide, version et débogage

Compilation d’images

Option « keepgoing«

Option « download«

Option « sdk«

Sous-actions de `cooker cook`

`cooker init`

`cooker update`

`cooker generate`

`cooker build`

Nettoyage

Informations

Accès au shell

Exécution à vide

Conclusion

Articles récents

Code et projets

Formations que j'anime

Liens Linux

Christophe Blaess

Yocto Cooker (3/3)

Aide, version et débogage

Compilation d’images

Option « keepgoing«

Option « download«

Option « sdk«

Sous-actions de cooker cook

cooker init

cooker update

cooker generate

cooker build

Nettoyage

Informations

Accès au shell

Exécution à vide

Conclusion

Articles récents

Code et projets

Formations que j'anime

Liens Linux

Sous-actions de `cooker cook`

`cooker init`

`cooker update`

`cooker generate`

`cooker build`