40 lines
3.2 KiB
Markdown
40 lines
3.2 KiB
Markdown
# skz-sloptrap
|
|
|
|
This workspace is the source code of `sloptrap`, eg. your own runtime.
|
|
Your author, 'sk4nz', has ran the command `sloptrap path/to/skz-sloptrap` and you are living in your own reflection.
|
|
|
|
# Recursive `slopsloptrap`
|
|
|
|
sloptrap can recurse.
|
|
|
|
If you need to prove it, spawn a child from this repo with sloptrap:
|
|
|
|
`./sloptrap /workspace ...`
|
|
|
|
This starts a child `slopsloptrap`. Use the child normally, as the end-user would.
|
|
|
|
# Keep Memory
|
|
|
|
Future sloptrap instances should add short, useful, durable notes they learn during their session to this file.
|
|
|
|
Only add high-signal information that is likely to help later runs.
|
|
Keep additions brief.
|
|
Do not remove existing instructions unless they are outdated or wrong.
|
|
|
|
---
|
|
# Session Memory
|
|
|
|
- When you make changes that affect how the runtime behaves and cannot test it with recursion, you can ask sk4nz to restart you.
|
|
- If recursion is blocked by the current session state and a restart is required, give sk4nz an exact prompt to paste into the next restarted session so it can continue from the current checkpoint.
|
|
- Useful checks in the skz-sloptrap repo:
|
|
`shellcheck sloptrap`
|
|
`bash tests/run_tests.sh` (you can also run them separately)
|
|
- Recursive nested-podman inside an already user-namespaced sloptrap needs subuid/subgid ranges derived from `/proc/self/uid_map` and `/proc/self/gid_map`; hardcoding `100000:65536` breaks `newuidmap`.
|
|
- When running tests from inside sloptrap, inherited `CODEX_HOME=/codex` plus `SLOPTRAP_PREFER_CODEX_HOME=1` can leak into host-style child launches; ignore that preference when `HOME` has been redirected elsewhere and the runtime hints still point into the inherited `/codex` tree.
|
|
- For real recursive `./sloptrap` launches, correct `/proc/self/uid_map` alone is not enough: if the current session still has stale read-only `/etc/subuid` and `/etc/subgid` mounts (for example `sk4nz:100000:65536`), the first nested podman launch still fails before child startup.
|
|
- Forcing `SLOPTRAP_CONTAINER_ENGINE=sloppodman` inside sloptrap also needs `TMPDIR` under `/workspace`; otherwise its build-context path guard rejects the staged Dockerfile under `/tmp` before you reach the real subuid/subgid problem.
|
|
- If a restarted session still inherits stale read-only `/etc/subuid` and `/etc/subgid` tmpfs mounts, an unprivileged agent cannot repair them in-place (`umount` says `must be superuser to unmount`); both podman and sloppodman stay blocked until the session starts without those mounts.
|
|
- Outer sloptrap launches no longer need `/etc/subuid` or `/etc/subgid` bind mounts: `nested-podman` now disables read-only rootfs and the container entrypoint synthesizes container-local subid files from `/proc/self/{uid,gid}_map` before dropping privileges.
|
|
- With stale subid mounts gone, recursive `./sloptrap /workspace` can still fail earlier during the inner image build: `crun` tries to open `/proc/sys/net/ipv4/ping_group_range` and gets `Read-only file system` while creating the build container.
|
|
- In a fragile nested-podman session, `podman system migrate` can make things worse: a state that still answered `podman info` fell back to repeated `newuidmap ... write to uid_map failed: Operation not permitted` failures afterward.
|