With the recent move to using sha256 checksums in sstate, the lengths of some file names can now exceed the 255 char limit seen in most Linux filesystems. When this occurs, bitbake crashes as it is unable to create the sstate archive or sigfile. To avoid this issue we need to shorten the length of the file names used in the sstate cache. The issue is triggered by a combination of a long package name, long package version and long expansion of `${PACKAGE_ARCH}${TARGET_VENDOR}-${TARGET_OS}`.
I sent a patch on this to the mailing list back in January but have had no further time to look into it since then. If you want to pick up from this work see http://lists.openembedded.org/pipermail/openembedded-core/2019-January/277826.html and follow ups.
Paul, Do you have an example of what package sstate was exceeding the 255 char limit? I'd like to check if it's still a problem.
(In reply to comment #2) > Paul, Do you have an example of what package sstate was exceeding the 255 > char limit? I'd like to check if it's still a problem. I had a relatively long package name (containerd-opencontainers), long target triplet (cortexa7t2hf-neon-vfpv4-poky-linux-musleabi) and long version number (v1.0.2+gitcfd04396dc68220d1cecbe686a6cc3aa5ce3667c). Looking at the tune listed there I was building for raspberrypi3. The full file name bitbake was trying to create was 'sstate:containerd-opencontainers:cortexa7t2hf-neon-vfpv4-poky-linux-musleabi:v1.0.2+gitcfd04396dc68220d1cecbe686a6cc3aa5ce3667c:r0:cortexa7t2hf-neon-vfpv4:3:8cf9e07e17de9682ef6e3eb78ac3eca8f942c2a833c4a7f5096cda401c1711e1_prepare_recipe_sysroot.tgz.siginfo' at a length of 257 chars - just over the 255 limit. There's some discussion in the IRC logs here: https://www.yoctoproject.org/irc/%23yocto.2019-01-08.log.html To replicate this, you'll probably need to roll back meta-virtualisation prior to this commit where I shortened ${PV} values: http://git.yoctoproject.org/cgit/cgit.cgi/meta-virtualization/commit/?id=488b5aba28fff50c64866b42a8b66aef74ac12ad
I'm worried that arbitrarily chopping the end off the version could result in bad matches. Would it be best to sanely handle the filename too long errors and just suggest that the recipe uses short SHAs in the PV?
Duplicate *** This bug has been marked as a duplicate of bug 13268 ***