From d078e5285fa0194bbf2890db0fb1cf817bbd18ac Mon Sep 17 00:00:00 2001 From: Sergio Date: Mon, 14 Sep 2026 01:24:11 +0000 Subject: [PATCH] =?UTF-8?q?SDD=2030=20=C2=A74b.2:=20la=20cadena=20entera?= =?UTF-8?q?=20probada=20en=20un=20arranque=20real=20=E2=80=94=20PRODUCT=5F?= =?UTF-8?q?SSH=5FOK?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Los tests no eran el punto: el punto era que un servicio DECLARADO en una receta termine supervisado por PID 1. `product-boot-test.sh` sobre el product-rootfs de la ruta real da `ok card sshd en la seed` y `PRODUCT_SSH_OK uid=0`, sin ningún eslabón escrito a mano: recipes/openssh.toml [[service]] → sidecar dentro del artefacto sellado → service_cards() → genesis de /ente/seed.card.json → arje-zero encarna sshd → la sesión SSH responde. Y HABÍA QUE DESCARTAR QUE LO MOVIERA ESTE CAMBIO: el product-rootfs salió con hash distinto (5011955a… → 8639894332…). No fue la seed — las dos son BYTE-IDÉNTICAS (diff del JSON, cero diferencias). Cambiaron `netup`, que es otro artefacto que cuando se selló el viejo, y por arrastre `ente/attest.json`, que registra su BLAKE3. O sea: la constante y la receta producen la misma seed, comprobado sobre el árbol real y no sólo en un test. Y queda escrito por qué el ESCRITORIO no se puede arrancar supervisado todavía, que es corpus y no diseño: gnome-shell en deuda (bloqueado sólo por evolution-data-server, que tiene blocked_by vacío) y sway sin sellar. Sin compositor no hay sesión. NO se cablearon los scripts de imagen a ciegas: inyectar cards en un genesis que no se puede bootear es escribir código que nadie puede contradecir, y este mismo doc ya tiene el ejemplo de qué pasa entonces (el SDD 06 afirmando meses un lector que no existía). --- docs/30-servicios-de-paquete.md | 56 ++++++++++++++++++++++++++++++--- 1 file changed, 52 insertions(+), 4 deletions(-) diff --git a/docs/30-servicios-de-paquete.md b/docs/30-servicios-de-paquete.md index 49856c4c..811d2559 100644 --- a/docs/30-servicios-de-paquete.md +++ b/docs/30-servicios-de-paquete.md @@ -1,6 +1,7 @@ # SDD 30 — Los servicios que trae un paquete -> **Estado:** §3, §4a y §4b IMPLEMENTADOS (2026-09-12/13), §4c y §5 abiertos. Nace de una pregunta directa: +> **Estado:** §3, §4a y §4b IMPLEMENTADOS y **VALIDADOS EN ARRANQUE REAL** (2026-09-12/14); +> §4c cerrado para la imagen de producto y bloqueado para las de escritorio; §5 abierto. Nace de una pregunta directa: > *«los paquetes que tienen sus servicios para systemd, openrc u otros, ¿ya saben empaquetarse en > takana con arje?»*. La respuesta medida era **no**, y este documento dice exactamente qué faltaba, > qué se cerró y qué queda. @@ -182,6 +183,34 @@ Coste que conviene saber: los árboles ya hidratados compartían inodes con el a nuevo tiene inodes propios (`%h = 1`). El contenido es el mismo, pero hasta que esos árboles se refresquen el disco lleva dos copias. +### 4b.2 La cadena entera, probada en un arranque real + +No alcanza con que los tests pasen: el punto de todo esto es que **un servicio declarado en una +receta termine supervisado por PID 1**. Medido el 2026-09-14, `scripts/product-boot-test.sh` sobre +el `product-rootfs` ensamblado por la ruta real: + +``` + ok card sshd en la seed + ==> boot QEMU (mem 2048), hostfwd :2223->:22 + PRODUCT_SSH_OK uid=0 +``` + +La cadena completa, sin ningún eslabón escrito a mano: + + recipes/openssh.toml `[[service]]` + → sidecar `.hammer/recipe.toml` DENTRO del artefacto sellado + → `service_cards()` (scope = system) + → `genesis` de `/ente/seed.card.json` + → arje-zero encarna sshd al boot + → la sesión SSH responde + +**Y el hash no se movió por esto.** El `product-rootfs` salió con hash distinto al anterior +(`5011955a…` → `8639894332…`), y había que saber si lo movía este cambio: **no**. La seed de ambos +árboles es **byte-idéntica** (`diff` sobre el JSON: sin diferencias); lo que cambió fueron `netup` +—otro artefacto que cuando se selló el viejo— y, por arrastre, `ente/attest.json`, que registra su +BLAKE3. La constante y la receta producen exactamente la misma seed, comprobado sobre el árbol real +y no sólo en un test. + **(c) Los de GNOME: DECLARADOS, no todavía arrancados por arje.** Las nueve unidades que `gnome-start-qemu.sh` levanta con `&` están declaradas en sus recetas y habilitadas en el perfil (`dbus-system`, `logind-compat`, `polkit-compat`, `accounts-daemon`, `upowerd`, `colord` de sistema; @@ -200,8 +229,26 @@ Dos cosas que NO son transcripción y hay que saber: a PID 1 por `RunCard`), pero mutter y kwin no tienen esa integración. `--services` avisa por cada una: el hueco queda contado, no omitido. -Falta el paso final: que el ensamblado de la imagen ponga las cards de sistema en el `genesis` en vez -de que el script las lance con `&`. Eso ya es §4b (el emisor) y el arranque supervisado en QEMU. +#### Por qué el escritorio NO se puede arrancar supervisado todavía (medido) + +El paso final —que el ensamblado de la imagen ponga las cards de sistema en el `genesis` en vez de +que el script las lance con `&`— **no está bloqueado por diseño sino por corpus**, y conviene que +esté escrito para no volver a averiguarlo: + +| imagen | estado | qué falta | +|---|---|---| +| `escritorio-gnome` | 307/309 de la clausura sellada | **`gnome-shell` en deuda**, y su único bloqueante es `evolution-data-server` (que tiene `blocked_by: []` — o sea que sus deps ya están: falta construirlo, no destrabarlo) | +| `escritorio-sway` | 260/261 | **`sway` mismo sin sellar** | + +Sin el compositor/shell no hay sesión que arrancar, así que el arranque supervisado de escritorio no +es verificable hoy por más cards que se inyecten. Y el andamiaje de la imagen tampoco está: en este +hub `work/metal-rootfs` no existe y `work/gnome-rootfs` son 388 K de residuo, no el cierre hidratado. + +**Lo que NO se hizo a propósito:** cablear los scripts de imagen a ciegas. Inyectar cards en un +`genesis` que no se puede bootear es escribir código que nadie puede contradecir — y este documento +ya tiene un ejemplo de lo que pasa entonces (el SDD 06 afirmando durante meses un lector que no +existía). El mecanismo está probado donde SÍ se puede arrancar (§4b.2); el escritorio espera a que +su corpus cierre. ## 5. El hueco que no es nuestro: no hay readiness @@ -233,7 +280,8 @@ arriba en arje. | Los 9 de GNOME declarados y habilitados (hash sin mover, 9/9) | ✅ §4c | | Emisor desde el sidecar (`service_cards`, falla ruidosa + test) | ✅ §4b | | Re-sellado de openssh con control → **reproduce bit a bit** | ✅ §4b.1 | -| Que la imagen los arranque por arje y no por el script `&` | ◻ §4c, depende de §4b | +| La cadena receta→sidecar→card→genesis→arje, **en arranque real** | ✅ §4b.2 (`PRODUCT_SSH_OK`) | +| Que la imagen de ESCRITORIO los arranque y no el script `&` | ⛔ §4c, bloqueado (abajo) | | `escritorio-cosmic`: auditar su `cosmic-start.sh` y habilitar | ◻ hoy sale con 5 AVISO | **La primera lectura del vigía**, para que no haya que creerle a este documento: 0 errores y 18