Skip to content

Yocto Build Troubleshooting

do_fetch fails with network errors

Check connectivity

curl -I https://github.com

If this fails, your network or proxy is blocking outbound connections.

Set proxy variables

export http_proxy=http://proxy.example.com:3128
export https_proxy=http://proxy.example.com:3128
export no_proxy=localhost,127.0.0.1

Add them to local.conf as well:

BB_ENV_PASSTHROUGH_ADDITIONS += "http_proxy https_proxy no_proxy"

Use mirrors

If a upstream source is temporarily unavailable, configure a mirror in local.conf:

MIRRORS += "https://.*/.* https://downloads.yoctoproject.org/mirror/sources/"

Build offline

If the downloads/ directory is already populated, you can build without network access:

BB_NO_NETWORK = "1"
Disk full during build

Yocto build directories can easily exceed 100 GB. Options to reclaim space:

Enable rm_work

This automatically removes recipe work directories after each task completes. Add to local.conf:

INHERIT += "rm_work"

Warning

With rm_work active, devshell and manual inspection of WORKDIR are no longer available after a build.

Clean a specific recipe

bitbake <recipe> -c cleansstate

This removes the recipe's work directory and sstate cache entries, forcing a full rebuild of that recipe.

Clean all build artifacts

Removes tmp/ entirely but keeps the downloads/ cache:

rm -rf build/tmp

The next build will reuse sstate from other machines if a shared sstate mirror is configured, otherwise it rebuilds from source.

Build is very slow or runs out of memory

Limit parallelism

Edit local.conf:

BB_NUMBER_THREADS = "4"    # number of bitbake tasks in parallel
PARALLEL_MAKE = "-j4"      # make -j flag inside each task

Set both to the number of physical CPU cores. Using logical threads (hyperthreading) often causes memory pressure and thrashing rather than speedup.

Add swap space

Yocto build tasks, especially do_compile for large packages like Qt or the kernel, can require several GB of RAM per task. If the system OOM-kills build processes:

sudo fallocate -l 8G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

Use a VM with more resources

See Virtual Machine for recommended VM settings.

U-Boot does not reflect the new DDR configuration

After changing UBOOT_CONFIG in local.conf, BitBake does not automatically know that U-Boot needs to be rebuilt. The sstate cache serves the old binary.

Clean U-Boot and rebuild:

bitbake u-boot-engicam -c cleansstate
bitbake engicam-evaluation-image

See DDR Selection for the full procedure.

Sstate cache causes stale builds

If a build produces unexpected results after changing configuration, the sstate cache may be serving a stale version of a task output.

Clean a specific recipe completely

bitbake <recipe> -c cleansstate

Invalidate the entire sstate cache

bitbake -c cleansstate world

Or simply remove the sstate directory:

rm -rf build/sstate-cache

The next build will regenerate all sstate entries from source.

Recipe fails with a hash mismatch or checksum error

This usually means the upstream source file changed (the server replaced the tarball), or the SRC_URI checksum in the recipe is outdated.

Fetch the new file manually and check

bitbake <recipe> -c fetch
bitbake <recipe> -c unpack

If it fails, check the recipe's SRC_URI[sha256sum]. You can find the actual checksum of the downloaded file:

sha256sum build/downloads/<file>

Update the recipe with the correct checksum, or report it upstream.