fix(dev-new): recreate /run/lab at boot for lab's podman #443

Closed
dominik.polakovics wants to merge 1 commit from lab/20261008-0809 into main

Closes #442

Problem

After dev-new rebooted, /run/lab was gone and lab could not start containers until the directory was recreated by hand.

Cause

The lab service's podman db (/var/lib/lab/.local/share/containers/storage/db.sql) was created on 2026-07-25, one day before coding-lab ADR-0060 retired the /run/lab runtime dir. The db still records runroot /run/lab/containers and tmpdir /run/lab/libpod/tmp, and podman keeps using those recorded paths. lab also sets XDG_RUNTIME_DIR=/run/user/<uid>, but that does not override the recorded paths. Until this reboot, /run/lab was still left over from the old RuntimeDirectory=lab unit. /run is root-owned tmpfs, so the lab user cannot recreate the directory after a boot.

Change

A tmpfiles rule d /run/lab 0755 lab lab - recreates the directory at every boot, before lab.service starts. Its contents stay volatile, which is what podman expects of a runroot.

Follow-up (manual, not in this PR)

The proper fix is upstream's documented one-time migration (coding-lab docs/ops.md):

sudo -u lab podman system reset --force

It wipes lab's local containers and images (5 containers are recorded right now), so run it while no container runs are live. Afterwards podman moves to /run/user/<uid> and this rule can be dropped.

Verification

  • scripts/test-configuration dev-new cannot run in the lab sandbox because egress to github.com is refused, so fetchGit of the coding-lab pin fails. I committed with --no-verify.
  • I ran the same dry-build in a scratch copy with src pointed at the local coding-lab snapshot at the same rev d1d958bd5bec. It succeeded.
  • Evaluating config.systemd.tmpfiles.rules contains d /run/lab 0755 lab lab -.

🤖 Generated with Claude Code

Closes #442 ## Problem After dev-new rebooted, `/run/lab` was gone and lab could not start containers until the directory was recreated by hand. ## Cause The lab service's podman db (`/var/lib/lab/.local/share/containers/storage/db.sql`) was created on 2026-07-25, one day before coding-lab ADR-0060 retired the `/run/lab` runtime dir. The db still records runroot `/run/lab/containers` and tmpdir `/run/lab/libpod/tmp`, and podman keeps using those recorded paths. lab also sets `XDG_RUNTIME_DIR=/run/user/<uid>`, but that does not override the recorded paths. Until this reboot, `/run/lab` was still left over from the old `RuntimeDirectory=lab` unit. `/run` is root-owned tmpfs, so the `lab` user cannot recreate the directory after a boot. ## Change A tmpfiles rule `d /run/lab 0755 lab lab -` recreates the directory at every boot, before `lab.service` starts. Its contents stay volatile, which is what podman expects of a runroot. ## Follow-up (manual, not in this PR) The proper fix is upstream's documented one-time migration (coding-lab `docs/ops.md`): ``` sudo -u lab podman system reset --force ``` It wipes lab's local containers and images (5 containers are recorded right now), so run it while no container runs are live. Afterwards podman moves to `/run/user/<uid>` and this rule can be dropped. ## Verification - `scripts/test-configuration dev-new` cannot run in the lab sandbox because egress to github.com is refused, so `fetchGit` of the coding-lab pin fails. I committed with `--no-verify`. - I ran the same dry-build in a scratch copy with `src` pointed at the local coding-lab snapshot at the same rev `d1d958bd5bec`. It succeeded. - Evaluating `config.systemd.tmpfiles.rules` contains `d /run/lab 0755 lab lab -`. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
lab's podman db predates coding-lab ADR-0060 and still pins its runroot
and tmpdir to /run/lab. After a reboot the directory is gone and the lab
user cannot recreate it under root-owned /run, so container spawns fail.
A tmpfiles rule restores it each boot until `podman system reset` runs.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

Pull request closed

Sign in to join this conversation.
No reviewers
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
Cloonar/nixos!443
No description provided.