From 731d4f6ffce221e99df99c60909098ee2e3759c7 Mon Sep 17 00:00:00 2001 From: Sergio Date: Thu, 11 Jun 2026 12:48:50 +0000 Subject: [PATCH] =?UTF-8?q?docs:=20SDD=2011=20=C2=A77=20=E2=80=94=20dise?= =?UTF-8?q?=C3=B1o=20del=20builder=20rootfs=20(camino=20a=20Stage=202=20pl?= =?UTF-8?q?eno)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit La verificación de Stage 2 (of_tree + verify_against) está probada y los 4 componentes reconstruyen bit-idéntico. El rebuild *dentro* del rootfs exige un builder rootfs: el Stage 1 mínimo es runtime, sin compilador. Diseña: qué necesita el builder (hammer estático + recetas + seed zig + make/ autotools + cargo/rust + linux-headers + bwrap para el sandbox anidado); dos niveles de pureza fasables — (a) pragmático (toolchain desde Alpine, demuestra el mecanismo + cierra la reproducibilidad end-to-end) y (b) auto-alojamiento puro (toolchain construido por hammer desde fuente, incremental); y el enganche con stage2 (ya ancla of_tree(stage1); el builder produce stage1'). Co-Authored-By: Claude Opus 4.8 (1M context) --- docs/11-bootstrap.md | 36 +++++++++++++++++++++++++++++++++++- 1 file changed, 35 insertions(+), 1 deletion(-) diff --git a/docs/11-bootstrap.md b/docs/11-bootstrap.md index 3b33a6bd..45a463c2 100644 --- a/docs/11-bootstrap.md +++ b/docs/11-bootstrap.md @@ -172,7 +172,41 @@ hammer bootstrap --all # las tres + reporte de reproducibilidad del roadmap. ☐ - **Kernel:** importado pinned ahora; from-source después. ☐ -## 7. Hecho cuando +## 7. Auto-alojamiento: el builder rootfs (camino a Stage 2 pleno) + +La verificación de reproducibilidad de Stage 2 ya está operativa y probada: `of_tree` (content-hash +de bytes) + `verify_against`, y los 4 componentes reconstruyen **bit-idéntico** (ver +[runbook §8/§8b](runbooks/stage1-vm-boot.md)). Lo que falta es el **rebuild *dentro* del rootfs +usando sólo sus herramientas** — y ahí aparece el obstáculo real: + +> El Stage 1 que booteamos es un **runtime** (musl+busybox+hammerd+arje-zero): **no trae compilador** +> (ni `zig`, ni `make`/autotools, ni `cargo`/rust, ni `linux-headers`, ni `bwrap`). No puede +> reconstruir nada. El rebuild in-rootfs exige un **builder rootfs**: Stage 1 + el toolchain adentro. + +### 7.1 Qué necesita el builder rootfs + +Para correr `hammer bootstrap stage1` **dentro** de sí mismo: el binario `hammer` (estático), las +recetas, la **semilla** (`zig`, ya un artefacto sellado), `make`+autotools, `cargo`+rust, +`linux-headers`, y `bwrap` (el lab anida un sandbox ⇒ userns sin privilegios dentro del chroot/VM). + +### 7.2 Dos niveles de pureza (fasable) + +- **(a) Builder pragmático** — el toolchain entra al rootfs **desde Alpine** (apk), no construido por + hammer. Demuestra el **mecanismo** (rebuild in-rootfs + `of_tree(stage1)==of_tree(stage1')`) y + cierra la reproducibilidad *end-to-end*, sin ser aún auto-alojamiento puro. +- **(b) Auto-alojamiento puro** — el toolchain lo **construye hammer desde fuente** (recetas para + make/autotools, y el gran tramo: rust/llvm o un rustc bootstrappeado). Es el end-state; el más + caro (construir rust desde cero). Se llega **incrementalmente**, reemplazando una a una las piezas + Alpine por componentes hammer, con Stage 2 verificando cada paso. + +### 7.3 Enganche con lo ya hecho + +`stage2` ya ancla `of_tree(stage1)`; el builder produce `stage1'` y `verify_against` emite el +veredicto. El determinismo necesario está cubierto (paths fijos `/src`, `SOURCE_DATE_EPOCH`, locks +deterministas). El sub-ítem es: **ensamblar el builder** (variante de `assemble_rootfs` que hidrata +el toolchain) y **correr el rebuild anidado** en la VM. + +## 8. Hecho cuando `hammer bootstrap --all` produce un rootfs que, ejecutado en la VM destino, **reconstruye su propio toolchain y userland con hashes idénticos a los publicados**, sin que ninguna