我正在尝试使用 yocto 构建自定义 Linux 映像。设置是；
Oracle 虚拟机上的 Ubuntu 20.04
Yocto 发布 dunfell
它给出了这个错误
注意：退出代码 127。输出： /home/user234/yocto-project/image/build/tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/interc ept_scripts-1bf6a9721f164ba99b8a07325a9c3fe0f21a700fea55c8351519b59cf02d0aca/update_desktop_database： 7：更新桌面数据库：找不到
错误：安装后拦截挂钩“update_desktop_database”失败，详细信息位于 /home/user234/yocto-project/image/build/tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/temp/log .do_rootfs
该问题仅出现在虚拟机环境中，在我的另一台机器上的本机linux环境中运行良好。
我已经安装了 desktop-file-utils，我可以从 shell 手动运行。不知何故，bitbake 无法检测到它。有人知道解决办法吗
我也有类似的问题（没有虚拟机，你会看到这部分是不相关的）。 问题出在 Yocto 源或部分源的文件权限上。在我的特定情况下，DevOps 已将整个 Yocto 源目录的 POSIX 文件权限设置为
777-rwxrwxrwx在 OP 的情况下，Yocto 源似乎已在某些无需许可的文件系统（如 FAT32）的帮助下复制到虚拟机，这会导致相同的结果。一个很好的例子是使用 FAT32 格式化的 USB 闪存驱动器复制源。 YMMV，这可能也与 ACL 相关，我还没有尝试去摆弄它。
在我看来，这应该被视为 bitbake 中的一个错误。如果源文件权限可能导致这种不可预测的行为，则必须在构建之前或构建期间对其进行验证，并且必须通过生成错误来通知用户。
这显然与OP无关，希望有人发现它有用。
您可以通过修补 poky 源以跳过此路径中“update_desktop_database”的执行来立即解决此问题：
狭小/脚本/postinst-intercepts/update_desktop_database
只需评论该行即可。
其他脚本可能会再次发生这种情况。对其他脚本执行相同的操作。最后，do_rootfs 任务将成功完成。
这似乎是主机上的某些软件包（libgdk-pixbuf）出现问题，并且在您在容器中构建时发生。注释行有效，但它适用于 wsl 和虚拟框