Build problems

Bitbake fails with a strange Java error

On Ubuntu 18.04 and some other distros, you may get an error with a Java stack trace that includes the following line: the trustAnchors parameter must be non-empty

This issue is due a change in the packaging for OpenJDK 9+ security certificates. It has a simple workaround, however.

Run the following commands:

sudo rm /etc/ssl/certs/java/cacerts
sudo update-ca-certificates --fresh

Try the bitbake build again. If the build still doesn’t work, run the following commands:

sudo /usr/bin/printf '\xfe\xed\xfe\xed\x00\x00\x00\x02\x00\x00\x00\x00\xe2\x68\x6e\x45\xfb\x43\xdf\xa4\xd9\x92\xdd\x41\xce\xb6\xb2\x1c\x63\x30\xd7\x92' > /etc/ssl/certs/java/cacerts
sudo /var/lib/dpkg/info/ca-certificates-java.postinst configure

More detailed info about the cause of the bug, as well as links to the bug in various distros' issue trackers, can be found on github.

GnuTLS build fails with older kernels

GnuTLS currently requires a kernel >= 3.17 to build. If you’re using an older kernel, you’ll see an error like this:

../../../gnutls-3.5.3/lib/nettle/rnd-linux.c: In function 'have_getrandom':
../../../gnutls-3.5.3/lib/nettle/rnd-linux.c:59:42: error: 'SYS_getrandom' undeclared (first use in this function)
 #  define getrandom(dst,s,flags) syscall(SYS_getrandom, (void*)dst, (size_t)s, (unsigned int)flags)

This is an upstream problem; until it’s fixed in upstream poky, you can download this patch to your poky directory and apply it to fix the issue.

Build didn’t work after switching architectures

You might have tried something like this:

source meta-updater/scripts/ raspberrypi3

{ build an image ... }

cd ..
source meta-updater/scripts/ qemux86-64

This doesn’t work. The setup script sets up certain environment variables for bitbake, but it also generates your local.conf and bblayers.conf files. If it finds existing files, however, it leaves them alone, and only sets up the environment. If you want to switch architectures, you also need to change your config files. You can do that by deleting/renaming your old ones and re-generating the config files. Don’t forget to add your credentials and other customizations to the re-generated files!

Depending on your use case, however, it often makes more sense to just keep separate project directories for your separate architectures, and share the state cache and downloads directories between them.

Runtime problems

File ownership incorrect after an update (static UID to name mapping)

Yocto assigns numeric user IDs (UIDs) to Linux login names at system build time. This dynamic assignment does not always work correctly for an embedded system that is receiving software updates, because the numeric UID of a service can change between builds, but any files the service created on the file system will remain owned by the original UID.

The solution is to manually set the contents of /etc/passwd and /etc/group for your system, so that the UIDs remain stable between builds.

This is required if you have a service that does all of the following:

  • Creates files

  • Runs as an account that is not one of the 'standard' accounts (root, floppy, man, tape, etc)

  • The recipe for the service creates the user (using useradd)

In this case, you should set USERADDEXTENSION to "useradd-staticids". The useradd section of the Yocto Mega Manual describes this process in more detail.

Don’t see your problem here?

We’d love to hear from you about how we can improve the docs and make ATS Garage better. Contact and we’ll do our best to help.