10857 2016-12-24 02:40:07 +0000 sstate: .siginfo files are not accessed from local or NFS-mounted SSTATE_MIRROR 2017-03-10 18:33:36 +0000 1 1 7 Build System, Metadata & Runtime OE-Core configuration unspecified x86 Multiple RESOLVED FIXED Medium normal 2.3 1 denis eduard.bartosh --- --- No (bug/feature does not impact docs) oldest_to_newest 69382 0 denis 2016-12-24 02:40:07 +0000 It appears that .siginfo files are not being accessed from local or NFS-mounted SSTATE_MIRROR (file://), so their timestamp never gets updated. If you periodically clean SSTATE_MIRROR based on access time, they get deleted, even though they are still being used, leading to errors like: WARNING: quilt-native-0.64-r0 do_populate_sysroot_setscene: Failed to fetch URL file://Ubuntu-16.04/52/sstate:quilt-native:x86_64-linux:0.64:r0:x86_64:3:5227556845cbc224f05726d1633de4e5_populate_sysroot.tgz.siginfo, attempting MIRRORS if available ERROR: quilt-native-0.64-r0 do_populate_sysroot_setscene: Fetcher failure: Unable to find file file://Ubuntu-16.04/52/sstate:quilt-native:x86_64-linux:0.64:r0:x86_64:3:5227556845cbc224f05726d1633de4e5_populate_sysroot.tgz.siginfo anywhere. The paths that were searched were: In this case, corresponding file://Ubuntu-16.04/52/sstate:quilt-native:x86_64-linux:0.64:r0:x86_64:3:5227556845cbc224f05726d1633de4e5_populate_sysroot.tgz is still there, but not its .siginfo Everything works fine for HTTP-based SSTATE_MIRROR, because .tgz and their corresponding .siginfo files are being downloaded, updating both files timestamps on the server. So, regardless of SSTATE_MIRROR access protocol, when .tgz is being used, corresponding .siginfo file should probably be "touch"-ed to update it's timestamp to prevent this issue. 70785 1 denis 2017-02-17 00:45:56 +0000 Any updates or comments on this? 70830 2 eduard.bartosh 2017-02-20 12:06:39 +0000 I'm sorry, I haven't looked at this yet. I'm planning to do it after I fix all 2.3 M3 bugs assigned to me with higher priority. 70923 3 eduard.bartosh 2017-02-23 18:05:17 +0000 Can you provide more info please? How your sstate NFS share is mounted? Did you use noatime or relatime option to mount it? 71003 4 denis 2017-03-01 03:35:02 +0000 It uses "relatime" by default. Should I try something else? 71012 5 eduard.bartosh 2017-03-01 10:08:42 +0000 No, you shouldn't unless you want atime to be updated immediately when file is accessed. relatime is delaying atime updates as far as I know. I reproduced this bug with strictatime mount option. Hopefully will fix it soon. 71019 6 eduard.bartosh 2017-03-01 14:37:33 +0000 Please review: http://lists.openembedded.org/pipermail/openembedded-core/2017-March/133500.html 71091 7 eduard.bartosh 2017-03-06 15:48:31 +0000 sent v2: http://lists.openembedded.org/pipermail/openembedded-core/2017-March/133701.html 71195 8 eduard.bartosh 2017-03-10 18:31:36 +0000 The fix has been merged to oe-core and poky master branches. 71196 9 denis 2017-03-10 18:33:36 +0000 Thanks!