Prototype: nested rootless Podman for agent containers

kayg commented

2026-09-24 07:42:51 +00:00

Owner

Codex job nested-podman: prove rootless Podman inside the rootless calternal container can run agent containers with persistent storage.

Base: 818bc4d19b

Codex job `nested-podman`: prove rootless Podman inside the rootless calternal container can run agent containers with persistent storage. Base: 818bc4d19bcb86d34df64185faecaf97c1608fc1

kayg commented

2026-09-24 07:43:34 +00:00

Author

Owner

Starting nested rootless Podman prototype. Branch: job/nested-podman; base SHA: 818bc4d19bcb86d34df64185faecaf97c1608fc1. I confirmed the worktree is clean and the host reports Debian 13, Podman 5.4.2, kernel 6.12.69, cgroup v2, and kayg:165536:65536 in /etc/subuid. I’ll test the requested outer/inner behavior and document exact commands, output, limitations, and recommendation in the owned paths.

Starting nested rootless Podman prototype. Branch: `job/nested-podman`; base SHA: `818bc4d19bcb86d34df64185faecaf97c1608fc1`. I confirmed the worktree is clean and the host reports Debian 13, Podman 5.4.2, kernel 6.12.69, cgroup v2, and `kayg:165536:65536` in `/etc/subuid`. I’ll test the requested outer/inner behavior and document exact commands, output, limitations, and recommendation in the owned paths.

kayg commented

2026-09-24 07:49:56 +00:00

Author

Owner

Finding from the first real outer launch: the service starts, but inner namespace creation exits with newuidmap ... 65536 100000 65536: Operation not permitted. useradd inserted Debian's default podman:100000:65536 sub-ID range, which is not mapped into the outer user namespace. The image also had the mapped ranges I configured, so the next iteration removes the invalid default and retries with only IDs mapped by the outer namespace. No security-option conclusion yet.

Finding from the first real outer launch: the service starts, but inner namespace creation exits with `newuidmap ... 65536 100000 65536: Operation not permitted`. `useradd` inserted Debian's default `podman:100000:65536` sub-ID range, which is not mapped into the outer user namespace. The image also had the mapped ranges I configured, so the next iteration removes the invalid default and retries with only IDs mapped by the outer namespace. No security-option conclusion yet.

kayg commented

2026-09-24 07:57:38 +00:00

Author

Owner

Second launch finding: adding --cap-add=SYS_ADMIN to the outer rootless container changes the inner service from exiting on newuidmap to staying up. The service user remains UID/GID 1000; podman info reports rootless: true, cgroup v2, and a valid inner ID map. That trial still had --security-opt=seccomp=unconfined plus SETUID/SETGID; I’m narrowing those flags before treating this as the minimal set.

Second launch finding: adding `--cap-add=SYS_ADMIN` to the outer rootless container changes the inner service from exiting on `newuidmap` to staying up. The service user remains UID/GID 1000; `podman info` reports `rootless: true`, cgroup v2, and a valid inner ID map. That trial still had `--security-opt=seccomp=unconfined` plus `SETUID`/`SETGID`; I’m narrowing those flags before treating this as the minimal set.

kayg commented

2026-09-24 08:13:46 +00:00

Author

Owner

Finding: the inner Docker-compatible API is reachable over /run/user/1000/podman/podman.sock; _ping, /version, Debian image pull, and named-volume create all succeeded. A Docker API container create with HostConfig.UsernsMode=auto created an auto mapping (IDMappings.UidMap=["0:1:1024"]) and the Podman annotation io.podman.annotations.userns=auto, but start returned HTTP 500: crun: write file /proc/307/gid_map: Operation not permitted. The inner engine also logged mkdir /sys/fs/cgroup/init: read-only file system; resource-limit behavior remains under test. I’m adjusting the non-root service UID/sub-ID layout and UID/GID capabilities to test the nested map path.

Finding: the inner Docker-compatible API is reachable over `/run/user/1000/podman/podman.sock`; `_ping`, `/version`, Debian image pull, and named-volume create all succeeded. A Docker API container create with `HostConfig.UsernsMode=auto` created an auto mapping (`IDMappings.UidMap=["0:1:1024"]`) and the Podman annotation `io.podman.annotations.userns=auto`, but start returned HTTP 500: `crun: write file /proc/307/gid_map: Operation not permitted`. The inner engine also logged `mkdir /sys/fs/cgroup/init: read-only file system`; resource-limit behavior remains under test. I’m adjusting the non-root service UID/sub-ID layout and UID/GID capabilities to test the nested map path.

kayg commented

2026-09-24 08:21:17 +00:00

Author

Owner

Finding: after moving the non-root inner service to UID/GID 65536 and giving it the contiguous subordinate range 1:65535, a Docker API container with UsernsMode=auto starts when NetworkMode=host and PidMode=host. Inspect shows a distinct UidMap=["0:1025:1024"] / GidMap=["0:1025:1024"]; the earlier failed creates occupy the first 1024-ID range. The start succeeds, but PID namespace sharing is a production concern, so I’m testing whether a private PID namespace can work with additional inner-container capabilities.

Finding: after moving the non-root inner service to UID/GID 65536 and giving it the contiguous subordinate range 1:65535, a Docker API container with `UsernsMode=auto` starts when `NetworkMode=host` and `PidMode=host`. Inspect shows a distinct `UidMap=["0:1025:1024"]` / `GidMap=["0:1025:1024"]`; the earlier failed creates occupy the first 1024-ID range. The start succeeds, but PID namespace sharing is a production concern, so I’m testing whether a private PID namespace can work with additional inner-container capabilities.

kayg commented

2026-09-24 08:32:17 +00:00

Author

Owner

Finding: --security-opt='unmask=/proc/*' on the outer container resolves the nested crun: mount proc ... Operation not permitted failure while retaining the default seccomp profile. A Docker API container then starts with private PID, host network, and UsernsMode=auto (UidMap=["0:1:1024"]). A per-user named volume mounted as name:/agent-home:U is remapped to that ID slice and writable. The first private-network start now reaches netavark but fails because the minimal outer image lacks the nft executable (nftables error: unable to execute nft: No such file or directory); I’m adding the Debian nftables package. The API HostConfig.Devices request did not appear in inspect, so I’m checking a bind mount for /dev/fuse as the Docker-compatible pass-through.

Finding: `--security-opt='unmask=/proc/*'` on the outer container resolves the nested `crun: mount proc ... Operation not permitted` failure while retaining the default seccomp profile. A Docker API container then starts with private PID, host network, and `UsernsMode=auto` (`UidMap=["0:1:1024"]`). A per-user named volume mounted as `name:/agent-home:U` is remapped to that ID slice and writable. The first private-network start now reaches netavark but fails because the minimal outer image lacks the `nft` executable (`nftables error: unable to execute nft: No such file or directory`); I’m adding the Debian nftables package. The API `HostConfig.Devices` request did not appear in inspect, so I’m checking a bind mount for `/dev/fuse` as the Docker-compatible pass-through.

kayg commented

2026-09-24 08:54:43 +00:00

Author

Owner

Real-machine checks from the API-backed agent prototype:

With UsernsMode=auto, a private bridge container reached https://example.com and opened TCP to the host LAN endpoint 10.69.69.49:22022; its route was default via 10.88.0.1.
A non-root uid=1000(agent) container mounted bindfs from the sole inner device bind /dev/fuse:/dev/fuse. HostConfig.CapAdd=["SYS_ADMIN"] was required; the mount failed with Operation not permitted without it. The default seccomp profile remained enabled.
The outer container can pass the required auto mappings with only outer CAP_SYS_ADMIN; a fresh outer engine also started --userns=auto containers without outer SETUID/SETGID capability additions. Without outer CAP_SYS_ADMIN, the service exited 125: newuidmap: write to uid_map failed: Operation not permitted.
Cgroup limits were accepted by the inner API but unenforced with the ordinary outer mount (memory.max=max, cpu.max=max 100000, pids.max=2048). Adding --systemd=always --cgroupns=private made the cgroup mount writable; API values of 268435456 bytes, 500000000 NanoCPUs and 128 PIDs then appeared as memory.max=268435456, cpu.max=50000 100000, pids.max=128.

Real-machine checks from the API-backed agent prototype: - With `UsernsMode=auto`, a private bridge container reached `https://example.com` and opened TCP to the host LAN endpoint `10.69.69.49:22022`; its route was `default via 10.88.0.1`. - A non-root `uid=1000(agent)` container mounted `bindfs` from the sole inner device bind `/dev/fuse:/dev/fuse`. `HostConfig.CapAdd=["SYS_ADMIN"]` was required; the mount failed with `Operation not permitted` without it. The default seccomp profile remained enabled. - The outer container can pass the required `auto` mappings with only outer `CAP_SYS_ADMIN`; a fresh outer engine also started `--userns=auto` containers without outer `SETUID`/`SETGID` capability additions. Without outer `CAP_SYS_ADMIN`, the service exited 125: `newuidmap: write to uid_map failed: Operation not permitted`. - Cgroup limits were accepted by the inner API but unenforced with the ordinary outer mount (`memory.max=max`, `cpu.max=max 100000`, `pids.max=2048`). Adding `--systemd=always --cgroupns=private` made the cgroup mount writable; API values of 268435456 bytes, 500000000 NanoCPUs and 128 PIDs then appeared as `memory.max=268435456`, `cpu.max=50000 100000`, `pids.max=128`.

kayg commented

2026-09-24 09:44:59 +00:00

Author

Owner

Finding: nested resource limits are enforceable in Podman 5.4.2 when the outer container starts with --systemd=always --cgroupns=private, but the first Docker-compatible API start on a clean graphroot fails with crun: opening file memory.max for writing: No such file or directory. Running one bounded CLI container first initializes the delegated controllers; the next limited API container reports memory.max=268435456, cpu.max=50000 100000, and pids.max=128. run-outer.sh now performs this small bootstrap using a digest-pinned Debian probe image and tags it for subsequent API creates.

Timing experiment: restarting the same stopped bridge-network container fails on its second API start with HTTP 500 and rootless netns: kill network process: permission denied. The smoke script now measures five fresh create + start + wait runs for both the initial and warmed-engine samples, so it records the warm path without hiding that restart limitation.

Finding: nested resource limits are enforceable in Podman 5.4.2 when the outer container starts with `--systemd=always --cgroupns=private`, but the first Docker-compatible API start on a clean graphroot fails with `crun: opening file memory.max for writing: No such file or directory`. Running one bounded CLI container first initializes the delegated controllers; the next limited API container reports `memory.max=268435456`, `cpu.max=50000 100000`, and `pids.max=128`. `run-outer.sh` now performs this small bootstrap using a digest-pinned Debian probe image and tags it for subsequent API creates. Timing experiment: restarting the same stopped bridge-network container fails on its second API start with HTTP 500 and `rootless netns: kill network process: permission denied`. The smoke script now measures five fresh `create + start + wait` runs for both the initial and warmed-engine samples, so it records the warm path without hiding that restart limitation.

kayg commented

2026-09-24 09:55:10 +00:00

Author

Owner

Finding: the reproducible deploy/nested-podman/smoke.sh completed successfully on this VM. It created an Agent-like container through the Docker-compatible API with UsernsMode=auto (uid_map=0 1 1024), mounted bindfs as UID 1000, fetched https://example.com, and connected to the host LAN TCP probe 10.69.69.49:22022. It read memory.max=268435456, cpu.max=50000 100000, and pids.max=128 after the CLI cgroup prewarm.

The script removed and recreated the outer container with the same named state volume; the inner image ID remained f097c58fd6c15c2047e6db69d1471c1d95a23c4d7b3897b9b017022c82a3f349, the smoke-agent definition remained inspectable, and the inner named volume retained persisted-across-outer-recreate.

Timing samples (API create + start + wait, /bin/true, local image, bridge network): cold 9202, 583, 332, 355, 339 ms, p50 355 ms; warm 326, 356, 366, 329, 349 ms, p50 349 ms. The first cold bridge startup was 9.2 seconds. Full details and limitations are in docs/research/nested-podman.md.

Finding: the reproducible `deploy/nested-podman/smoke.sh` completed successfully on this VM. It created an Agent-like container through the Docker-compatible API with `UsernsMode=auto` (`uid_map=0 1 1024`), mounted bindfs as UID 1000, fetched `https://example.com`, and connected to the host LAN TCP probe `10.69.69.49:22022`. It read `memory.max=268435456`, `cpu.max=50000 100000`, and `pids.max=128` after the CLI cgroup prewarm. The script removed and recreated the outer container with the same named state volume; the inner image ID remained `f097c58fd6c15c2047e6db69d1471c1d95a23c4d7b3897b9b017022c82a3f349`, the `smoke-agent` definition remained inspectable, and the inner named volume retained `persisted-across-outer-recreate`. Timing samples (API create + start + wait, `/bin/true`, local image, bridge network): cold `9202, 583, 332, 355, 339 ms`, p50 `355 ms`; warm `326, 356, 366, 329, 349 ms`, p50 `349 ms`. The first cold bridge startup was 9.2 seconds. Full details and limitations are in `docs/research/nested-podman.md`.

kayg commented

2026-09-24 10:04:58 +00:00

Author

Owner

Finished on branch job/nested-podman.

Head SHA: 292a3953bbc0d46ca6960a64cd14d6c665c7ada7.

The prototype and report are committed. The full smoke sequence passed, including API create/start, rootless userns=auto, FUSE mount as UID 1000, internet and LAN TCP access, cgroup values, and image/container/volume persistence through outer recreation. The smoke script cleaned its isolated store. The remaining manually-created test engines were pruned inside their own named graphroots; their exact outer containers, state volumes, and local test tags were removed. No matching test containers, volumes, or image tags remain.

Gate outputs:

sh -n deploy/nested-podman/run-outer.sh deploy/nested-podman/smoke.sh: exit 0, stdout/stderr empty.

git diff --check HEAD^ HEAD: exit 0, stdout/stderr empty.

cargo fmt --check (exit 1):

`cargo metadata` exited with an error: error: could not find `Cargo.toml` in `/home/kayg/Developer/calternal-wt/nested-podman` or any parent directory

This utility formats all bin and lib files of the current crate using rustfmt.

Usage: cargo fmt [OPTIONS] [-- <rustfmt_options>...]

Arguments:
  [rustfmt_options]...  Options passed to rustfmt

Options:
  -q, --quiet
          No output printed to stdout
  -v, --verbose
          Use verbose output
      --version
          Print rustfmt version and exit
      --all
          Format all packages, and also their local path-based dependencies
      --check
          Run rustfmt in check mode
  -p, --package <package>...
          Specify package to format
      --manifest-path <manifest-path>
          Specify path to Cargo.toml
      --message-format <message-format>
          Specify message-format: short|json|human
  -h, --help
          Print help

cargo clippy --all-targets -- -D warnings (exit 101):

error: could not find `Cargo.toml` in `/home/kayg/Developer/calternal-wt/nested-podman` or any parent directory

cargo test (exit 101):

error: could not find `Cargo.toml` in `/home/kayg/Developer/calternal-wt/nested-podman` or any parent directory

cargo clean (exit 101):

error: could not find `Cargo.toml` in `/home/kayg/Developer/calternal-wt/nested-podman` or any parent directory

Finished on branch `job/nested-podman`. Head SHA: `292a3953bbc0d46ca6960a64cd14d6c665c7ada7`. The prototype and report are committed. The full smoke sequence passed, including API create/start, rootless `userns=auto`, FUSE mount as UID 1000, internet and LAN TCP access, cgroup values, and image/container/volume persistence through outer recreation. The smoke script cleaned its isolated store. The remaining manually-created test engines were pruned inside their own named graphroots; their exact outer containers, state volumes, and local test tags were removed. No matching test containers, volumes, or image tags remain. Gate outputs: `sh -n deploy/nested-podman/run-outer.sh deploy/nested-podman/smoke.sh`: exit 0, stdout/stderr empty. `git diff --check HEAD^ HEAD`: exit 0, stdout/stderr empty. `cargo fmt --check` (exit 1): ```text `cargo metadata` exited with an error: error: could not find `Cargo.toml` in `/home/kayg/Developer/calternal-wt/nested-podman` or any parent directory This utility formats all bin and lib files of the current crate using rustfmt. Usage: cargo fmt [OPTIONS] [-- <rustfmt_options>...] Arguments: [rustfmt_options]... Options passed to rustfmt Options: -q, --quiet No output printed to stdout -v, --verbose Use verbose output --version Print rustfmt version and exit --all Format all packages, and also their local path-based dependencies --check Run rustfmt in check mode -p, --package <package>... Specify package to format --manifest-path <manifest-path> Specify path to Cargo.toml --message-format <message-format> Specify message-format: short|json|human -h, --help Print help ``` `cargo clippy --all-targets -- -D warnings` (exit 101): ```text error: could not find `Cargo.toml` in `/home/kayg/Developer/calternal-wt/nested-podman` or any parent directory ``` `cargo test` (exit 101): ```text error: could not find `Cargo.toml` in `/home/kayg/Developer/calternal-wt/nested-podman` or any parent directory ``` `cargo clean` (exit 101): ```text error: could not find `Cargo.toml` in `/home/kayg/Developer/calternal-wt/nested-podman` or any parent directory ```

kayg referenced this issue from a commit

2026-09-24 10:06:36 +00:00

Merge job/nested-podman: nested rootless Podman prototype and report (#6)

kayg commented

2026-09-24 10:34:15 +00:00

Author

Owner

Starting work in job/nested-o2 from base 310465abcd50d3115ec54687d47a4171b04ac756. Initial o2 read-only check found Ubuntu arm64 on kernel 6.17 with Podman 4.9.3; df -h ~ reports 11G available, above the 4G stop threshold. Source inspection shows the Containerfile uses three build-time heredocs and both image references currently use the same digest; I will reproduce the failures before changing either.

Starting work in `job/nested-o2` from base `310465abcd50d3115ec54687d47a4171b04ac756`. Initial o2 read-only check found Ubuntu arm64 on kernel 6.17 with Podman 4.9.3; `df -h ~` reports 11G available, above the 4G stop threshold. Source inspection shows the Containerfile uses three build-time heredocs and both image references currently use the same digest; I will reproduce the failures before changing either.

kayg commented

2026-09-24 10:38:09 +00:00

Author

Owner

Baseline smoke reproduction on o2 (Ubuntu arm64, Podman 4.9.3) exited while executing the first Containerfile RUN: exec /bin/sh: exec format error. The subsequent Buildah error was while running runtime: exit status 255. The Containerfile and run-outer.sh both referenced the amd64 child digest sha256:7792b1f7702a86946cd518db72b6a407302c3e9bc1635634368b878189e8221c; a registry read confirms it is the amd64 child of Debian 13 slim index sha256:a99cfc517144bc59b1978475ec53b46ecabec7e43635402ee5b77cc54cd1b20a, which has an arm64 child. The failure occurred before outer container creation.

Baseline smoke reproduction on o2 (Ubuntu arm64, Podman 4.9.3) exited while executing the first Containerfile `RUN`: `exec /bin/sh: exec format error`. The subsequent Buildah error was `while running runtime: exit status 255`. The Containerfile and `run-outer.sh` both referenced the amd64 child digest `sha256:7792b1f7702a86946cd518db72b6a407302c3e9bc1635634368b878189e8221c`; a registry read confirms it is the amd64 child of Debian 13 slim index `sha256:a99cfc517144bc59b1978475ec53b46ecabec7e43635402ee5b77cc54cd1b20a`, which has an arm64 child. The failure occurred before outer container creation.

kayg commented

2026-09-24 10:40:37 +00:00

Author

Owner

After pinning the verified multi-platform Debian index digest, the o2 run passed the architecture-dependent package-install RUN and reached the first Containerfile heredoc. Podman 4.9.3/Buildah then exited 125 with Build error: Unknown instruction: "[STORAGE]"; the diagnostic identifies [storage] as the parsed Containerfile command. This reproduces the independent heredoc incompatibility.

After pinning the verified multi-platform Debian index digest, the o2 run passed the architecture-dependent package-install `RUN` and reached the first Containerfile heredoc. Podman 4.9.3/Buildah then exited 125 with `Build error: Unknown instruction: "[STORAGE]"`; the diagnostic identifies `[storage]` as the parsed Containerfile command. This reproduces the independent heredoc incompatibility.

kayg commented

2026-09-24 10:45:28 +00:00

Author

Owner

The full smoke passed on o2 with Podman 4.9.3 (arm64, Ubuntu 24.04.4, kernel 6.17.0-1018-oracle). The inner API became ready after cgroup prewarm. API create/start passed with UsernsMode=auto (uid_map=0 1 1024); the Agent reached https://example.com and TCP 10.69.69.52:443; bindfs FUSE passed; limits were memory.max=268435456, cpu.max=50000 100000, pids.max=128; the image ID and named-volume content persisted through outer recreation.

Smoke summary, verbatim:

cold_create_start_wait_p50_ms=164
warm_create_start_wait_p50_ms=172
result=passed

The run's cleanup removed its outer container, state volume, and uniquely tagged image. Follow-up podman ... exists checks returned status 1 for each. Free space remained 9.9G. Host info reports rootless=true, netavark, cgroups=v2, manager=systemd.

The full smoke passed on o2 with Podman 4.9.3 (arm64, Ubuntu 24.04.4, kernel 6.17.0-1018-oracle). The inner API became ready after cgroup prewarm. API create/start passed with `UsernsMode=auto` (`uid_map=0 1 1024`); the Agent reached `https://example.com` and TCP `10.69.69.52:443`; bindfs FUSE passed; limits were `memory.max=268435456`, `cpu.max=50000 100000`, `pids.max=128`; the image ID and named-volume content persisted through outer recreation. Smoke summary, verbatim: ```text cold_create_start_wait_p50_ms=164 warm_create_start_wait_p50_ms=172 result=passed ``` The run's cleanup removed its outer container, state volume, and uniquely tagged image. Follow-up `podman ... exists` checks returned status 1 for each. Free space remained 9.9G. Host info reports rootless=true, netavark, cgroups=v2, manager=systemd.

kayg commented

2026-09-24 11:12:13 +00:00

Author

Owner

Completed on branch job/nested-o2.

Head SHA: 134dcc3740cccee3fffef22ddb41c4b7cd0dfb93

Verdict: nested rootless Podman works on o2 (Ubuntu 24.04.4, arm64, kernel 6.17, host Podman 4.9.3) with the listed workarounds. The image now pins the multi-arch Debian index digest; the Containerfile uses COPY-ed config files instead of heredocs. The run passed API create/start, userns=auto, internet and LAN probes, FUSE, resource limits, and persistence across outer recreation. The 5.4.2 amd64 VM also passed the portability rerun.

Commits:

4fd4bc0 fix(deploy): pin Debian multi-arch index digest
24240dc fix(deploy): support Podman 4.9 Containerfiles
551a15a docs(research): record Podman 4.9 o2 smoke results
134dcc3 docs(research): attribute bridge restart failure to VM

Gates: sh -n deploy/nested-podman/run-outer.sh deploy/nested-podman/smoke.sh deploy/nested-podman/inner-podman-service passed with no output; git diff --check, cargo fmt --check, and clippy passed with no output; cargo test passed (448 passed, 1 ignored, 0 failed); bun run check reported svelte-check found 0 errors and 0 warnings; bun run test reported Test Files 1 passed and Tests 1 passed.

O2 smoke summary (verbatim):

cold_create_start_wait_p50_ms=164
warm_create_start_wait_p50_ms=172
result=passed

Local VM smoke summary (verbatim):

cold_create_start_wait_p50_ms=687
warm_create_start_wait_p50_ms=620
result=passed

cargo clean output: Removed 6464 files, 2.7GiB total. The worktree is clean. Known gaps and owner decisions are recorded in docs/research/nested-podman.md; notably, the stopped-bridge restart failure was observed on the 5.4.2 VM and was not tested on o2, and the cross-combinations 4.9.3/amd64 and 5.x/arm64 remain untested.

Completed on branch `job/nested-o2`. Head SHA: `134dcc3740cccee3fffef22ddb41c4b7cd0dfb93` Verdict: nested rootless Podman works on o2 (Ubuntu 24.04.4, arm64, kernel 6.17, host Podman 4.9.3) with the listed workarounds. The image now pins the multi-arch Debian index digest; the Containerfile uses `COPY`-ed config files instead of heredocs. The run passed API create/start, `userns=auto`, internet and LAN probes, FUSE, resource limits, and persistence across outer recreation. The 5.4.2 amd64 VM also passed the portability rerun. Commits: - `4fd4bc0` fix(deploy): pin Debian multi-arch index digest - `24240dc` fix(deploy): support Podman 4.9 Containerfiles - `551a15a` docs(research): record Podman 4.9 o2 smoke results - `134dcc3` docs(research): attribute bridge restart failure to VM Gates: `sh -n deploy/nested-podman/run-outer.sh deploy/nested-podman/smoke.sh deploy/nested-podman/inner-podman-service` passed with no output; `git diff --check`, `cargo fmt --check`, and clippy passed with no output; `cargo test` passed (448 passed, 1 ignored, 0 failed); `bun run check` reported `svelte-check found 0 errors and 0 warnings`; `bun run test` reported `Test Files 1 passed` and `Tests 1 passed`. O2 smoke summary (verbatim): ``` cold_create_start_wait_p50_ms=164 warm_create_start_wait_p50_ms=172 result=passed ``` Local VM smoke summary (verbatim): ``` cold_create_start_wait_p50_ms=687 warm_create_start_wait_p50_ms=620 result=passed ``` `cargo clean` output: `Removed 6464 files, 2.7GiB total`. The worktree is clean. Known gaps and owner decisions are recorded in `docs/research/nested-podman.md`; notably, the stopped-bridge restart failure was observed on the 5.4.2 VM and was not tested on o2, and the cross-combinations 4.9.3/amd64 and 5.x/arm64 remain untested.

kayg referenced this issue from a commit

2026-09-24 11:14:47 +00:00

Merge job/nested-o2: nested Podman runs on o2 (Podman 4.9.3, arm64) (#6)

kayg commented

2026-10-01 05:08:20 +00:00

Author

Owner

Completed on dev in dcc806f4c6 (Merge job/nested-o2: nested Podman runs on o2 (Podman 4.9.3, arm64) (#6)).

Completed on dev in dcc806f4c625cccaeb47de0f52ee2a7355a6a628 (Merge job/nested-o2: nested Podman runs on o2 (Podman 4.9.3, arm64) (#6)).

kayg closed this issue

2026-10-01 05:08:21 +00:00

kayg referenced this issue