Bitbake build consumes more space

Question

I recently started using Bitbake for building Yocto. Everytime I build, it consumes more space and currently I'm running out of disk space. The images are not getting overwritten. A set of new files with timestamp is getting created for every build. I have deleted old files from build/tmp/deploy/images/. But it doesn't make much difference in the disk free space. Is there any other locations from where I can delete stuff?

The error I observe during build is:

WARNING: The free space of source/build/tmp (/dev/sda4) is running low (0.999GB left)
ERROR: No new tasks can be executed since the disk space monitor action is "STOPTASKS"!
WARNING: The free space of source/build/sstate-cache (/dev/sda4) is running low (0.999GB left)
ERROR: No new tasks can be executed since the disk space monitor action is "STOPTASKS"!
WARNING: The free space of source/build/downloads (/dev/sda4) is running low (0.999GB left)
ERROR: No new tasks can be executed since the disk space monitor action is "STOPTASKS"!

Kindly suggest some pointers to avoid this issue.

Bernhardt

Answer 1

In order of effectiveness and how easy the fix is:

• Buy more disk space: Putting $TMPDIR on an SSD of its own helps a lot and removes the need to micromanage.
• Delete $TMPDIR (build/tmp): old images, old packages and workdirectories/sysroots for MACHINEs you aren't currently building for accumulate and can take quite a lot of space. You can normally just delete the whole $TMPDIR once in a while: as long as you're using sstate-cache the next build should still be pretty fast.
• Delete $SSTATE_DIR (build/sstate-cache): If you do a lot of builds sstate itself accumulates over time. Deleting the directory is safe but the next build will take a long time as everything will be rebuilt.
• Delete $DL_DIR (build/downloads): If you use a build directory for a long time (while pulling updates from master or changing to newer branch) the obsolete downloads keep taking disk space. Keep in mind that deleting the directory will mean re-downloading everything. Looking at just the largest files and deleting the old versions may be a useful compromise here.

Nematic

Thanks a lot! Deleting the tempdir itself released approximately 32GB!!! And, there was no change in the build time also! – Bernhardt

If your going down the deleting route, you could also try adding INHERIT += "rm_work" to your projects configuration file. Adding this statement deletes the work directory used for building a recipe once the recipe is built. – Koah

Answer 2

There are some official ways instead of deleting.

By deliberately deleting you could be forcing unnecessary builds & downloads. Some elements of the build could be not controlled by bitbake, and you can find yourself in a situation that you cannot rebuild these items in an easy way.

With these recommendations, you can beat the non written 50GB per build yocto rule:

Check your IMAGE_FSTYPES variable. My experience says it is safe to delete all images of these files that are not symlinks, or symlinks targets. Avoid the last one generated to avoid breaking the last build link, and any related with bootloaders and configuration files, as they could be rarely regenerated.

If you are keeping more than one build with the same set of layers, then you can use a common download folder for builds.

DL_DIR ?= "common_dir_across_all_builds/downloads/"

And afterwards:

To keep your /deploy clean:

RM_OLD_IMAGE: Reclaims disk space by removing previously built versions of the same image from the images directory pointed to by the DEPLOY_DIR variable.Set this variable to "1" in your local.conf file to remove these images:

RM_OLD_IMAGE = "1"

IMAGE_FSTYPES Remove the image types that you do not plan to use, you can always enable a particular one when you need it:

IMAGE_FSTYPES_remove = "tar.bz2"

IMAGE_FSTYPES_remove = "rpi-sdimg"

IMAGE_FSTYPES_remove = "ext3"

For /tmp/work, do not need all the workfiles of all recipes. You can specify which ones you are interested in your development.

RM_WORK_EXCLUDE: With rm_work enabled, this variable specifies a list of recipes whose work directories should not be removed. See the "rm_work.bbclass" section for more details.

INHERIT += "rm_work"

RM_WORK_EXCLUDE += "home-assistant widde"

Advisable

Answer 3

You can use the script sstate-cache-management.sh (from poky) with the option --remove-duplicated.

Remove the duplicated sstate cache files of one package, only the newest one will be kept. The duplicated sstate cache files of one package must have the same arch, which means sstate cache files with multiple archs are not considered duplicate.

Rodriguez