New AB-INT, only seen on my branch so far. We had a few uki changes in the last month, but nothing looks really related with this. 2026-02-02 16:13:56,460 - oe-selftest - INFO - uki.UkiTest.test_uki_boot_systemd (subunit.RemotedTestCase) 2026-02-02 16:13:56,471 - oe-selftest - INFO - ... FAIL ... ERROR: When reparsing /tmp/selftest-fetchrun8g13b/test.bb:do_checkuri, the basehash value changed from 84b9e23a83a764e7a5d8a96ee523199e2b1c604f4280a45030e248de0ff52962 to 4123da244f465feffecb2b4fd2b132b64851981ec2fb70bf9445df8b0ea6a69e. The metadata is not deterministic and this needs to be fixed. ERROR: The following commands may help: ERROR: $ bitbake test -cdo_checkuri -Snone ERROR: Then: ERROR: $ bitbake test -cdo_checkuri -Sprintdiff
oe-selftest-fedora stream9-vk-1 mathieu/master-next completed at 2026-02-02 17:51:09+00:00 https://autobuilder.yoctoproject.org/valkyrie/#/builders/48/builds/3030/steps/15/logs/stdio oe-selftest-fedora alma9-vk-2 mathieu/master-next completed at 2026-02-03 20:17:05+00:00 https://autobuilder.yoctoproject.org/valkyrie/#/builders/48/builds/3035/steps/15/logs/stdio
Paul, please add your analysis as a comment.
In both cases the error described here happens after the error described in issue #16143 - "AB-INT: do_image_wic: tar command return exit status 2". It's unclear at this point exactly how the two issues relate, but the build environment may not be in a good state after the first error. We should look at this again once we understand the other issue more.
We could artificially force earlier test case to fail and see if that causes this to reproduce.
oe-selftest-fedora alma9-vk-2 mathieu/master-next completed at 2026-02-18 09:22:11+00:00 https://autobuilder.yoctoproject.org/valkyrie/#/builders/48/builds/3112/steps/15/logs/stdio
oe-selftest-fedora rocky9-vk-1 mathieu/master-next&mathieu/master-next-tests completed at 2026-03-03 17:37:28+00:00 https://autobuilder.yoctoproject.org/valkyrie/#/builders/48/builds/3208/steps/15/logs/stdio
Both of the two most recent instances of this failure show that the pseudo abort described in #16143 happened before the non-deterministic metadata error. I don't really trust the system after those failures, and we haven't seen this issue in isolation so far. We have fixed the associated pseudo error, so can we close this and re-open if it reoccurs independently?
The error means something corrupted bitbake's cache, bitbake is re-executing without re-validating it's cache, or the failing test caused an exit without cleaning up. Possibly a more general oe-selftest correctness issue. Needs investigation.