examples/vm-selfbuild — a self-rebuilding ElpeOS (template)

Boot an ElpeOS image that runs the elped daemon inside the VM, then run elpe build in the guest. This is the loop that lets ElpeOS rebuild itself — the counterpart to running nixos-rebuild on a NixOS host.

Status: template, pending one prerequisite

The image-side plumbing is complete and wired in build.ml:

• Image.Service.elpe_daemon ships /etc/elpe/config.toml + the elped.service systemd unit (enabled for multi-user.target);
• extra_store_closures bakes the daemon binary and its closure into the image.

What is missing is the payload. daemon_bin must be an absolute Elpe store path of the elped binary, and nothing builds elpe-rs (the Rust daemon) into the store yet: lib/rust/rust.ml has the machinery (compiled_crate, per-crate cargo) but no recipe assembles a runnable elped. Building elpe-rs via Elpe’s own cargo builder is the dogfood milestone that unblocks this example.

Running elpe build here today stops immediately with a precise message from the elped_store placeholder — by design.

What already works (so you know the rest is real)

• In-sandbox elpe lock is validated: cd elpe && elpe lock build.ml runs the opam solve inside the sandbox and writes the lock (exit 0).
• The image pipeline builds end-to-end (deb extraction, postinst-elimination idiom analysis, ESP) — see examples/vm for a bootable image today.
• The OCaml frontend already self-hosts (examples/native-ocaml, doc/authoring-recipes/native-ocaml-build.md). The Rust backend does not yet — that is the gap this example is waiting on.

To finish it

1. Add an elpe-rs cargo derivation producing elpe-daemon, e.g.

   let elped_store =
     new Rust.workspace ~manifest:"elpe-rs" ~bin:"elpe-daemon" ()
   

2. Set daemon_bin to that derivation’s store path + /bin/elpe-daemon.

3. Build the image, boot it (run.sh, like examples/vm), log in, and run elpe build inside the guest against the resident daemon on :50051.