Bug 16045

Summary: Intermittent error on qemuarm: failed to find screen to remove
Product: [Build System, Metadata & Runtime] OE-Core Reporter: Chen Qi <Qi.Chen>
Component: coreAssignee: Ross Burton <ross.burton>
Status: ACCEPTED --- QA Contact:
Severity: normal    
Priority: Medium+ CC: meta.mr.watcher, meta.watcher, randy.macleod, richard.purdie, ross.burton, tim.orling
Version: unspecified   
Target Milestone: 6.1 M2   
Hardware: ARM   
OS: Multiple   
Whiteboard:
OS type for building Yocto: --- Type of Regression: ---
Verified: Documentation change: No (bug/feature does not impact docs)

Description Chen Qi 2025-10-29 04:50:12 UTC 
With systemd 258, there's an intermittent error on qemuarm + core-image-sato at boot:
failed to find screen to remove

I bisected systemd repo and located the following commit:
https://github.com/systemd/systemd/commit/0ba9d06963ecb848e71951ed5e9f6f6f03b80b06
"""
udev: use sd_notify to communicate between worker and manager processes

Let's replace home-grown notification from worker to manager process
with sd_notify.
"""

Looking at the commit log, it does look like a change that could introduce such intermittent error. As the error is likely caused by some race condition.

However, that commit cannot be reverted, not only because there are a bunch of changes based on this one, but also because the change look like a reasonable one. Besides, it's possible that the real fix need to be in xserver-xorg.
Comment 1 Tim Orling 2025-10-30 14:45:32 UTC 
This is something that needs to be resolved for the systemd upgrade.
Comment 2 Chen Qi 2025-10-31 02:52:08 UTC 
(In reply to Tim Orling from comment #1)
> This is something that needs to be resolved for the systemd upgrade.

Is there someone familiar with xserver? I think the final fix is likely to be in xserver instead of systemd.

I've put a workaround in the patchset V4. I don't think this is a serious problem that should block systemd upgrade.

Anyway, if there's someone familiar with xserver, please take this issue. That would be really appreciated. Otherwise, I'll take care of it only when there is some real runtime issue, e.g., no desktop or something like that.
Comment 3 Chen Qi 2025-10-31 05:32:41 UTC 
I spent some time looking into this issue again. I think there might be a better solution than the current workaround.
Comment 5 Ross Burton 2025-12-11 10:38:45 UTC 
We're merging that patch but I'm not entirely convinced the dependency is the optimal one, so please keep this bug open.
Comment 6 Randy MacLeod 2026-03-31 17:47:26 UTC 
Bump to M4.
Ross, do you have a better approach in mind now?
Comment 7 Randy MacLeod 2026-06-04 15:26:54 UTC 
Close or more optimal patch incoming ?