Building PELUX sources¶
This chapter details how to download and configure the sources of a PELUX build, so that an image can be built.
A note on development images¶
Both PELUX images are available as -dev variants, which include some extra development and debugging tools. For some platforms, those images are also available as -update to generate update artifacts for the SOTA System.
It should be noted that the regular image is not a production ready image. For a production project, it is recommended to create an image that can be based on the PELUX image to begin with, but one will probably want to create a custom image eventually, as the project evolves further and further away from vanilla PELUX. For example, a PELUX-based image has an empty root password and an ssh server installed by default.
Create a directory for the PELUX build. Instruct repo tool to fetch a manifest
using the command repo init. In this context, branch denotes what branch of the
git repo pelux-manifests to use. If you want to use a released version of
PELUX, use the SHA id of the commit pointed to by the release tag (or the branch
that the commit lies on). Otherwise,
master is usually a good choice for
Then make repo tool fetch all sources using the command repo sync.
mkdir pelux cd pelux repo init -u https://github.com/Pelagicore/pelux-manifests.git -b <branch> repo sync
|Image name||Variant name|
When done fetching the sources, create a build directory and set up bitbake.
TEMPLATECONF tells the
oe-init-build-env script which path to fetch
configuration samples from.
The example below gets the template configuration for the Intel BSP
without Qt Automotive Suite (QtAS). Use
intel-qtauto as the last
part of the path to get QtAS support. The same pattern is used for the
Raspberry Pi BSP (
rpi-qtauto). There is also
experimental support for
TEMPLATECONF=`pwd`/sources/meta-pelux/conf/variant/intel source sources/poky/oe-init-build-env build
The script will create configurations if there are no configurations present. A printout about
conf/bblayers.conf is normal.
Building the image¶
Finally, build the desired image. See the variables description above for information on the different images.
When the build is complete the result will be available in
tmp/deploy/images/<machine>/. It is possible to generate a number of
different image formats, ranging from just the rootfs as a tarball to ready
disk-images containing EFI-bootloader, configuration and rootfs and that can be
written directly to a storage device. For PELUX, the preferred format for the
Intel NUC are
.wic images, which are complete disk-images. For the Raspberry
Pi 3, the preferred format is
.rpi-sdimg which can be directly written to
the SD card.
Building with Vagrant¶
In the current setup in our CI system we use Docker with Vagrant, however only in a GNU/Linux system. It should still work under Windows or OSX, but we have not tried it.
- Docker CE
- Virtualization enabled in BIOS
Ubuntu and Debian both have very old versions of Docker in their apt repositories. Follow the steps at docker.io to install the latest version of Docker.
- Clone the pelux-manifests git repository with submodule
git clone --recurse-submodules firstname.lastname@example.org:Pelagicore/pelux-manifests.git
- Start Docker through Vagrant
docker build -t pelux . docker run -d --name pelux-build -v $(pwd):/docker pelux
- Run inside the Docker container
At this point, we recommend using
vagrant ssh and to follow the same
instructions as when building locally (but inside the Docker container).
- Move the built images to the host
The directory where you cloned pelux-manifests is bind-mounted to
inside the container, so you can simply run:
cp <YOCTO_DIR>/build/tmp/deploy/images /vagrant
For more detailed steps, refer to the
where we have automated our building of PELUX.