Bitbake构建消耗更多空间

Gom*_*omu 4 linux build bitbake yocto

我最近开始使用Bitbake来构建Yocto.每次我构建,它消耗更多的空间,目前我的磁盘空间不足.图像不会被覆盖.将为每个构建创建一组带有时间戳的新文件.我从build/tmp/deploy/images /中删除了旧文件.但它在磁盘可用空间方面没有太大区别.我可以删除任何其他位置吗?

我在构建期间观察到的错误是:

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"!
Run Code Online (Sandbox Code Playgroud)

请提出一些建议来避免这个问题.

urn*_*eld 7

有一些官方的方法而不是删除。

通过故意删除,您可能会强制进行不必要的构建和下载。构建的某些元素可能不受 bitbake 控制,您可能会发现自己无法以简单的方式构建这些项目。

通过这些建议,您可以击败每个构建 yocto 规则的非书面 50GB:

检查您的IMAGE_FSTYPES变量。我的经验表明,删除这些不是符号链接或符号链接目标的文件的所有图像是安全的。避免生成最后一个以避免破坏最后一个构建链接,以及任何与引导加载程序和配置文件相关的内容,因为它们很少会重新生成。

如果您使用同一组图层保留多个构建,则可以使用通用下载文件夹进行构建。

DL_DIR ?= "common_dir_across_all_builds/downloads/"

之后:

保持你的 /deploy 干净:

RM_OLD_IMAGE:通过从 DEPLOY_DIR 变量指向的图像目录中删除相同图像的先前构建版本来回收磁盘空间。在 local.conf 文件中将此变量设置为“1”以删除这些图像:

RM_OLD_IMAGE = "1"

IMAGE_FSTYPES删除您不打算使用的图像类型,您可以随时在需要时启用特定类型:

IMAGE_FSTYPES_remove = "tar.bz2"

IMAGE_FSTYPES_remove = "rpi-sdimg"

IMAGE_FSTYPES_remove = "ext3"

对于 /tmp/work,不需要所有配方的所有工作文件。您可以指定您对您的开发感兴趣的那些。

RM_WORK_EXCLUDE:启用 rm_work 后,此变量指定不应删除其工作目录的配方列表。有关更多详细信息,请参阅“rm_work.bbclass”部分。

INHERIT += "rm_work"

RM_WORK_EXCLUDE += "home-assistant widde"


Jus*_*nen 6

为了有效性和修复是多么容易:

  • 购买更多的磁盘空间:将$ TMPDIR放在自己的SSD上有很大帮助,并且不再需要微管理.
  • 删除$ TMPDIR(build/tmp):旧的图像,旧的软件包和工作目录/ sysroots for MACHINEs,你目前没有建立累积,可以占用相当多的空间.你通常可以暂时删除整个$ TMPDIR:只要你使用sstate-cache,下一个版本应该仍然非常快.
  • 删除$ SSTATE_DIR(build/sstate-cache):如果你做了很多构建,那么sstate会随着时间的推移而累积.删除目录是安全的,但下一次构建将花费很长时间,因为所有内容都将重建.
  • 删除$ DL_DIR(构建/下载):如果长时间使用构建目录(从主服务器提取更新或更改为更新的分支),过时的下载将继续占用磁盘空间.请记住,删除目录意味着重新下载所有内容.仅查看最大的文件并删除旧版本可能是一个有用的折衷方案.