What happened?
On stock ghcr.io/projectbluefin/dakota:stable, Project Bluefin's ujust recipes invoke podman through the user's PATH. Homebrew precedes /usr/bin, so they select Homebrew Podman 6.0.2:
podman is /home/linuxbrew/.linuxbrew/bin/podman
podman is /usr/bin/podman
Homebrew Podman is installed as a dependency of podman-compose.
ujust clean-system
Both Podman cleanup operations fail:
Error: configure storage: open /var/lib/containers/storage/storage.lock: open /var/lib/containers/storage/storage.lock: permission denied
Error: configure storage: open /var/lib/containers/storage/storage.lock: open /var/lib/containers/storage/storage.lock: permission denied
The OS-managed binary initializes correctly as rootless:
/usr/bin/podman info
runRoot=/run/user/1000/containers
graphRoot=/home/kdlocpanda/.local/share/containers/storage
rootless=true
Impact on the reporter currently shipped by Dakota stable
Dakota stable still ships the older v0.1 reporter. Its optional containerized OTel collector also calls unqualified podman and fails:
Collector output:
inappropriate ioctl for device
Diagnostic gist: https://gist.github.com/joshyorko/d68f272d22507a841ae6f86c38faa968
Expected behavior
OS-provided maintenance recipes should use the OS-managed Podman and operate on the user's rootless container storage, regardless of whether Homebrew has linked another podman binary earlier in PATH.
Steps to reproduce
- Boot an image consuming Project Bluefin Common; reproduced on stock Dakota stable.
- Install Homebrew
podman-compose, which links Homebrew podman.
- Confirm
type -a podman lists Homebrew before /usr/bin/podman.
- Run
ujust clean-system and accept Podman cleanup.
- Observe both prune operations fail with storage permission errors.
- Run
/usr/bin/podman info and confirm the system binary initializes correctly as rootless.
- On Dakota stable's currently shipped v0.1 reporter, enable deep metrics and observe its Podman collector failure.
Source ownership and propagation
The canonical shared recipe is:
system_files/shared/usr/share/ublue-os/just/default.just
Dakota also carries:
files/just-overrides/default.just
Its clean-system implementation duplicates the same unqualified Podman calls, so the fix should be propagated there as well.
Common v0.2 removed the OTel capture path, so no reporter change is requested here. The reporter symptom only demonstrates the impact of unqualified runtime resolution in the older shared tooling still present on Dakota stable.
Acceptance criteria
- The canonical Common
clean-system recipe resolves the OS-managed Podman independently of the user's Homebrew PATH.
- Rootless image and volume pruning works when Homebrew
podman-compose has linked Homebrew Podman first in PATH.
- Existing confirmation and cleanup behavior remains unchanged.
- Dakota's
files/just-overrides/default.just receives the equivalent fix through the normal cross-repository propagation process.
What happened?
On stock
ghcr.io/projectbluefin/dakota:stable, Project Bluefin's ujust recipes invokepodmanthrough the user'sPATH. Homebrew precedes/usr/bin, so they select Homebrew Podman 6.0.2:Homebrew Podman is installed as a dependency of
podman-compose.ujust clean-systemBoth Podman cleanup operations fail:
The OS-managed binary initializes correctly as rootless:
Impact on the reporter currently shipped by Dakota stable
Dakota stable still ships the older v0.1 reporter. Its optional containerized OTel collector also calls unqualified
podmanand fails:Diagnostic gist: https://gist.github.com/joshyorko/d68f272d22507a841ae6f86c38faa968
Expected behavior
OS-provided maintenance recipes should use the OS-managed Podman and operate on the user's rootless container storage, regardless of whether Homebrew has linked another
podmanbinary earlier inPATH.Steps to reproduce
podman-compose, which links Homebrewpodman.type -a podmanlists Homebrew before/usr/bin/podman.ujust clean-systemand accept Podman cleanup./usr/bin/podman infoand confirm the system binary initializes correctly as rootless.Source ownership and propagation
The canonical shared recipe is:
system_files/shared/usr/share/ublue-os/just/default.justDakota also carries:
files/just-overrides/default.justIts
clean-systemimplementation duplicates the same unqualified Podman calls, so the fix should be propagated there as well.Common v0.2 removed the OTel capture path, so no reporter change is requested here. The reporter symptom only demonstrates the impact of unqualified runtime resolution in the older shared tooling still present on Dakota stable.
Acceptance criteria
clean-systemrecipe resolves the OS-managed Podman independently of the user's HomebrewPATH.podman-composehas linked Homebrew Podman first inPATH.files/just-overrides/default.justreceives the equivalent fix through the normal cross-repository propagation process.