ci_test-int Stage 4 firmware publish fails on private dockerd PID collision

[foil-copy-overrate]

What was checked

Run: https://github.com/yubi-OS/yubiOS/actions/runs/29152466267
Original failed job: https://github.com/yubi-OS/yubiOS/actions/runs/29152466267/job/86545643408
Rerun job: https://github.com/yubi-OS/yubiOS/actions/runs/29152466267/job/86546874621
Workflow: .github/workflows/ci_test-int.yml
Stage: Stage 4 — Publish firmware bundle (0mniteck/yubios:firmware)

Result

The requested Stage 4 rerun was triggered. It reproduced the same failure in step 3, Install docker-engine + buildx (pinned, private dockerd on ducker.sock).

All preceding artifact stages in the latest attempt were green, including Stage 1, Stage 2, and Stage 3/QEMU. Stage 4 stops before assembling or pushing the firmware bundle.

Failure signature

The static Docker daemon exits immediately because GitHub's hosted runner already has /var/run/docker.pid for another Docker process:

failed to start daemon, ensure docker is not running or delete /var/run/docker.pid: process with PID 1353 is still running
ERROR: failed to initialize builder hardened (hardened0): failed to connect to the docker API at unix:///var/run/ducker.sock: no such file or directory

Likely cause

The workflow starts a private dockerd on /var/run/ducker.sock, but it does not set a private --pidfile. Docker still checks the default /var/run/docker.pid, sees the hosted runner's daemon, and exits before creating /var/run/ducker.sock.

Recommended fix

Update the Stage 4 dockerd invocation in .github/workflows/ci_test-int.yml on main to use an isolated PID file, for example:

--pidfile "${RUNNER_TEMP}/ducker.pid" \

Place it alongside the existing private socket/data-root options. It would also be useful to make the wait loop fail explicitly if the socket never becomes ready before buildx create runs.

Notes

I attempted to prepare the CI edit from this environment, but direct raw/git checkout access from the container is blocked by HTTP 403 and the available connector write helper requires a full-file replacement for workflow edits. I did not make a partial or risky workflow rewrite.

Related TODO/FUTURE follow-up opened separately as one item per PR and not merged: #69.

[foil-copy-overrate]

Update from requested rerun on 2026-07-11:

• Requested job URL checked: https://github.com/yubi-OS/yubiOS/actions/runs/29152466267/job/86545643408
• Latest failed Stage 4 job before retry: https://github.com/yubi-OS/yubiOS/actions/runs/29152466267/job/86546874621
• Rerun triggered for only Stage 4 — Publish firmware bundle (0mniteck/yubios:firmware).
• New rerun job: https://github.com/yubi-OS/yubiOS/actions/runs/29152466267/job/86547584163

Result: rerun reproduced the same failure in step 3, Install docker-engine + buildx (pinned, private dockerd on ducker.sock).

Observed signature:

failed to start daemon, ensure docker is not running or delete /var/run/docker.pid: process with PID 1181 is still running
ERROR: failed to initialize builder hardened (hardened0): failed to connect to the docker API at unix:///var/run/ducker.sock: no such file or directory

Artifact download was successful again (fip-flash-arm64, digest sha256:4eb27c39b2060033605eb3e914f00eb0cf68987348000dc2cdb501d177516cf9). This confirms the failure is deterministic in the private dockerd startup path, not an artifact issue. Recommended fix remains adding an isolated --pidfile for the private daemon and making the readiness loop fail explicitly before buildx create.

[foil-copy-overrate]

Fix landed on main in commit 9ab6429.

Change scope: one-line workflow edit in .github/workflows/ci_test-int.yml:

           sudo env PATH="$docker_bin:$PATH" "$docker_bin/dockerd" \
             --storage-driver=overlayfs \
             --data-root=/mnt/docker \
+            --pidfile "${RUNNER_TEMP}/ducker.pid" \
             -H unix:///var/run/ducker.sock &

Verified via compare: exactly one file changed, one line added. Verified fetched main snippet shows the --pidfile line between private --data-root and private socket options.

Commit status was empty immediately after the write, and the available workflow-run lookup helper only exposes PR-triggered runs, so I could not yet attach a new push-triggered run URL from this connector session.