installer-init-system: none (fix for #95) still fails on self-hosted runners without an init system #99

installer-init-system: none (added in #96 to fix #95) does not actually fix nix/devbox usage on self-hosted runners running in a container without an init system (e.g. Kubernetes pods via actions-runner-controller). It changes the installer's config, but the job still fails at the same point with the same underlying error.

Setup

• Self-hosted GitHub Actions runners running as Kubernetes pods (actions-runner-controller gha-runner-scale-set), no systemd / no init system in the container.
• Pinned devbox-install-action to the unreleased main tip (1af623155b1203817421a7efe5574f59f4a055c6, includes feat: make nix installer init system configurable #96 — no tagged release contains it yet).

- name: Install devbox
  uses: jetify-com/devbox-install-action@1af623155b1203817421a7efe5574f59f4a055c6
  with:
    enable-cache: true
    installer-init-system: none

What happens

The install still logs the same self-test warning as #95:

WARN nix_installer::plan: SelfTest([ShellFailed { ... stderr: "error:\n … error: cannot connect to socket at '/nix/var/nix/daemon-socket/socket': No such file or directory\n" } ...])

And then any later devbox/nix command run as the (unprivileged) job user fails:

error: opening lock file "/nix/var/nix/db/big-lock": Permission denied
Error: error installing package openjdk@17
source: nix: command error: nix ... path-info ...: opening lock file "/nix/var/nix/db/big-lock": Permission denied: exit code 1
Error: There was an internal error. Run with DEVBOX_DEBUG=1 for a detailed error message, and consider reporting it at https://github.com/jetify-com/devbox/issues

This matches upstream nix-installer's own documented behavior for --init none: it skips configuring a systemd-managed daemon, but there's still no daemon running afterward, so only root or a user who explicitly elevates (sudo -i nix ...) can use Nix. None of the action's later steps (devbox run --config=... -- echo "Packages installed!", or our own subsequent devbox/terraform/terragrunt calls) elevate via sudo, so they hit the same permission wall #95 originally reported — just via a different code path.

What actually works: pinning to v0.14.0

- name: Install devbox
  uses: jetify-com/devbox-install-action@a0d2d53632934ae004f878c840055956d9f741b0 # v0.14.0
  with:
    enable-cache: true

v0.14.0 still delegates Nix installation to DeterminateSystems/nix-installer-action@v19 instead of invoking the raw experimental installer directly. nix-installer-action has its own force-no-systemd handling ("automatically enabled when necessary") that detects the missing init system and spawns the daemon itself, rather than just omitting the systemd unit. With v0.14.0 pinned (same self-hosted, no-init runner pods, no other changes), devbox installs packages (terraform, terragrunt, node, a JDK) successfully and every job using it passes.

Ask

Given v0.14.0 works correctly in this exact environment and 0.15.0+ doesn't (even with installer-init-system: none), it'd be great to either:

• have the action's own no-init detection actually spawn the daemon directly (matching what nix-installer-action already does), instead of just toggling the installer's --init flag, or
• document clearly that installer-init-system: none requires every subsequent nix/devbox invocation to run as root/sudo, since as shipped it silently doesn't fix the self-hosted/no-init case 0.15.0 is broken on self-hosted runners - no systemd #95 was filed for.

Happy to provide more logs/config if useful.