hammer/docs/runbooks/stage1-vm-boot.md

Runbook — validar Stage 1 booteando en QEMU

Operativo, no diseño. Valida end-to-end que el rootfs que produce hammer bootstrap stage1 (SDD 11) bootea con arje-zero como PID 1 (SDD 12), levanta hammerd + getty bajo supervisión, y que el CRASHED real funciona.

Esto es un procedimiento, no un transcript verificado. La lógica de ensamblado/hash/seed está cubierta por unit tests (y la seed se validó contra card_core::Card), pero el cross-compile y el boot reales no se han corrido todavía — ese es justo el punto de este runbook. La primera corrida puede destapar ajustes (link, /dev/console, getty/tty); §7 los anticipa.

0. Lo que valida / lo que no

• Valida: que el árbol sellado por stage1 arranca como sistema: arje-zero monta los pseudo-FS, carga la seed, incarna hammerd y la getty, y al matar hammerd lo reinicia con backoff (el CRASHED que la Fase 5 difirió).
• No valida (aún): bus único (B.2), overlay del store (I4), atestación (A1/A2), kernel from-source. Aquí el kernel es prestado del host; el overlay no se monta.

1. Prerrequisitos

• Lab de dev montado: ./scripts/bootstrap-devfs.sh (deja .dev-fs/alpine + .dev-fs/tools/zig).
• Red: el build de hammerd y arje-zero clona repos git (hammer, tawasuyu) y corre cargo vendor en el fetch. El build hermético del sandbox es --offline, pero el fetch necesita red.
• Herramientas host: qemu-system-x86_64, un kernel x86_64 (/boot/vmlinuz-*), cpio, gzip.
• Espacio/tiempo: construir arje-zero vendorea las deps del monorepo tawasuyu entero — es pesado y lento la primera vez (se cachea después).
• El binario hammer: cargo build --release -p hammer-cli ⇒ ./target/release/hammer.

El store debe vivir en la raíz del repo (./store) para que BuildConfig resuelva .dev-fs/alpine como hermano (store/.. = repo root). El toolchain de Stage 1 no es el de .dev-fs: es la semilla de Stage 0 (paso 2), que stage1 enchufa como zig_dir del sandbox.

2. Stage 0 — ingerir la semilla (zig)

export HAMMER=./target/release/hammer
export STORE=./store

"$HAMMER" --store "$STORE" bootstrap stage0 \
  --url https://ziglang.org/download/0.16.0/zig-x86_64-linux-0.16.0.tar.xz \
  --sha256 70e49664a74374b48b51e6f3fdfbf437f6395d42509050588bd49abe52ba3d00 \
  --version 0.16.0
# → imprime el seed_hash (b3:...). Guardalo:
SEED="b3:..."   # pegá el hash impreso

Idempotente: re-correr no re-descarga. La semilla queda sellada como seed-zig en el store y anota su línea en bootstrap.json.

3. Stage 1 — construir y sellar el rootfs

"$HAMMER" --store "$STORE" bootstrap stage1 --seed-hash "$SEED" --recipes recipes
# construye musl + busybox + hammerd + arje-zero, ensambla el rootfs FHS y lo sella.
# → imprime el rootfs_hash (b3:...).

# El árbol sellado (read-only) del rootfs:
ROOTFS_DIR=$(ls -d "$STORE"/*-stage1-rootfs)
echo "$ROOTFS_DIR"
ls "$ROOTFS_DIR"/ente/seed.card.json "$ROOTFS_DIR"/sbin/init "$ROOTFS_DIR"/usr/bin/{hammerd,arje-zero}

Necesita red (git clone + cargo vendor). Si un build Cargo falla en el link (-lgcc_s) o por static-PIE, ver §7 — el zig cc del lab debería resolver -lgcc_s (bitácora M2 del plan arje↔hammer).

4. Empaquetar el rootfs como initramfs

El árbol del store ya trae /sbin/init→/usr/bin/arje-zero y /ente/seed.card.json. Se empaqueta como cpio newc + gzip (formato initramfs):

( cd "$ROOTFS_DIR" && find . -print0 | cpio --null -o --format=newc ) | gzip -9 > /tmp/stage1.cpio.gz
ls -lh /tmp/stage1.cpio.gz

cpio newc preserva symlinks y hardlinks. El symlink /sbin/init→/usr/bin/arje-zero es absoluto: en un initramfs resuelve dentro de su propia raíz. (Si el kernel no auto-monta devtmpfs, ver §7 por el nodo /dev/console.)

5. Bootear en QEMU

qemu-system-x86_64 -m 512 -nographic \
  -kernel /boot/vmlinuz-linux \
  -initrd /tmp/stage1.cpio.gz \
  -append "console=ttyS0 rdinit=/sbin/init"

• rdinit=/sbin/init — el default de un initramfs es /init; lo sobreescribimos a /sbin/init (→arje-zero). Alternativa directa: rdinit=/usr/bin/arje-zero.
• console=ttyS0 + -nographic — consola serie, donde arje escribe y la getty se engancha.
• Salir de QEMU: Ctrl-A luego X.

6. Criterios de éxito (qué observar)

1. PID 1: en kmsg/consola, arje-zero loguea "despierta como PID 1".
2. Pseudo-FS: monta /proc /sys /dev sin error fatal (best-effort; un EBUSY se ignora).
3. Seed: carga /ente/seed.card.json sin "card inválida" (ya validada contra card_core::Card).
4. hammerd: arranca como Ente — su tracing aparece y/o crea /run/agent.sock.
5. getty: aparece un prompt de shell (/bin/sh) en ttyS0.
6. CRASHED real — la prueba clave. En el shell:

   kill "$(pidof hammerd)"
   

   arje registra el on_death(ExitStatus) y reinicia hammerd tras el backoff (200 ms → ×2…). Eso es el CRASHED que la Fase 5 dejó diferido, ahora manejado por el init propio.

7. Troubleshooting (síntoma → causa → fix)

Síntoma	Causa probable	Fix
Kernel panic … no init found	/sbin/init no ejecuta	probar rdinit=/usr/bin/arje-zero; verificar que el symlink quedó en el cpio (cpio -tv)
arje cae a rescue shell "card inválida"	la seed no validó	confirmar que /ente/seed.card.json se empaquetó; comparar con el schema de seeds/arje-qemu.card.json
hammerd/arje-zero: exec format error	binario no estático / falta loader	confirmar link = "static"; un static-PIE pide /lib/ld-musl-x86_64.so.1 — para init-clásico desactivar PIE (-C relocation-model=static, bitácora M2)
Build Cargo falla en -lgcc_s	hueco del toolchain musl dinámico	el lab usa zig cc (empaqueta su compiler-rt) → no debería aparecer; verificar compiler = "zig-cc" en la receta
getty sin prompt	device console no engancha tty	probar argv con ttyS0 en vez de console; revisar que /dev/console existe
No working init / sin /dev/console	kernel sin auto-mount de devtmpfs	crear el nodo en el cpio (mknod -m 600 dev/console c 5 1 antes de empaquetar) o usar un kernel con CONFIG_DEVTMPFS_MOUNT=y
cargo vendor / git clone falla	el fetch necesita red	correr Stage 1 con red; el sandbox de build sigue siendo --offline

8. Bitácora — primera corrida real (2026-06-11)

Corrida en el host de desarrollo (Artix). Resultado: el userland C builda end-to-end; el camino Rust está bloqueado por una decisión de toolchain. Hallazgos, en orden:

#	Etapa	Resultado
1	Lab (bootstrap-devfs.sh)	✅ Alpine + zig 0.16.0 + 43 build-tools
2	Stage 0 (ingerir zig)	✅ seed_hash sellado, idempotente
3	musl 1.2.5	✅ cross-compila con zig cc y se sella — el cross-compile C hermético funciona
4	busybox 1.36.1	✅ tras tres fixes (abajo); compila y linkea con zig cc, se sella
5	hammerd (Cargo)	❌ bloqueado: triple de toolchain (abajo)
6	arje-zero (Cargo)	⏸ no alcanzado (mismo bloqueo; además vendorea el monorepo entero)

Fixes aplicados a recipes/busybox.toml (incompatibilidades GNU-toolchain ↔ zig, esperadas):

1. gcc hardcodeado. El Kbuild de busybox fija CC = gcc / HOSTCC = gcc con = (ignora el env CC del sandbox). Fix: pasar CC='zig cc' HOSTCC='zig cc' en línea de comando de make.
2. Flags GNU-ld que zig cc rechaza. El link pasa -Wl,--warn-common, -Wl,-Map,…, -Wl,--verbose; zig cc valida los -Wl, y aborta. Fix: quitarlos de scripts/trylink con sed.
3. (gcc para herramientas host como fixdep y gcc-version.sh lo cubre el mismo HOSTCC.)

Bloqueo del camino Rust — decisión de toolchain (plan C.2):

• El vendoring (Lote 6) corre OK en el fetch (host, con red). El cargo build corre en el sandbox.
• Se añadió rust cargo al rootfs (apk) — pero el rust de Alpine tiene host triple x86_64-alpine-linux-musl, mientras BuildSys::Cargo pide --target x86_64-unknown-linux-musl. Alpine no trae ese std y no hay rustup → error[E0463]: can't find crate for core.
• Opciones (a decidir): (A) construir nativo sin --target (el sandbox ya es x86_64 musl) — cambio en BuildSys::Cargo; (B) recetas Cargo con target = "x86_64-alpine-linux-musl" — leakage de Alpine; (C) rustup en el sandbox + rustup target add — pierde hermeticidad/pin. Es la misma tensión de "pin de toolchain entra al hash" que el plan C.2 dejó abierta.

Stage 1 completo + intento de boot

Tras los fixes, los 4 componentes buildan y el rootfs se sella (musl+busybox+hammerd+arje-zero, 29 MB; /sbin/init→arje-zero, /ente/seed.card.json, loader musl). Se empaquetó como initramfs (cpio newc+gzip, 11 MB) y se booteó en QEMU. La cadena de hallazgos del boot:

1. AVX. El CPU default de QEMU (qemu64) no tiene AVX, pero los binarios (zig/rust nativos) emiten vxorps → SIGILL (invalid_op) en el loader → init muere. Fix: -cpu Broadwell (AVX2 bajo TCG; sin /dev/kvm no hay -cpu host). Para un distro real: compilar a un baseline x86-64 genérico, no al CPU del builder.
2. musl dinámico. El rust de Alpine produce binarios dinámicos (DT_NEEDED libc.musl-x86_64.so.1), no crt-static. El loader corre pero no resuelve memcpy/memset/log2/…: nuestro libc.so (musl 1.2.5 shared con zig cc) tiene 1586 dyn-syms pero no exporta esos símbolos. → Error relocating /sbin/init: memcpy: symbol not found → init muere.

Conclusión. El bootstrap C (musl+busybox+zig cc) y el build Rust nativo (hammerd y arje-zero compilan y se sellan) están validados end-to-end; el kernel arranca el initramfs y ejecuta arje-zero como PID 1. El último bloqueo del boot es el linking dinámico de musl: el fix correcto y golden-path es crt-static — compilar los componentes Rust con -C target-feature=+crt-static -C relocation-model=static para binarios autocontenidos (sin libc.so, sin loader, sin soname, como busybox). Requiere rebuild de hammerd/arje-zero (el de arje-zero vendorea el monorepo: caro en tiempo y disco). Es la realización plena de la "vía de oro" estática de hammer y cierra de paso el problema del soname de Alpine.

Actualización (Opción A implementada). BuildSys::Cargo ahora construye nativo sin --target cuando el target es el del sandbox (SANDBOX_NATIVE_TARGET), con un wrapper .hammer-zig-cc que (a) resuelve el zig cc de dos palabras para cargo/cc-rs y (b) sanea el triple que cc-rs pasa (--target=x86_64-alpine-linux-musl → x86_64-linux-musl, que zig sí entiende). Resultado: hammerd compila nativo y se sella ✓ — el camino Rust funciona. arje-zero queda bloqueado por otra razón: tawasuyu no commitea Cargo.lock (git ls-files Cargo.lock vacío), así que el git archive no lo trae y cargo vendor --locked no puede crearlo. Decisión pendiente: commitear el lock en tawasuyu (reproducible, plan C.2 #5) vs relajar --locked en el vendoring de hammer.

Cierres posteriores. (1) Vendoring --locked condicional al lock committeado → arje-zero vendorea sin --locked (genera el lock) y se sella: los 4 componentes buildan. (2) Boot: AVX → -cpu Broadwell; y el linking dinámico de musl (Alpine rust es dinámico por defecto → DT_NEEDED libc.musl-x86_64.so.1; nuestro libc.so no exporta memcpy/…) → fix crt-static. (3) Iteración del crt-static (cada paso destapó el siguiente; hammerd valida barato): +crt-static [-C relocation-model=static] en RUSTFLAGS rompe los proc-macros (dylibs PIC) en build nativo → solución: cargo rustc --release … -- <flags>, que aplica los flags sólo a la crate top-level. musl vuelve a --disable-shared (no se necesita loader).

✅ BOOT LOGRADO (2026-06-11)

Con cargo rustc -- +crt-static -C relocation-model=static, arje-zero y hammerd salen statically linked (ET_EXEC, sin DT_NEEDED, sin interpreter), el rootfs se sella, y el boot en QEMU (-cpu Broadwell) levanta el sistema:

arje_zero: ente-zero despierta como PID 1
arje_zero::seed: Tarjeta Semilla cargada y validada  path=/ente/seed.card.json
arje_zero: Ente #0 entra al bucle primordial  label=hammer-stage1
arje_zero::graph::lifecycle: instanciando genesis  count=2
  Ente encarnado  label=hammerd        pid=Some(Pid(59))
  Ente encarnado  label=console-getty  pid=Some(Pid(60))
~ #                                          (shell en consola)
hammerd: arranque  agent_sock=/run/agent.sock …
hammerd: watcher fanotify activo
hammerd::bus: escuchando  sock=/run/agent.sock

arje-zero es PID 1, carga+valida la seed y supervisa hammerd + getty; hammerd corre con su watcher fanotify y su agent.sock. Stage 1 bootea end-to-end. Comando reproducible: qemu-system-x86_64 -m 512 -no-reboot -nographic -cpu Broadwell -kernel <vmlinuz> -initrd stage1.cpio.gz -append "console=ttyS0 rdinit=/sbin/init".

✅ CRASHED real demostrado (lo que la Fase 5 difirió)

Desde la shell de la consola, kill $(pidof hammerd) y arje-zero lo supervisa de verdad:

kill $(pidof hammerd)
arje_zero::graph::lifecycle: Ente disuelto      label=hammerd  status=Killed(SIGTERM)
arje_zero::graph::lifecycle: Restart programado label=hammerd  delay_ms=200
arje_zero::graph::lifecycle: Ente encarnado     label=hammerd  pid=Some(Pid(64))
hammerd: arranque  agent_sock=/run/agent.sock …

Detecta la muerte con su ExitStatus (Killed(SIGTERM)), programa el restart con backoff (200 ms) y re-encarna hammerd (pid 59→64). Es la supervisión real del init propio — el CRASHED que ADR 0007 prometía y la Fase 5 había diferido. Exponerlo a la capa de IA por agent.sock es B.2 (bus único).

8b. Stage 2 — verificación de reproducibilidad (pre-rebuild-in-rootfs)

El stage2 de hammer ancla el content-hash (ArtifactHash::of_tree, los bytes reales) del rootfs y lo compara con un rebuild. El rebuild dentro del rootfs usando sólo las herramientas de Stage 1 (auto-alojamiento pleno) necesita un builder rootfs — el Stage 1 mínimo es un runtime (no trae zig/make/cargo), así que ese paso es un hito aparte. Lo que sí se verificó acá: la bit-reproducibilidad del build (dos builds independientes del mismo componente → diff -r):

Componente	Reproducible	Notas
musl 1.2.5	✅ byte-idéntico	el build C con zig cc es determinista de fábrica
busybox 1.36.1	✅ tras dos fixes	(ver abajo)
hammerd (Rust)	✅ byte-idéntico	crt-static + cargo --locked + SOURCE_DATE_EPOCH + paths fijos /src + el workspace de hammer pinea codegen-units = 1 ⇒ rust reproducible
arje-zero (Rust)	✅ tras fix codegen-units	dos builds del host divergían ~10 KB repartidos por .text/.rodata/.eh_frame: el workspace tawasuyu no fija [profile.release] → cargo usa el default codegen-units = 16 y el codegen paralelo de rustc no es reproducible. Fix: el sandbox impone CARGO_PROFILE_RELEASE_CODEGEN_UNITS=1 para todas las crates (ver nota de cierre §8c). Verificado: dos builds cu=1 → byte-idénticos

La verificación cazó dos no-determinismos reales en busybox (justo lo que SDD 09 §2 pide):

1. Config interactiva. Tras editar .config, el compile corre silentoldconfig, que ante opciones NEW (WERROR, etc.) prompea leyendo stdin → el set de applets salía distinto por corrida (build no-determinista y flaky). Fix: yes '' | make oldconfig (acepta defaults, determinista; busybox 1.36.1 no tiene olddefconfig).
2. Headers del kernel. Con el config determinista, los applets de console-tools exigen linux/kd.h (UAPI) que zig no bundlea → linux-headers en el lab (bootstrap-devfs.sh); zig cc nativo los encuentra en /usr/include.

Con ambos, musl y busybox reconstruyen bit-idéntico. Sumados hammerd y arje-zero (este último tras el fix de codegen-units, nota de cierre §8c), los 4 componentes reconstruyen byte-a-byte — cada uno verificado con dos builds independientes del host. Lo único que le queda a Stage 2 es el rebuild dentro de un builder rootfs (un Stage 1 que incluya el toolchain) — el auto-alojamiento pleno, un hito propio (el Stage 1 mínimo es runtime, sin compilador).

8c. Builder rootfs — el rebuild in-rootfs (auto-alojamiento, SDD 11 §7)

Variante (b) — auto-alojamiento puro — CERRADA. Este §8c cubre el mecanismo con toolchain Alpine (variante a). Para el toolchain construido por hammer desde fuente (make/busybox/coreutils/ bwrap/linux-headers + rust + binutils) y la verificación capstone de los 6 swaps juntos in-VM, ver self-hosting-toolchain.md.

El ensamblado del builder ya está implementado (hammer bootstrap builder, SDD 11 §7.4; variante a, toolchain desde Alpine). Produce, sobre el Stage 1 rootfs, una imagen con el toolchain adentro lista para reconstruirse a sí misma. Receta operacional:

1. Binario hammer estático (musl). El builder lo bootea como PID-algo en la VM, así que debe ser autocontenido (como hammerd/arje-zero, crt-static — §7):

cargo build --release --target x86_64-unknown-linux-musl -p hammer-cli
# (o cargo rustc -- -C target-feature=+crt-static, según el camino de oro del boot)

2. Ensamblar el builder anclando la referencia of_tree(stage1) (la que imprimió stage2):

hammer --store store bootstrap builder \
    --stage1 b3:<STAGE1> --seed-hash b3:<SEED> \
    --hammer-bin target/x86_64-unknown-linux-musl/release/hammer \
    --toolchain .dev-fs/alpine --toolchain-tag alpine-3.23.4 \
    --ref-content b3:<OF_TREE_STAGE1> \
    --work-cache work \
    --out work/builder-rootfs

--work-cache work embebe sólo work/repos (mirrors git) y work/tarballs (descargas verificadas) en /work ⇒ rebuild offline y determinista en la VM (de ahí fetch rematerializa los árboles fuente). No copia work/sources (los árboles ya materializados): es regenerable y pesa varios GB. Sin --work-cache, el rebuild fetchea por red (la seed card trae networking: full).

3. Empaquetar como initramfs y bootear (igual que §4/§7, -cpu Broadwell por AVX). El script scripts/boot-builder-vm.sh encapsula esto (kernel, MEM, KVM configurables):

# --owner=root:root es OBLIGATORIO: si los ficheros viajan con el uid del que armó el builder
# (p. ej. 1000), ese uid no está mapeado en el userns de bwrap (mapea 0→0) y el copy-up de overlay
# del sandbox falla con EACCES (`Can't mkdir /opt/zig: Permission denied`).
( cd work/builder-rootfs && find . -print0 | cpio --null -o -H newc --owner=root:root | gzip -1 ) > work/builder.cpio.gz
./scripts/boot-builder-vm.sh        # o el qemu crudo:
qemu-system-x86_64 -m 6144 -no-reboot -nographic -cpu Broadwell \
    -kernel /boot/vmlinuz-linux -initrd work/builder.cpio.gz -append "console=ttyS0 rdinit=/sbin/init"

RAM. El initramfs se desempaqueta a un tmpfs (~1.2 GB) y el rebuild Rust necesita varios GB más, TODO en RAM. Con host ~7 GB y sin KVM va justo y lento (TCG). Sube MEM o monta un disco para /work si el rebuild muere por OOM.

✅ Boot del builder confirmado (2026-06-11). El initramfs (410 MB gz, 26 776 entradas) bootea end-to-end: arje-zero despierta como PID 1, carga+valida la seed card, instancia los 2 genesis (hammerd pid 60 + console-getty pid 61), hammerd levanta su watcher fanotify y el agent.sock, y la getty deja la shell ~ # en consola. Idéntico al boot de Stage 1 (§7) pero con el toolchain adentro — listo para el rebuild.

4. Dentro de la VM, desde la shell de la consola, correr el driver embebido:

rebuild-stage1
# >> rebuild stage1 (toolchain in-rootfs, semilla b3:3ce721ec…)
# >> stage1' = b3:…
# ✓ REPRODUCIBLE: stage1' == stage1 (auto-alojado bit a bit)     ← of_tree(stage1')==REF_CONTENT

rebuild-stage1 apunta HAMMER_ROOTFS=/toolchain, corre hammer bootstrap stage1 con la semilla y las recetas de adentro, y compara con stage2 --verify $REF_CONTENT. ✓ REPRODUCIBLE cierra el auto-alojamiento end-to-end de la variante (a); ✗ DIVERGENTE caza un no-determinismo nuevo (SDD 09 §2). La variante (b) — el toolchain construido por hammer desde fuente — reemplaza /toolchain Alpine pieza a pieza, con este mismo lazo verificando cada paso.

✅ Rebuild in-rootfs ejecutado (2026-06-11): 2/4 componentes sellados en la VM

Corrida real (QEMU TCG, -m 6144, sin KVM). El driver atravesó, en orden, una cadena de muros reales — cada uno destapado sólo por correr el rebuild dentro de la VM (justo lo que Stage 2 existe para cazar) y arreglado:

1. Toolchain incompleto. Traía compiladores (cargo/make/zig) pero no la orquestación del lab: bwrap (anida el sandbox), git (git archive del mirror), curl (tarballs). En el host las da el sistema; en la VM el toolchain es el único userland ⇒ apk add bubblewrap git curl.
2. Binarios dinámicos vs userland estático. El toolchain es Alpine dinámico; el Stage 1 es musl estático (sin loader en /lib) ⇒ no corrían. Fix: shim del loader (cp del ld-musl a /lib + LD_LIBRARY_PATH/PATH) en rebuild-stage1.
3. overlay es módulo. CONFIG_OVERLAY_FS=m y el initramfs arranca sin módulos ⇒ bwrap --tmp-overlay daba ENODEV. Fix: insmod /toolchain/lib/overlay.ko (+ kmod; overlay.ko del kernel destino inyectado en el builder).
4. Ownership del initramfs. El copy-up de overlay daba EACCES (Can't mkdir /opt/zig): los ficheros viajaban con uid 1000, sin mapear en el userns de bwrap (mapea 0→0). Fix: empaquetar con cpio --owner=root:root.

Con eso, musl y busybox se reconstruyeron y sellaron dentro de la VM con el toolchain de adentro (configure→compile→install→seal; ~35–38 min/componente bajo TCG). El mecanismo de auto-alojamiento queda probado sobre builds reales, no sólo en diseño.

Muro pendiente — deps Rust offline. hammerd abortó en cargo vendor (failed to sync): el /work embebido lleva los mirrors git de las fuentes (repos/) pero no las dependencias crates.io, y la VM no tiene red. Los componentes C sellan (tarballs autocontenidos); los Rust (hammerd, arje-zero) necesitan, para offline, o red en la VM (qemu -netdev user + NIC + /etc/resolv.conf, los repos privados ya están mirroreados) o las crates vendoreadas en /work. Sumado al coste de los builds Rust bajo TCG (horas, RAM justa ⇒ riesgo de OOM en arje-zero), el veredicto pleno 4/4 se completa en un host con KVM + más RAM (y, idealmente, un builder booteado desde disco en vez de initramfs puro, que además evita la fricción ramfs/ownership).

Rust-offline cruzado + un no-determinismo cazado: el CPU del builder (2026-06-11)

El muro Rust-offline cayó. Se dio red a la VM (NIC e1000 qemu user-mode + insmod e1000.ko + config estática de eth0 10.0.2.15 + DNS de slirp + CA bundle de Alpine copiado a la ruta estándar, commits 09034a5/fd20e38). Con eso cargo vendor resolvió crates.io entero (DNS+TLS), y hammerd se compiló, instaló y selló dentro de la VM (74 m 35 s bajo TCG). Para no pagar el vendoring del monorepo de arje-zero bajo TCG, esta corrida preseed-eó musl/busybox/arje-zero en el store del builder y dejó sólo hammerd para reconstruir in-VM (driver work/drive-rebuild.py).

Veredicto: ✗ DIVERGENTE — y es justo lo que Stage 2 existe para cazar. of_tree(stage1)=b3:94a4f1… (host) vs of_tree(stage1')=b3:ab615b… (VM). El seal hash del rootfs sí coincidió (b3:f11ca6e5…), pero el seal es of_inputs (recipe + (name,hash) de componentes): mismo key ≠ mismos bytes. Lo único reconstruido in-VM era hammerd, así que la divergencia está ahí.

Diagnóstico (experimento de control en el host, sin VM):

1. Rebuild de hammerd en el host → byte-idéntico al cacheado (cmp limpio, dos veces). La receta es determinista host-a-host; el cache no está stale.
2. ⇒ la divergencia es del entorno de build de la VM. La única entrada de codegen no fijada es el CPU del builder: zig cc (que compila el C/asm de los build-scripts: blake3, curve25519-dalek) default a -mcpu=native y hornea la ISA de quien compila.
3. Evidencia ISA: el hammerd del host trae sha256rnds2 (SHA-NI) ×32 y 3530 instrucciones AVX2 (ymm). El host tiene sha_ni+avx2; -cpu Broadwell (el de la VM bajo TCG) NO tiene SHA-NI ⇒ codegen distinto ⇒ bytes distintos ⇒ of_tree distinto. Es la misma raíz que el SIGILL de AVX del §7 (binarios al CPU del builder, no a un baseline).

Fix — -mcpu=baseline en TODOS los sitios zig cc (codegen al baseline x86-64 genérico, independiente del CPU): el CC/CXX del sandbox (sandbox.rs), los dos wrappers Cargo (.hammer-zig-cc, lib.rs) y los CC/HOSTCC de la receta de busybox. Las rutas SIMD que el runtime sí usa (blake3/sha2) son asm con dispatch en runtime: siguen presentes y funcionando. Bonus: cierra de paso el AVX/SIGILL del §7 (el binario corre en qemu64 sin -cpu Broadwell).

Validado en el host: con baseline, hammerd cambia de bytes (1 672 448 vs 1 677 584 — confirma que el default NO era baseline) y los 3 componentes rebuildan limpio (stage1 rc=0). Nueva referencia CPU-independiente: of_tree(stage1-baseline)=b3:4408e44e2ec51c3769deffcd64dd1f6c2010d414418937c3fa7930a0ded3f845 (con musl 57b66a2e+busybox 56664d70+arje bd0f8475+hammerd d08fd273, todos baseline salvo arje que quedó preseed nativo). Nota de fondo (plan C.2): el flag de CPU no entra hoy en of_inputs, así que un cambio de toolchain/flags da cache-hit con bytes viejos — la misma tensión "pin de toolchain al hash" que conviene cerrar para que Stage 2 no dependa de borrar el store a mano (por eso el refresh de abajo borró los artefactos viejos a mano antes de reconstruir).

Store refrescado a baseline 4/4 + builder listo (2026-06-11). Se reconstruyeron los 4 componentes con el toolchain baseline (incluido arje-zero, que re-vendorea el monorepo) en un store limpio, y se promovió a ./store (el nativo quedó en store-native-bak). arje-zero baseline difiere del nativo (char 25) ⇒ baseline aplicado. Referencia CPU-independiente full-4/4: of_tree(stage1)=b3:198f209f5e2c9d3a37411823b2ea42a09074d4e482f044278958b1b86f232dbb (rootfs key b3:2bd7c91b…; nótese que el key of_inputs es idéntico al del preseed-nativo — el cambio de bytes de arje no movió su key: la misma escotilla C.2). El builder se re-ensambló con ese toolchain + el hammer baseline + --ref-content 198f209f… (embebida en /etc/hammer/rebuild.env) y se repackó work/builder.cpio.gz (415 MB, 27 027 entradas, --owner=root:root). Listo para bootear: scripts/boot-builder-vm.sh (o scripts/drive-rebuild.py no-interactivo) → adentro rebuild-stage1 debe reproducir 198f209f… ⇒ ✓ REPRODUCIBLE cerraría el auto-alojamiento 4/4 bit a bit. Bajo TCG es lento y la RAM va justa; el veredicto pleno gana con KVM + más RAM (y boot desde disco).

No-determinismo #3 cazado — arje-zero y codegen-units (2026-06-12). El rebuild in-VM dio ✗ DIVERGENTE (of_tree host 984e002f… ≠ VM 94b93585…) pese a que los 4 componentes sellaban bajo el mismo key of_inputs. La caza (bisección por componente en el host): musl, busybox y hammerd reconstruyen byte-idéntico entre dos builds del host, y la ensambladura del rootfs (of_tree) es determinista e independiente del entorno. El culpable era arje-zero: dos builds del mismo host daban binarios distintos (Δ ~9.6 KB repartidos por .text −8064, .rodata −896, .eh_frame, .gcc_except_table, .data.rel.ro, .got) — la firma del codegen paralelo de rustc. Raíz: el workspace de hammer pinea [profile.release] codegen-units = 1 (por eso hammerd reproducía), pero el monorepo tawasuyu no declara perfil → cargo usa el default codegen-units = 16. Con 16 unidades el reparto del crate en N objetos varía build-a-build incluso con entradas idénticas, y la salida cambia. Fix: el sandbox impone CARGO_PROFILE_RELEASE_CODEGEN_UNITS=1 para todas las crates Cargo (crates/hammer-build/src/sandbox.rs) — el lab elimina el no-determinismo en vez de confiar en que cada repo upstream lo declare (SDD 09 §2). Verificado: dos builds cu=1 de arje-zero → byte-idénticos, y el of_tree(stage1) queda estable. Nueva referencia reproducible 4/4 (cu=1): of_tree(stage1)=b3:0039b2b90fddf62221ad5b804a34df93ef57dc533cb210512cf53752876afdff (reemplaza la 198f209f… de cu=16, que ya era no-reproducible). El store del host se refrescó a este baseline y EXPECT_REF en selfhost-verify.sh se actualizó.

✓ REPRODUCIBLE — verificado end-to-end in-VM (2026-06-12). KVM=1 MEM=24576 ./scripts/selfhost-verify.sh en el host libre (cachyos, /dev/kvm + swap 32G): la VM reconstruyó los 4/4 con el toolchain de adentro (arje-zero cu=1 compiló en 27m32s in-VM), selló el rootfs key 2bd7c91b… y su of_tree(stage1') = b3:0039b2b9… igualó la referencia ⇒ ✓ REPRODUCIBLE: stage1' == stage1 (auto-alojado bit a bit), DRIVER_RC=0. El auto-alojamiento bit-a-bit de Stage 1 queda cerrado y confirmado en el bucle completo (host↔VM), no sólo host↔host.

✓ REPRODUCIBLE con swaps de la variante (b) — verificado end-to-end in-VM (2026-06-13). KVM=1 MEM=24576 SWAP_MAKE=1 SWAP_BUSYBOX=1 ./scripts/selfhost-verify.sh en libre: el builder se ensambla pisando el /toolchain Alpine con el make (b3:fbad44ac…) y el busybox (b3:56664d70…) que hammer compiló desde fuente, y la VM reconstruye los 4/4 con ese toolchain hammerizado — incluido busybox compilándose a sí mismo con hammer-busybox de shell. Sellaron in-VM: musl 57b66a2e…, busybox 56664d70…, hammerd d08fd273…, arje-zero bd0f8475… (cu=1), y el of_tree(stage1') igualó la referencia 9adefb82… ⇒ ✓ REPRODUCIBLE: stage1' == stage1, DRIVER_RC=0 (RESULTADO: ✓ REPRODUCIBLE, elapsed 3261 s ≈ 54 min con arje-zero cu=1 in-VM). La procedencia del builder deja de ser "todo Alpine": make+busybox son ya de hammer, auditados, y el auto-alojamiento sigue siendo bit-a-bit. Siguiente pieza de la variante (b): linux-headers → bwrap → rust/llvm (cada una swapeada y re-verificada con este mismo comando).

Tarea reproducible end-to-end: scripts/selfhost-verify.sh. Un solo comando hace TODO el pipeline (stage0 → stage1 baseline → stage2 ref → inyectar overlay.ko/e1000.ko del kernel local → ensamblar builder → empaquetar → bootear + driver no-interactivo → veredicto), pensado para correr en una máquina con KVM + RAM holgada (laptop):

./scripts/bootstrap-devfs.sh          # una vez: el lab (.dev-fs/alpine + zig)
KVM=1 MEM=10240 ./scripts/selfhost-verify.sh
# PRESEED=hammerd → preseed C+arje y reconstruye sólo hammerd in-VM (barato si la RAM va justa)

Cross-check de reproducibilidad entre máquinas: el script compara su of_tree(stage1) contra EXPECT_REF (la referencia conocida-buena 0039b2b9… del host de dev, baseline cu=1). Si difieren, o cambió un pin (toolchain/recipes/seed) o hay un no-determinismo nuevo. En el host de dev (Artix, 7.6 GB, sin KVM) el rebuild 4/4 in-VM colgó por presión de RAM bajo TCG a los ~17 min del make de musl — el muro de hardware que esta tarea traslada a un host capaz.

9. Cross-check opcional — arje-packager

arje trae su propio empaquetador (03_ukupacha/arje/init/arje-packager): arje-packager --seed <CARD.json> --out <initramfs.cpio.gz> [--bin LABEL=PATH]…. Útil para comparar el initramfs canónico de arje contra el que sale del rootfs de hammer (§4). No reemplaza esta validación: aquí probamos el rootfs que hammer sella, no el que arje arma.