tawasuyu

sergio/takana

> Una distribución Linux construida con un laboratorio funcional y hermético en el > sótano, y una terminal mutable, clásica y anárquica en el piso de arriba — diseñada > desde el suelo para que una IA programadora entienda, modifique y co…

selfhost-verify: el work-cache se puede acotar — con el corpus entero no arranca

El verify relanzado pasó el punto donde moría antes y falló más adelante con
«RESULTADO: ? incompleto (timeout/boot/OOM)» y `DRIVER done sent=False
elapsed=2s`. La causa, medida:

    work/builder.cpio.gz: 15G     ← contra MEM=8192

Un initramfs se carga ENTERO en RAM, así que la VM muere a los dos segundos. Y
los 15 G no son el toolchain (1,2 G) ni el store (396 M): son el `--work-cache`,
que copia `repos/` y `tarballs/` — en el worker, 8,7 G de mirrors git y 6,3 G de
tarballs, o sea el corpus entero cacheado. El default `work` es correcto en una
laptop de dev y es inarrancable en una máquina que ya construyó todo.

Ahora `WORK_CACHE` es una variable (default `work`, sin cambio de comportamiento)
y el comentario trae la receta del caché mínimo: el rebuild in-VM sólo necesita
las fuentes del NÚCLEO — takana.git (hammerd) 15M, arje-zero.git 146M y los tres
tarballs de musl/busybox/util-linux, ~15M. Total ~176 M contra 15 G.

Lo que enseña este fallo es el mensaje: «? incompleto (timeout/boot/OOM)» suena a
cualquier cosa menos a «el initramfs no cabe en la RAM que le diste», y el dato
que lo delata —el tamaño del cpio— estaba impreso cuatro líneas más arriba.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

a11740e1cff181e0e53eeff229648c814bd16bea · by Sergio · (28 d ago) · parent 87a3969b1 · browse the tree at this commit

Semantic delta

No definition changed: this change is text, documentation or data.

1 files · +16 −1

diff --git a/scripts/selfhost-verify.sh b/scripts/selfhost-verify.sh
index c5d7e789..8497e4af 100755
--- a/scripts/selfhost-verify.sh
+++ b/scripts/selfhost-verify.sh
@@ -33,6 +33,21 @@ STORE="${STORE:-store}"
 KERNEL="${KERNEL:-/boot/vmlinuz-linux}"
 MEM="${MEM:-6144}"
 PRESEED="${PRESEED:-all}"
+# Caché de fetch que viaja DENTRO del builder (sólo `repos/` y `tarballs/`; ver el paso 7 de
+# `builder_rootfs`). Por defecto `work`, que es lo correcto en una laptop de dev.
+#
+# ⚠ **En una máquina que ya construyó el corpus entero, `work` son DECENAS DE GIGAS** y el builder
+# se vuelve inarrancable: el initramfs se carga ENTERO en RAM, así que 15 G de mirrors y tarballs
+# contra `MEM=8192` matan la VM a los dos segundos y el script reporta «? incompleto
+# (timeout/boot/OOM)», que suena a cualquier cosa menos a lo que es. Medido en el worker el
+# 2026-09-24: `work/repos` 8,7 G + `work/tarballs` 6,3 G ⇒ `builder.cpio.gz` de 15 G.
+#
+# El rebuild in-VM sólo necesita las fuentes del NÚCLEO. Un caché mínimo son ~176 M:
+#     mkdir -p /tmp/wc/{repos,tarballs}
+#     cp -al work/repos/{takana,arje-zero}.git /tmp/wc/repos/     # hammerd · arje-zero
+#     cp -al work/tarballs/<sha de musl,busybox,util-linux>.tar /tmp/wc/tarballs/
+#     WORK_CACHE=/tmp/wc ./scripts/selfhost-verify.sh
+WORK_CACHE="${WORK_CACHE:-work}"
 SEED_VERSION="${SEED_VERSION:-0.16.0}"
 STAGE0_URL="${STAGE0_URL:-https://ziglang.org/download/0.16.0/zig-x86_64-linux-0.16.0.tar.xz}"
 STAGE0_SHA256="${STAGE0_SHA256:-70e49664a74374b48b51e6f3fdfbf437f6395d42509050588bd49abe52ba3d00}"
@@ -247,7 +262,7 @@ say "ensamblar builder (toolchain in-rootfs + hammer baseline + ref${SWAP_ARGS:+
     --toolchain "$TOOLCHAIN" --toolchain-tag "$TOOLCHAIN_TAG" \
     --ref-content "$REF" \
     "${SWAP_ARGS[@]}" \
-    --work-cache work --out work/builder-rootfs
+    --work-cache "$WORK_CACHE" --out work/builder-rootfs
 
 # 4b) Preseed opcional para abaratar el rebuild in-VM (sólo hammerd se reconstruye).
 if [[ "$PRESEED" == "hammerd" ]]; then