https://autobuilder.yoctoproject.org/typhoon/#/builders/133/builds/805/steps/12/logs/stdio ====================================================================== ERROR: test13 (oeqa.buildperf.test_basic.Test1P3) Build core-image-sato with rm_work enabled ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/pokybuild/yocto-worker/buildperf-alma8/build/meta/lib/oeqa/buildperf/test_basic.py", line 58, in test13 save_bs=True) File "/home/pokybuild/yocto-worker/buildperf-alma8/build/meta/lib/oeqa/buildperf/base.py", line 346, in measure_cmd_resources raise data oeqa.utils.CommandError: Command '['bitbake', '-R', '/home/pokybuild/build-perf-test/results-5200799866-20221007030024/test13.tmp/postfile.conf', 'core-image-sato']' returned non-zero exit status 1 with output: ... (last 40 lines of output) inode mismatch: '/home/pokybuild/build-perf-test/build-5200799866-20221007030024/tmp/work/core2-32-poky-linux/pciutils/3.8.0-r0/image/usr/lib/libpci.so.3' ino 26215279 in db, 26215277 in request. Setup complete, sending SIGUSR1 to pid 3749733.
Something has touched libpci.so.3 outside of the pseudo context. Check the pciutils do_install recipes to see if it's doing anything interesting.
https://autobuilder.yoctoproject.org/typhoon/#/builders/132/builds/1035/steps/11/logs/stdio
I looked into this one and it is a bug in the recipe and/or the pciutils makefile. There are two different make targets for the symlink. From the kernel's perspective, they're atomic and one will win but pseudo can't know which would and hence it's database can be out of sync.
Unfortunately, Sakib is busy for the next 2 weeks and then on holiday so moving to unassigned.
Indicative of a pseudo race condition that we should debug.
Build move to 5.0 -- ../Randy
Bulk move from 5.0* to 5.99 to indicate that there isn't any one available to work on this issue.
https://autobuilder.yoctoproject.org/typhoon/#/builders/133/builds/3432/steps/12/logs/stdio https://autobuilder.yoctoproject.org/typhoon/#/builders/133/builds/3272/steps/12/logs/stdio https://autobuilder.yoctoproject.org/typhoon/#/builders/132/builds/3597/steps/11/logs/stdio
*** Bug 15609 has been marked as a duplicate of this bug. ***
Assumed to be fixed by improvements in pseudo (link handling?) but reopen if seen again.
buildperf-alma8 perf-alma8-vk master completed at 2025-03-15T04:48:39Z https://autobuilder.yoctoproject.org/valkyrie/#/builders/57/builds/783/steps/12/logs/stdio
Wha we need to do here is create a test case where "ln -sf" is run multiple times in several threads in parallel on the same target, then see if we can reproduce the database error from pseudo.
Reopening as recurred
Reproducer shared on the mailing list https://lists.openembedded.org/g/openembedded-core/message/213331
Just sent a patch to avoid the race in pciutils, at least.
*** Bug 15846 has been marked as a duplicate of this bug. ***
The pciutils race was fixed in commit a5fc49fafe910a25be7372c82bfbd7876871ce3f, merged to oe-core in March 2025. A failing test case was added in commit 0f7c26cf00f67405c2e457e5b91071d1f1b164c5 in pseudo. Should we open a separate, non-AB-INT bug for following up the failing test cases in pseudo?
Bulk move of unassigned 6.0-M* bugs to 6.1-M2.
Possible race conditions in move/rename, Mark added a test case in test/test-parallel-rename.sh in pseudo. I'll close this and open the new bug.