Yocto Common Errors

Yocto system common build errors

Hardware resources

Yocto builds may strongly impact your HW resources in terms of

• required disk space
• required RAM
• CPU overheating

Required disk space

Since Yocto will download the source code that will be used to build the packages included in the image, consider reserving at least 300 GB of free space.

Using a SSD will extremely speed up the build.

Required RAM

Yocto will check for the host CPU feature and will try to use all of them in order to speed-up the build.

Just as an example,

• with an i7-7700K (4 cores / 8 threads), Yocto will activate 8 building threads
• with an i7-9700K (8 cores / 8 threads), Yocto will activate 8 building threads
• with an i7-11700K (8 cores / 16 threads), Yocto will activate 16 building threads

Each building thread will require a dedicated amount of RAM, that can easily rise above 3 GB.

To safely run 8 building threads, plan to have 32 (8*4) GB of RAM.

To safely run 16 building threads, plan to have 64 (16*4) GB of RAM.

Since such an amount of RAM is not always available, you can forcibly reduce the number of building threads by setting the variable BB_NUMBER_THREADS in your local.conf to something like (available RAM in GB / 4). This also means that is not reasonable run a Yocto build with less then 4 GB of RAM.

A typical settings for a 16 GB RAM system is

BB_NUMBER_THREADS = "4"

Typical errors due to low memory are

ERROR: Worker process (12928) exited unexpectedly (-9), shutting down...
ERROR: Worker process (12928) exited unexpectedly (-9), shutting down...
ERROR: Worker process (12928) exited unexpectedly (-9), shutting down...
ERROR: Worker process (12928) exited unexpectedly (-9), shutting down...

or:

fatal error: Killed signal terminated program
compilation terminated.

CPU overheating

Being Yocto extremely resource hungry, a build can easily lead the building host to an overheat condition, with merely unpredictable side effects, ranging from crashes to memory corruptions.

We strongly suggest to keep the CPU core temperature under control.

Fetching problems

GitHub: unsafe repositories

On April 12, 2022, GitHub announced the need to upgrade the local installation of Git. For more information, please see https://github.blog/2022-04-12-git-security-vulnerability-announced/

Something reasonably changed also in GitHub repositories: starting from the above date, some GitHub users are experiencing error messages like

fatal: unsafe repository ('<repo-path>' is owned by someone else)
To add an exception for this directory, call:
    git config --global --add safe.directory <repo-path>  

The message already suggests the solution with the "git config" command, but if this is not working, you may want to updated to latest Git version.

On an Ubuntu machine, you can run

sudo add-apt-repository ppa:git-core/ppa -y
sudo apt update
sudo apt upgrade -y
git config --global --add safe.directory '*'

This will update to the latest git version available for your machine and disable the safe check system-wide.

Please note that the option to disable the safe check system-wide is only available starting from Git v2.35.3

GitHub: Git protocol on port 9418

On January 11, 2022, Github disabled the Git protocol on 9418. For more information, please see https://github.blog/2021-09-01-improving-git-protocol-security-github/

This change will break all recipes using the Git protocol. Fortunately, starting in Yocto Pyro, Yocto will try fetching using HTTPS when the Git protocol fails. See: https://git.yoctoproject.org/poky/commit/meta/classes/mirrors.bbclass?h=pyro&id=85c41bfcf2c62e8b394a7f3d9efdf50af77ff960

For Yocto Morty and older, you will observe the following error:

fatal: remote error:
The unauthenticated git protocol on port 9418 is no longer supported.
Please see https://github.blog/2021-09-01-improving-git-protocol-security-github/ for more information.

This can be fixed by manually adding HTTPS mirrors to conf/local.conf:

MIRRORS += "\
git://anonscm.debian.org/.*   git://anonscm.debian.org/git/PATH;protocol=https \n \
git://git.gnome.org/.*        git://git.gnome.org/browse/PATH;protocol=https \n \
git://git.savannah.gnu.org/.* git://git.savannah.gnu.org/git/PATH;protocol=https \n \
git://git.yoctoproject.org/.* git://git.yoctoproject.org/git/PATH;protocol=https \n \
git://.*/.*                   git://HOST/PATH;protocol=https \n \
"

Firewalls / proxies constraints

Firewalls and proxies may block the access to specific websites or protocols (like git).

Double check with the IT team that you are not experiencing any access restriction during the fetching phase.

Certificates validation

Messages like

server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none

indicate that the certificates on your machine are outdated.

You can try the following commands:

$ sudo apt update
$ sudo apt upgrade

and then check if the latest version of the CAcertificate package can solve the problem.

Note that starting from January 2022, github dropped git:// support and now only https:// (encrypted) access is allowed.

If your Ubuntu release reached its EOL, no further CA certificates updates are available: the installed certificates will systematically expire.

In such case, to avoid git cloning errors, disable https verification (based on CA certificates) by running:

$ git config --global http.sslverify "false"

Can't find package

Due to server maintenance sometime it will fail to fetch the source.

Search the exact file name and version and download it from other source into your download directory.

Checksum mismatch

Sometime you will get an error as listed below.
The reason is due to re packaging on the server of the provider.
locate the pacakage bb file

$ find ../sources/ -name evtest*

./meta-openembedded/meta-oe/recipes-support/evtest
./meta-openembedded/meta-oe/recipes-support/evtest/evtest_1.25.bb

edit the pacakage

$ gedit ./meta-openembedded/meta-oe/recipes-support/evtest/evtest_1.25.bb

And replace:
SRC_URI[archive.md5sum] = "770d6af03affe976bdbe3ad1a922c973"
SRC_URI[archive.sha256sum] = "3d34123c68014dae6f7c19144ef79ea2915fa7a2f89ea35ca375a9cf9e191473"
With:
SRC_URI[archive.md5sum] = "0ef3fe5e20fa2dee8994827d48482902"
SRC_URI[archive.sha256sum] = "6e93ef54f0aa7d263f5486ce4a14cac53cf50036bfd20cf045fef2b27ee6664b"

Error log example

ERROR: Fetcher failure for URL: 'http://cgit.freedesktop.org/~whot/evtest/snapshot/evtest-1.25.tar.bz2;name=archive'. Checksum mismatch!
File: '/ws/variscite/yocto_dl_dora/evtest-1.25.tar.bz2' has md5 checksum 0ef3fe5e20fa2dee8994827d48482902 when 770d6af03affe976bdbe3ad1a922c973 was expected
File: '/ws/variscite/yocto_dl_dora/evtest-1.25.tar.bz2' has sha256 checksum 6e93ef54f0aa7d263f5486ce4a14cac53cf50036bfd20cf045fef2b27ee6664b when 3d34123c68014dae6f7c19144ef79ea2915fa7a2f89ea35ca375a9cf9e191473 was expected
If this change is expected (e.g. you have upgraded to a new version without updating the checksums) then you can use these lines within the recipe:
SRC_URI[archive.md5sum] = "0ef3fe5e20fa2dee8994827d48482902"
SRC_URI[archive.sha256sum] = "6e93ef54f0aa7d263f5486ce4a14cac53cf50036bfd20cf045fef2b27ee6664b"
Otherwise you should retry the download and/or check with upstream to determine if the file has become corrupted or otherwise unexpectedly modified.

ERROR: Function failed: Fetcher failure for URL: 'http://cgit.freedesktop.org/~whot/evtest/snapshot/evtest-1.25.tar.bz2;name=archive'. Unable to fetch URL from any source.
ERROR: Logfile of failure stored in: /home/variscite/var-som-mx6-dora-v5/build_var/tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/evtest/1.25-r0/temp/log.do_fetch.2662
NOTE: recipe evtest-1.25-r0: task do_fetch: Failed
ERROR: Task 2966 (/home/variscite/var-som-mx6-dora-v5/sources/meta-openembedded/meta-oe/recipes-support/evtest/evtest_1.25.bb, do_fetch) failed with exit code '1'
NOTE: Running task 2366 of 6931 (ID: 2848, /home/variscite/var-som-mx6-dora-v5/sources/meta-openembedded/meta-oe/recipes-benchmark/nbench-byte/nbench-byte_2.2.3.bb, do_fetch)

kernel compile errors

Some users reported the following error

fatal error: yaml.h: No such file or directory

Although most of the distro already provide the relevant packages, some do not.
Running the following command on the host PC should fix the problem

$ sudo apt install libyaml-dev

UBI size is too small (max_leb_cnt too low)

Sometimes when building a large image the system fails, because the image cannot fit into the default 512MB NAND flash.

Log data follows:
| DEBUG: Executing python function set_image_size
| DEBUG: Python function set_image_size finished
| DEBUG: Executing shell function do_image_ubi
| Error: max_leb_cnt too low (4094 needed)
| ERROR: Function failed: do_image_ubi

There are three ways to overcome this issue:

• If you are using a SOM with eMMC, use the eMMC to store the filesystem, and remove the ubi image type from the build process by adding the following line to the conf/local.conf file in your build directory:

IMAGE_FSTYPES_remove_<MACHINE> = "ubi multiubi"

(Replace <MACHINE> with either var-som-mx6, imx6ul-var-dart or var-som-mx7, according to the SOM you are using)

• If you have a SOM with a 512MB NAND flash and no eMMC, you'll have to remove packages from the image you are building in order to make it fit, or just use a different and smaller image.
• If you have a 1GB NAND flash on the SOM and you want to use it to hold the filesystem, edit the conf/machine/include/variscite.inc file under meta-variscite, comment out the 512MB NAND parameters and uncomment the appropriate 1GB NAND parameters.