From be368df07055c27d7fba652ef9f68f608d661d22 Mon Sep 17 00:00:00 2001 From: Sergio Date: Thu, 10 Sep 2026 23:04:23 +0000 Subject: [PATCH] =?UTF-8?q?SDD=2028=20=C2=A76.3-6.4:=20puerta=202=20en=20v?= =?UTF-8?q?erde,=20el=20disco=20arreglado,=20y=20la=20puerta=203=20choca?= =?UTF-8?q?=20con=20un=20muro=20estructural?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit **Puerta 2 ✅**: 1362 artefactos reales, 0 vacíos. (El primer conteo dio «3 vacíos» y eran `.mirror-tmp`, `.bootstrap-tmp` y `.divergen` — directorios de trabajo, no artefactos: el chequeo tiene que acotar por el patrón `-`, no listar el directorio.) **El disco**: la imagen ocupaba 7 G de 76,3 y los otros 69 eran inalcanzables. Arreglado; `/store` en la caja pasó de 487 M a **68,7 G**. Con eso el store de 55 G entra en disco local y **la mudanza ya no depende de desenganchar el volumen de gioser** — que era la parte que paraba la granja. **Puerta 3 🚧 BLOQUEADA, y no por configuración.** Al ir a computar los grafos: $ python3 -c "print(1)" sh: python3: not found <- y `command -v python3` decía /usr/bin/python3 Está y no arranca: es un ELF DINÁMICO que pide `/lib/ld-musl-x86_64.so.1`, y **en la imagen no hay ningún cargador dinámico**. Tampoco en el store: el artefacto `musl` publica sólo lo estático (`libc.a`, `crt*.o`, headers) — no hay `libc.so` ni `ld-musl` en NINGÚN artefacto del corpus. Lo que hace que esto funcione en gioser es el rootfs Alpine del LAB. Contado sobre la imagen: **23 binarios inertes de 726**. La suite binutils entera, más perl, python3, sqlite3, flex y nft. Frena la mudanza porque TODO el instrumental del proyecto es Python (build-state, targets, yupana, hydrate-profile, drenar, triaje): un servidor takana no puede correr ni una de sus herramientas. Las tres salidas —publicar el cargador desde musl (toca Stage 1 y mueve el baseline del selfhost), python/perl estáticos (frente propio), o aceptar que el instrumental vive en el hub (contradice apagar gioser)— son decisión de ADR. Queda escrito, medido, y sin tocar nada de Stage 1 de rebote. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_01RomoxEGZUhaT4pob1QSX5x --- docs/28-servidor-de-produccion.md | 71 +++++++++++++++++++++++++++++++ 1 file changed, 71 insertions(+) diff --git a/docs/28-servidor-de-produccion.md b/docs/28-servidor-de-produccion.md index 56956bba..3c211bbd 100644 --- a/docs/28-servidor-de-produccion.md +++ b/docs/28-servidor-de-produccion.md @@ -511,6 +511,77 @@ caja nueva y que el dato se verifica por contenido.** 751 sobre el MISMO corpus) y por eso se sacó del JSON. Si los grafos difieren, mirar primero si la diferencia es «cuánto de esto tengo en disco» y no «qué existe». +### 6.3 Estado de las puertas *(2026-09-10)* + +| # | puerta | estado | +|---|---|---| +| 1 | arranca takana puro y se entra por SSH | ✅ §3.8 | +| 2 | el store está entero | ✅ **1362 artefactos reales, 0 vacíos** | +| 3 | los cuatro grafos idénticos | 🚧 **bloqueada** — ver §6.4 | +| 4 | la granja late en la caja nueva | 🚧 bloqueada por lo mismo | +| 5 | el repo se sirve y el host se actualiza de sí mismo | ⬖ mitad: sirve (§5.1), no consume (§5.4) | +| 6–8 | dominios vivos · respaldo · fósiles decididos | pendientes | + +**Puerta 2, medida acotando al patrón `-`**: 1362 artefactos, **0 vacíos**. Los 3 sin +`.hammer/recipe.toml` son `stage1-rootfs`, `product-rootfs` y `seed-zig` — productos de bootstrap, +que por diseño no salen de una receta. (El primer conteo dio «3 vacíos» y eran `.mirror-tmp`, +`.bootstrap-tmp` y `.divergen`: directorios de trabajo con punto inicial, no artefactos. El chequeo +tiene que acotar por el patrón, no listar el directorio.) + +**De paso, el disco**: la imagen ocupaba 7 G de los 76,3 G de la caja y los otros 69 eran +inalcanzables. Arreglado en `install-image.sh` — el store pasa a ser la ÚLTIMA partición (la única +que puede crecer sin mover datos) y el wrapper de `/sbin/init` la extiende en el primer arranque. +Medido en la caja: **`/store` = 68,7 G**, contra los 487 M de antes. Con eso el store de 55 G entra +en el disco local y **la mudanza no depende de mover el volumen de gioser**. + +### 6.4 ⚠ El muro de la puerta 3: la imagen trae 23 binarios que NO PUEDEN CORRER + +Al ir a computar los grafos en la caja: + +``` +$ python3 -c "print(1)" +sh: python3: not found ← y `command -v python3` decía /usr/bin/python3 +``` + +No es que falte: **está y no arranca**. `/usr/bin/python3.12` son 23 MB y es un ELF **dinámico**: + +``` +Requesting program interpreter: /lib/ld-musl-x86_64.so.1 +NEEDED libc.so +``` + +**Y en toda la imagen no hay ningún cargador dinámico.** Tampoco en el store: el artefacto `musl` +publica sólo lo estático (`libc.a`, `crt*.o`, headers) — **no hay `libc.so` ni +`ld-musl-x86_64.so.1` en ningún artefacto del corpus**. Lo que hace que estos binarios funcionen en +gioser es el **rootfs Alpine del LAB**, que sí lo trae (`.dev-fs/alpine/lib/ld-musl-x86_64.so.1`). + +Es la fuga de [[needed-colgante-libstdcxx]] otra vez, y esta vez en el piso de abajo: *sella, +reproduce y no corre*, porque pide algo que sólo existe en el laboratorio. + +**Contado sobre la imagen: 23 binarios inertes de 726 (703 estáticos están bien).** Son la suite +`binutils` entera (`ar as ld nm objcopy objdump ranlib readelf strip addr2line c++filt elfedit gprof +size ld.bfd`), más **`perl`**, **`python3`**, **`sqlite3`**, **`flex`** y **`nft`**. + +**Por qué frena la mudanza y no es un detalle**: *todo* el instrumental del proyecto es Python — +`build-state.py`, `targets.py`, `yupana.py`, `hydrate-profile.py`, `drenar.py`, `triaje.py`. Un +servidor takana no puede correr ni una de sus propias herramientas. La puerta 3 (los cuatro grafos) +y la 4 (la granja) dependen de eso. + +**Y no se arregla de paso.** Las salidas son tres y ninguna es barata: + +1. **Publicar el cargador** — que `musl` emita `libc.so` + `ld-musl-x86_64.so.1`. Es lo correcto y lo + más chico en concepto, pero toca un componente de **Stage 1**: mueve el baseline `of_tree` del + selfhost y hay que rehacerlo a propósito, no de rebote. +2. **Construir python/perl estáticos** — el camino que evita el cargador, y es un frente propio: + Python estático con módulos de extensión es notoriamente arisco. +3. **Aceptar que el instrumental vive en el HUB** y que el servidor sólo sirve. Es la respuesta + honesta a corto plazo, pero contradice «mover allá todo lo que tengo acá»: el hub seguiría siendo + gioser, que es justo lo que se quiere apagar. + +Es decisión de ADR, y de las que conviene tomar mirando también el [SDD 27 §4](27-perfiles-instalables-y-el-instalador.md): +las dos preguntas —«¿el cliente reproduce o hidrata?» y «¿el cliente puede correr lo que le +mandamos?»— son la misma pregunta sobre qué es un sistema takana **sin laboratorio**. + ### 6.2 Lo que la mudanza tiene que producir, además de la mudanza El usuario lo pidió explícito: **que este experimento saque recetas y las pruebe**. La caja vieja es