13177 2019-02-13 18:29:35 +0000 sstate file names can exceed 255 char limit 2020-01-22 13:05:03 +0000 1 1 7 Build System, Metadata & Runtime OE-Core core 0.0.0 x86 Multiple RESOLVED DUPLICATE 13268 Medium normal 3.1 1 paul ross.burton meta.mr.watcher meta.watcher randy.macleod tvgamblin --- --- Don't know oldest_to_newest 82989 0 paul 2019-02-13 18:29:35 +0000 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}`. 82990 1 paul 2019-02-13 18:32:21 +0000 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. 83005 2 randy.macleod 2019-02-14 15:40:46 +0000 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. 83006 3 paul 2019-02-14 16:01:28 +0000 (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 83857 4 ross.burton 2019-05-17 23:47:34 +0000 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? 86080 5 ross.burton 2020-01-22 13:05:03 +0000 Duplicate *** This bug has been marked as a duplicate of bug 13268 ***