sergio/takana

El baseline nuevo (b3:d152f060) está anclado y comprobado: hub y worker calculan
el mismo of_tree del stage1 de 5 componentes. Eso es el cruce entre MÁQUINAS.

El auto-alojamiento —que la VM reconstruya ese árbol con su toolchain— sigue sin
verificarse, y queda escrito dónde se atasca y qué se arregló para llegar ahí:

  1. el script moría EN SILENCIO sin /lib/modules (set -e + find sobre directorio
     inexistente aborta antes del echo del else). ARREGLADO.
  2. el initramfs pesaba 15 G contra MEM=8192 porque el --work-cache lleva el
     corpus entero cacheado. ARREGLADO: WORK_CACHE es variable y el caché mínimo
     del núcleo son 174 M.
  3. ABIERTO: la VM arranca y el primer build muere en «bwrap: pivot_root:
     Invalid argument», con 0 sellados. No es falta de capacidades —USER_NS,
     NAMESPACES, OVERLAY_FS, TMPFS, DEVTMPFS y BLK_DEV_INITRD están en y— ni el
     ENODEV de overlay-como-módulo que el runbook documenta. La diferencia con la
     corrida que funcionó es el KERNEL: el runbook valida con /boot/vmlinuz-linux
     de una laptop Arch y acá se usó nuestro linux 6.16.12, porque el worker es un
     LXC sin kernel propio.

Lo que falta es una máquina con RAM suficiente Y kernel de distro: el worker tiene
los 16 G pero no kernel; el hub y gioser tienen kernel pero ~7 G y la VM pide 8.

⚠ Este mensaje se rehízo con --amend: el primero se escribió con `git commit -m`
entre comillas DOBLES y el texto traía backticks, así que bash EJECUTÓ lo que
había dentro («bwrap: command not found») y el mensaje quedó con un hueco donde
debía ir el error. Es la misma forma que el heredoc sin comillas que ya documenta
CLAUDE.md; con -F - y el delimitador entre comillas simples no pasa.

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

diff --git a/docs/plan-botar-busybox.md b/docs/plan-botar-busybox.md
index 5d5af069..580c4f05 100644
--- a/docs/plan-botar-busybox.md
+++ b/docs/plan-botar-busybox.md
@@ -1806,3 +1806,62 @@ lo provee OTRO paquete (el `destino` está mal):  0
 **De los 23 applets de «trabajo real» quedan 3**, y dos de ellos son una decisión de arquitectura ya
 escrita. No se cerró la brecha escribiendo userland: se cerró **midiendo** lo que ya existía, que es
 la misma lección con la que empezó este documento.
+
+## Re-verificar el self-host tras meter `util-linux`: hasta dónde se llegó (2026-09-24)
+
+El `of_tree` del stage1 cambió al pasar el núcleo de 4 a 5 componentes, así que el baseline había que
+re-anclarlo. **Eso está hecho y medido**:
+
+```
+of_tree(stage1)   b3:9adefb82…  →  b3:d152f060…      (anclado en scripts/selfhost-verify.sh)
+```
+
+⚠ **Pero eso es el cruce entre MÁQUINAS, no el auto-alojamiento.** Que la VM reconstruya ese mismo
+árbol con el toolchain de adentro **sigue sin verificarse**, y conviene decir exactamente dónde se
+atascó porque el camino destapó tres cosas, dos de ellas arregladas.
+
+### 1 · El script moría en silencio en cualquier máquina sin `/lib/modules` — ARREGLADO
+
+`set -euo pipefail` + `find` sobre un directorio inexistente: el `find` falla, con `pipefail` el pipe
+falla, la asignación falla y `set -e` aborta **antes** del `echo "NO encontrado"` que el propio bucle
+tenía preparado. El `2>/dev/null` remata el silencio. Pasa en el worker porque es un **LXC**: comparte
+el kernel del host y no trae árbol de módulos. El log terminaba en la línea del `say`, sin una
+palabra, y el proceso llevaba **dos días muerto** mientras yo lo daba por vivo — porque
+`pgrep -f selfhost-verify` **se encuentra a sí mismo**.
+
+### 2 · El initramfs pesaba 15 G y no cabía en la RAM de la VM — ARREGLADO
+
+```
+work/builder.cpio.gz: 15G        ← contra MEM=8192   ⇒   DRIVER done sent=False elapsed=2s
+```
+
+Un initramfs se carga entero en RAM. Los 15 G no eran el toolchain (1,2 G) ni el store (396 M): era
+el `--work-cache`, que lleva `repos/` y `tarballs/` — en una máquina que ya construyó el corpus, eso
+son **8,7 G de mirrors git + 6,3 G de tarballs**. Ahora `WORK_CACHE` es variable y el caché mínimo
+del núcleo son **174 M**: `takana.git`, `arje-zero.git` y los tres tarballs de musl/busybox/util-linux.
+El mensaje del script —«? incompleto (timeout/boot/OOM)»— no ayudaba: el dato que lo delataba estaba
+impreso cuatro líneas más arriba.
+
+### 3 · El muro actual: `bwrap: pivot_root: Invalid argument` — ABIERTO
+
+Con las dos cosas arregladas, **la VM arranca** (hay prompt y el driver corre) y falla el PRIMER
+build de dentro, con **0 sellados**:
+
+```
+bwrap: pivot_root: Invalid argument
+Error: core: build phase falló (exit 1): ./configure …
+```
+
+No es falta de capacidades del kernel — se comprobó en el `.config` sellado: `USER_NS`,
+`NAMESPACES`, `OVERLAY_FS`, `TMPFS`, `DEVTMPFS` y `BLK_DEV_INITRD` están **todos en `y`**. Y no es el
+`ENODEV` de overlay-como-módulo que el runbook documenta (§ «overlay es módulo»), que es otro error.
+
+**La diferencia con la corrida que sí funcionó es el KERNEL.** El runbook valida este flujo con
+`/boot/vmlinuz-linux` —el de una laptop Arch— y ahí musl y busybox se reconstruyeron y sellaron
+dentro de la VM. Acá se le pasó **nuestro** `linux` 6.16.12, porque el worker es un contenedor y no
+tiene kernel propio que ofrecer.
+
+⇒ Lo que falta para cerrar la re-verificación es **una máquina con RAM suficiente y un kernel de
+distro**: el worker tiene los 16 G pero es un LXC sin kernel propio; el hub y gioser tienen kernel
+pero ~7 G, y la VM sola pide 8. Mientras tanto, lo que está verificado es el cruce entre máquinas
+(el mismo `of_tree` calculado en hub y worker), no el rebuild de adentro.