Bug 15962 - AB-INT: overlayfs.OverlayFSEtcRunTimeTests.test_sbin_init_read_only fail
Summary: AB-INT: overlayfs.OverlayFSEtcRunTimeTests.test_sbin_init_read_only fail
Status: RESOLVED FIXED
Alias: None
Product: Functional (self) Testing
Classification: QA/Testing
Component: oe-selftest (show other bugs)
Version: unspecified
Hardware: x86 Multiple
: Medium normal
Target Milestone: 5.3
Assignee: Unassigned
QA Contact:
URL:
Whiteboard: AB-INT
Depends on:
Blocks:
 
Reported: 2025-09-02 06:44 UTC by Mathieu Dubois-Briand
Modified: 2025-12-23 15:38 UTC (History)
2 users (show)

See Also:
OS type for building Yocto: ---
Type of Regression: ---
Verified:
Documentation change: No (bug/feature does not impact docs)

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Mathieu Dubois-Briand 2025-09-02 06:44:28 UTC 
2025-09-01 04:39:59,917 - oe-selftest - INFO - overlayfs.OverlayFSEtcRunTimeTests.test_sbin_init_read_only (subunit.RemotedTestCase)
2025-09-01 04:39:59,925 - oe-selftest - INFO -  ... FAIL
...
2025-09-01 04:39:59,931 - oe-selftest - INFO - testtools.testresult.real._StringException: Traceback (most recent call last):
  File "/srv/pokybuild/yocto-worker/oe-selftest-fedora/build/meta/lib/oeqa/core/decorator/__init__.py", line 35, in wrapped_f
    return func(*args, **kwargs)
  File "/srv/pokybuild/yocto-worker/oe-selftest-fedora/build/meta/lib/oeqa/selftest/cases/overlayfs.py", line 379, in test_sbin_init_read_only
    self.run_sbin_init(True, "squashfs")
    ~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^
  File "/srv/pokybuild/yocto-worker/oe-selftest-fedora/build/meta/lib/oeqa/selftest/cases/overlayfs.py", line 406, in run_sbin_init
    self.assertTrue("/data" in output, msg=output)
    ~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/srv/pokybuild/yocto-worker/oe-selftest-fedora/build/buildtools/sysroots/x86_64-pokysdk-linux/usr/lib/python3.13/unittest/case.py", line 744, in assertTrue
    raise self.failureException(msg)
AssertionError: False is not true :
Comment 1 Mathieu Dubois-Briand 2025-09-02 06:45:31 UTC 
oe-selftest-fedora alma8-vk-2 master completed at 2025-09-01 10:51:20+00:00
https://autobuilder.yoctoproject.org/valkyrie/#/builders/48/builds/2174/steps/15/logs/stdio
Comment 2 Randy MacLeod 2025-09-04 14:39:12 UTC 
first occurence. 
Maybe fix the test to report what is going wrong rather than True != False.
Comment 3 Vyacheslav Yurkov 2025-09-04 14:45:10 UTC 
I take a look in the next couple of days. Any idea what has changed that it started failing?
Comment 4 Randy MacLeod 2025-09-04 20:27:02 UTC 
Thanks Vyacheslav. 

Unfortunately, no we don't know why this started to fail.

As you may know, there are lots of changes being merged typically in batches 
twice or more per week so looking at recent changes may help. Other bugs just 
suddenly appear due to a new race condition or change in system load as packages are updated. We label such bugs, including this one with: 
  AB-INT
meaning that they happen on the YP AutoBuilder and are INTermittent.

If the root cause isn't clear to you based on the stack trace, 
I suggest submitting a patch that gathers more data and logs it in the failure case. 

We'll keep this bug open for a few months or longer to see if it happens again.
Comment 5 Vyacheslav Yurkov 2025-09-08 01:57:16 UTC 
I tried to reproduce it locally, but was not able to. I'm currently not sure why there are so many qemu logs, because the test should produce only 2. I suspect some kind of race for now, but can't confirm it yet.

Is there any way to get qemu_boot_log's from autobuilder?
Comment 6 Mathieu Dubois-Briand 2025-09-08 17:06:59 UTC 
Hi Vyacheslav,

Yes, this issues in intermittent and only happened once so far, so a race condition is plausible.

Autobuilder logs cannot be retrieved anymore, as this build is from last week. I will try to keep the logs if it happens again.
Comment 7 Vyacheslav Yurkov 2025-09-12 00:02:36 UTC 
I think I was able to hit a pretty similar failure (with a bit different trace though), but I believe they must be related:

> ip: SIOCGIFFLAGS: No such device

My suspicion for now is that communication with QEMU is not handled properly (could be another race though), but I still haven't figured out the exact reason for the failure.
Comment 8 Vyacheslav Yurkov 2025-09-12 22:38:02 UTC 
Possible fix is submitted