Decía «copiar es gratis de verdad, no casi». La regla honesta es: gratis SÓLO si
toda la clausura transitiva resuelve a lo mismo. Se cumple con libdisplay-info,
hwdata y nasm; no con pipewire.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
El compositor compiló a la primera en 51m39s (JOBS=1 + lto fat), sin un solo
parche a la fuente; lo único que hubo que corregir fue el --bin del gotcha 1.
Lo que vale es el enlace, porque es medición y no impresión: ocho NEEDED, y las
siete primeras son EXACTAMENTE los backends de smithay que la receta declara
(display-info, gbm, seat, udev, input, pixman, xkbcommon). La octava es musl.
No hay libgcc_s —el compositor no arrastra la deuda del unwinder— y no aparece
nada sin declarar: la clausura de build y la de runtime coinciden.
Un compositor Wayland completo (DRM/GBM/EGL/libinput/seat/Vulkan/XWayland,
renderer multi-GPU y UI en iced) cerrando con ocho librerías compartidas y cero
parches es el resultado más limpio de las cuatro campañas de escritorio.
Queda anotado además por qué cosmic-settings-daemon NO se resuelve copiando
pipewire: copiar entre colas es gratis sólo si TODA la clausura transitiva
resuelve igual, y ahí glib resolvería distinto (sombra de GNOME b3:f6ccdf98 vs
corpus b3:93d2cad0) ⇒ un segundo pipewire contra otra glib, que es el cuadro de
dos registros de GType que la campaña GNOME ya midió y evitó. Medido con yupana
radio antes de tocar nada.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
cosmic-idle se escribió sin [deps] con un argumento que parecía sólido: no usa
smithay-client-toolkit (el que hizo caer a cosmic-bg) y un demonio de inactividad
no interpreta teclas. Reventó igual, pero en el ENLACE y no en un build.rs:
-lxkbcommon lo arrastra cosmic-settings-config, de donde sale la tabla de atajos
y que usa TODO componente de la suite. La dep no viene de lo que el paquete hace
sino de la librería de configuración común.
Dos veces el mismo error de método con dos razonamientos distintos, y las dos
veces el mensaje decía exactamente quién y por qué. Queda en el runbook como
regla, no como anécdota.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
cosmic-bg se escribió sin [deps] con ese argumento y reventó en el build.rs de
smithay-client-toolkit pidiendo xkbcommon.pc. El que dlopea xkbcommon es winit,
que es otra capa. Hablar el protocolo en Rust dice cómo viaja el byte, no con
qué se interpreta un teclado. El link=static sigue siendo verdad: el artefacto de
libxkbcommon trae .a además de .so.
Corolario anotado en el runbook: todo cliente de la suite va a necesitar al menos
libxkbcommon + pkgconf.
Entran además cosmic-idle (cliente Wayland puro, SIN deps a propósito: no usa
sctk y no necesita interpretar teclas) y cosmic-osd, que es el primer cliente de
iced/libcosmic y por eso vale como sonda: panel, launcher, app-library,
workspaces y notifications comparten su mismo sustrato exacto.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Deja asentado por qué COSMIC no se parece a KDE ni a GNOME (no hay torre de C
debajo: la primera receta salió estática y con cero NEEDED), la tabla de lo que
se hereda gratis de mirada/GNOME, el pin en lockstep epoch-1.5.0, y los seis
gotchas medidos — entre ellos que start-cosmic es bash de verdad (mapfile, [[ ]],
${!var}) y que bash no lo pide ningún [deps], así que a la imagen no lo trae
nadie por accidente.
Y el porqué del orden de ataque, que NO es el orden de arranque: cosmic-bg antes
del panel para que «pinta el fondo pero no el panel» separe la capa de UI del
transporte.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
El plan seguía sin tilde aunque el shell arranca justamente porque están: se
verificó uno por uno con `hammer hash` contra el store en vez de fiarse del
recuerdo. Se deja el texto original del plan por la advertencia de libelogind,
que sigue vigente.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
accounts-daemon y upowerd morían al arrancar: el shim de polkit se lanza en
background y tarda ~2s en adquirir org.freedesktop.PolicyKit1, ellos llamaban a
polkit_authority_get_sync() en ese hueco, D-Bus intentaba ACTIVAR el servicio y
fallaba con 'Failed to execute program ... Permission denied'.
Lo peor era el informe: los tres esperar_nombre estaban al final, así que para
cuando corrían el shim ya tenía el nombre y el resumen daba 'PolicyKit1 OK'
sobre dos clientes ya muertos. Un chequeo posterior a la carrera no la mide.
esperar_nombre pasa a definirse antes del primer daemon y el bloque de polkit
espera su propio nombre antes de que arranque ningún cliente suyo. Lanzar en
orden no es estar listo en orden.
De paso queda cerrado el ítem 4 del runbook: validación CON PANTALLA (DISP=gtk)
del Overview con el PID1 sellado nuevo — 689 colores distintos, con evidencia.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Audio
├─ Devices: 48. HDA Intel [alsa]
├─ Sinks: * 52. HDA Intel Analog Stereo [vol: 0.40]
├─ Sources: * 53. HDA Intel Analog Stereo [vol: 1.00]
Y gvc con perfiles reales (`output:analog-stereo+input:analog-stereo`). Se fue el auto_null.
LA CAUSA: SPA pide el device `card` (alsa-udev.c:178-183), que no tiene major:minor, y
libudev-zero recorría SÓLO /sys/dev/{block,char} — sólo devices CON nodo. El device que
SPA necesita nunca entraba en la enumeración: no faltaba una propiedad, faltaba la mitad
del espacio de búsqueda.
**Y LA PRIMERA VERSIÓN DEL PARCHE ARREGLÓ EL AUDIO Y ROMPIÓ EL VÍDEO.** Recorría
/sys/class entero, y /sys/class/drm no trae sólo tarjetas: trae los CONECTORES
(card0-Virtual-1) y un fichero `version`, ninguno con nodo. Mutter los tomaba como
candidatos ⇒ `No available CRTC for monitor` + `Page flip failed: drmModeAtomicCommit:
Invalid argument` en bucle. Pantalla negra con el compositor vivo: el mismo síntoma de
antes por una causa nueva. El udev real también los enumera, pero les adjunta las
propiedades por las que mutter los descarta, y ésas libudev-zero no las sintetiza.
La lección, que vale para cualquier reimplementación parcial de una API: **ensanchar la
enumeración expone los huecos de PROPIEDADES a más consumidores. Los dos lados del
contrato tienen que crecer juntos.** El parche final lleva una LISTA ACOTADA de
subsistemas (`sound` hoy); agregar otro es una línea *y* una prueba de que el consumidor
lo necesita y no se rompe.
POR QUÉ NO eudev — y corrijo mi propia sugerencia de antes, que era la peor opción: el
repo ya lo había probado en otro frente y ROMPIÓ EL INPUT. Su libudev.so.1 pisa el de
libudev-zero y, sin udevd, no expone ID_INPUT ⇒ libinput ignora todos los dispositivos en
silencio. Verificación A/B en QEMU de aquel episodio: eudev = 0 «New device»,
libudev-zero = 5. eudev sin udevd es PEOR, y correr udevd contradice la arquitectura
(arje-zero es PID1). El arreglo va donde está el hueco.
Radio pagado: 51 sellados a deuda, 9 en el cierre GNOME (reconstruidos: libinput,
libgudev, colord, mutter, gnome-shell, libgdm, upower, pipewire, wireplumber). El resto
—base, cli, KDE— queda para el latido.
Captura actualizada: escritorio pintando (628 colores) Y audio, cero page-flip fallidos.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Cierra el gestor de sesión de PipeWire, que es lo que separa «PipeWire acepta clientes»
de «PipeWire tiene dispositivos». Su política está escrita en Lua, así que arrastró una
receta de Lua que hubo que autorar entera.
LO QUE LA RECETA DE LUA TIENE QUE INVENTAR: el Makefile de upstream sólo produce
liblua.a y los binarios — **no hay regla de .so ni fichero pkg-config**, los agrega cada
distro. Acá la compartida se enlaza a mano desde la .a con --whole-archive (una estática
sólo aporta lo referenciado y hay que llevarse todo) y el .pc se escribe con los TRES
nombres que se usan por ahí, porque wireplumber prueba lua-5.4, lua5.4 y lua54 en orden.
`-fPIC` no es opcional: libwplua es un objeto compartido.
Dos símbolos más en libelogind (tawasuyu 087230054 → re-pineado 749edfe41):
sd_uid_get_seats y sd_uid_get_state, que module-logind.c de wireplumber usa para saber si
el usuario está en un asiento antes de tomar los dispositivos. Van 28 símbolos sd-*.
**EL `Devices:` VACÍO DE wpctl NO ES UN FALLO DE wireplumber: el kernel no tiene ALSA.**
recipes/linux-metal.toml:111 lo apaga explícito (`-d SOUND -d SND`), así que no hay
/dev/snd que enumerar. Y esto NO se dio por supuesto: se agregó una ich9-intel-hda
emulada a QEMU (AUDIO=1, ahora el default de run-qemu-desktop.sh) justo porque un
«Devices: vacío» se lee IGUAL si wireplumber funciona sobre una VM sin hardware que si no
funciona. Con tarjeta y sin ALSA en el kernel, el resultado no cambia — la ambigüedad
queda resuelta. Encender el sonido en la distro es una decisión con costo (re-sellar el
kernel, rehacer la imagen metal) y queda a la vista en vez de escondida en un default.
Bug propio destapado en el camino: el bloque de wireplumber quedó DUPLICADO en
gnome-start y había DOS wireplumber peleándose el grafo. El síntoma no era un error sino
una lista de clientes que se lee normal si no se cuenta: dos «WirePlumber» con pids
distintos en wpctl status.
Y una nota de ADR 0012 que costó un rato: la cascada de libelogind cortó a mitad y dejó
el `output/` de mutter a medio hacer; el reintento moría con «error opening
'...c.o.d': No such file or directory». Un `rm -rf output` en el configure NO alcanzó
—el árbol tenía estado viejo más allá del build dir—; lo que lo arregló fue BORRAR
work/sources/mutter-* para que el fetch lo re-extraiga limpio.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Cierra una pregunta que estaba explícitamente abierta en varias recetas, y que es la
razón por la que `pulseaudio` se había construido con `-Ddaemon=false`: sólo el cliente,
para que gvc hablara el protocolo sin cerrar la decisión de prestado.
**Los dos conviven y por eso la decisión no rompe nada**: pipewire va con
`-Dlibpulse=enabled` ⇒ `pipewire-pulse`, un servidor que habla el protocolo de
PulseAudio. gnome-shell usa libpulse sin enterarse de qué hay del otro lado. No hubo que
tocar una línea del cliente.
== gnome-qemu :: socket pipewire-0 OK
== gnome-qemu :: socket pulse/native OK — gvc va a poder conectar
Gvc-DEBUG: Updating client: index=32 name='pipewire'
Gvc-DEBUG: Updating sink: index=33 name='auto_null' description='Dummy Output'
El `Failed to connect context: Connection refused` desapareció. El sink es auto_null, que
es la respuesta honesta: la VM no tiene tarjeta de sonido.
**⚠ Falta wireplumber** (gestor de sesión, Lua + su cierre). Sin él PipeWire acepta
clientes pero NO enumera ni enruta dispositivos. «El shell conecta» ≠ «hay sonido», y el
log de arriba es justo el caso donde confundirlos sería fácil. Queda escrito en la receta
y en el runbook.
GOTCHA MEDIDO: ya existía incoming-kde/pipewire.toml sellada y NO se puede reusar
hidratándola acá — los dos cierres traen glib y **no son la misma glib**:
incoming-kde/glib-shared y incoming-gnome/glib producen libglib-2.0.so.0.8800.1 con bytes
distintos (verificado con cmp) y comparten 370 rutas. Proyectar las dos deja que una gane
por orden de proyección ⇒ dos registros de GType en un proceso, el cuadro que costó el
episodio de colord. De ahí la copia en la cola GNOME (glib-shared→glib, dbus→dbus-shared,
pcre2-shared→pcre2), que sí re-construye. Lo que FUE gratis: alsa-lib, cuya única dep es
pkgconf y resuelve al catálogo PADRE ⇒ hash idéntico y cache hit (b3:93cae411).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
bus: org.freedesktop.login1 OK
bus: org.freedesktop.PolicyKit1 OK
bus: org.freedesktop.Accounts OK
bus: org.freedesktop.UPower OK
accounts-daemon y upowerd arrancaban, seguían vivos, y NUNCA adquirían su nombre: los
dos se bloquean en `polkit_authority_get_sync()` al iniciar, y `org.freedesktop.PolicyKit1`
no lo servía nadie —nuestra receta polkit es libs-only a propósito, porque el demonio lo
pone arje—. gnome-shell esperaba después 25s por cada uno.
**El dato que lo resolvió no salió del log de los daemons sino de la LISTA DE NOMBRES DEL
BUS**: ahí estaban como conexiones anónimas `:1.0`, `:1.1`, sin nombre bien conocido. Eso
distingue tres cosas que en el log del cliente se ven igual — «no arrancó», «arrancó y no
llegó a pedir el nombre» y «lo pidió y se lo negaron». Era la segunda. `gnome-start` ahora
espera cada nombre con NameHasOwner y, si no aparece, vuelca el log del daemon y la lista.
Receta nueva `arje-polkit-compat` (b3:03e0a86f), tercer shim de este tipo tras
arje-logind-compat y arje-sdlogin-compat. Su propio autor ya había escrito el diagnóstico
en el crate: «apps que usan polkit bloquean en CheckAuthorization si no responde nadie».
⚠ AUTORIZA TODO — es la postura de sistema confiado que arje ya tenía tomada, no algo que
esta receta introduzca; queda explícito en su comentario.
Dos gotchas del empaquetado:
- **La política de polkit ya existe y NO alcanza**: permite `own` sólo al usuario polkitd
y el shim corre como root. Se agrega un `zz-arje-polkit-compat.conf` en vez de reescribir
la de upstream — dbus lee system.d en orden alfabético y las posteriores ganan.
- **Los ficheros del rootfs fundido son hardlinks de SÓLO LECTURA del store** (0444). Un
`cat >` encima falla con Permission denied y rompió un build. Regla: nunca sobrescribir
un fichero que venga de un artefacto; agregar al lado.
Queda escrito en el runbook lo que sigue faltando (colord, y que el shell no tiene servidor
de sonido porque pulseaudio se construyó sólo-cliente: el demonio de audio de la distro
sigue sin decidirse) y las dos lecciones de método que costaron una iteración cada una.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Captura actualizada: ahora se ve el puntero (Adwaita) y el icono de la notificación.
Colores distintos 582 → 629.
El setuid del dbus-daemon-launch-helper explicaba DOS cosas, no una: el «permission of
the setuid helper is not correct» de colord y, por la misma vía, que ninguna activación
por bus de sistema funcionara. Con el arreglo, colord pasó de «permiso incorrecto» a
«timed out» — la activación ya se intenta y lo que queda es del demonio.
Queda UPower: upowerd arranca y sigue vivo, pero no adquiere su nombre en el bus (su
política D-Bus está verificada y permite own a root), así que el shell espera sus 25s.
Es el indicador de batería en una VM sin batería.
Y queda escrita la lección que costó una iteración: **un pid no es un servicio**.
Reportar «lanzado» sin comprobar que el daemon adquirió su nombre es reportar una
intención, no un hecho.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
docs/evidencia/gnome-shell-qemu-2026-07-29.png: el conmutador de espacios de trabajo,
el reloj en el panel, la miniatura del escritorio, el dash, y la notificación estándar
de GNOME por sesión de root. Todo construido desde fuente sobre el kernel de hammer,
arje-zero como PID1 y musl.
**EL MURO NO ERA DE KMS.** El diagnóstico anterior culpaba al plano primario de
virtio-gpu («no advertised formats», sólo `Queue mode set`, ningún page flip). Era
correlación. Se probó quitando MUTTER_DEBUG_FORCE_KMS_MODE=simple —el log pasó a decir
`using atomic mode setting`, o sea que el cambio SÍ tomó efecto— y la pantalla siguió
con exactamente 2 colores. Refutada. Mutter no tenía un frame que presentar; no es que
no supiera presentarlo.
La causa estaba en el stack trace, en el log, desde el principio: la excepción por el
gschema `org.gnome.settings-daemon.peripherals.touchscreen` ocurre DENTRO de
`Main.start()`, construyendo los quick settings ⇒ el panel nunca se arma. Proceso vivo,
compositor con DRM master, nada que pintar.
Receta `gsd-schemas`: los gschemas de gnome-settings-daemon SIN g-s-d, que sigue
aparcada por GTK3/X11. **Tercera vez que aparece la misma lección** (tras la política
D-Bus de login1 y el `org.gnome.login-screen` de libgdm): un gschema no es un fichero de
datos del demonio, es una interfaz publicada que consume otro programa.
Dos trampas de diagnóstico, las dos ahora blindadas:
- **`glib-compile-schemas` sale con 0 aunque RECHACE un esquema.** Instalé los once XML,
el log dijo `esquemas OK` y el shell seguía diciendo `not found`: faltaba
`org.gnome.settings-daemon.enums.xml`, que meson genera con glib-mkenums y no es uno
de los `.in`. Sin los `<enum>`, glib descarta el esquema entero, avisa por stderr y
sigue. `gnome-start` ahora vuelca ese stderr SIEMPRE, no sólo al fallar.
- El log serial persiste entre arranques y me hizo leer dos veces un `STATUS +30s` de una
VM ya muerta. Truncarlo antes de arrancar; `Failed to get "write" lock` avisa de que
hay otro QEMU con el disco tomado.
Y queda escrito cómo validar CON PANTALLA sin humano delante: screendump por el monitor
de QEMU, con una métrica barata previa a mirar — contar colores distintos. Negro = 2;
pintando = 582, con el azul GNOME (2,60,136) al frente.
Lo que falta son detalles, ninguno impide el escritorio: lanzar upowerd desde gnome-start,
un tema de cursor, el setuid de colord y gnome-control-center.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Estado: gnome-shell corre 5 minutos sobre DRM real sin una sola JS ERROR, y la
captura del framebuffer muestra la consola del kernel en negro. Mutter nunca
presentó un frame.
La pista del log de KMS es concreta: el plano primario 33 de virtio-gpu 'has no
advertised formats' y sólo hay 'Queue mode set' — ningún page flip. Tres hipótesis
de una variable cada una, la primera es quitar MUTTER_DEBUG_FORCE_KMS_MODE=simple,
que se heredó de la campaña KDE (donde el que fallaba con atomic era kwin).
Queda además escrito CÓMO validar con pantalla sin humano delante: screendump por
el monitor de QEMU + PPM→PNG. Aplicar esa regla es lo que destapó este muro — el
serial decía 'sesión viva'.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Venía cerrando typelibs de a uno: AccountsService → DBus-1.0 → cairo-1.0 → Gdm-1.0,
un rebuild de imagen y un arranque completo por cada uno. Cuatro rondas para
descubrir que la lista estaba escrita todo el tiempo.
`js/misc/dependencies.js` de gnome-shell ENUMERA lo que el shell exige al arrancar.
Cruzada contra el rootfs hidratado, la frontera completa es exacta:
GnomeDesktop-4.0 + GnomeBG-4.0 → gnome-desktop (YA sellada, pero -Dintrospection=false
y estática ⇒ falta la variante de isla dinámica)
Geoclue-2.0 → geoclue (sin receta)
GWeather-4.0 → libgweather (sin receta)
IBus-1.0 → ibus (sin receta)
Rsvg-2.0 → librsvg (sin receta; es Rust)
UPowerGlib-1.0 → upower (sin receta)
Los otros veinte de la lista ya están. GnomeBluetooth, NM/NMA4 y Malcontent son
condicionales y no bloquean.
REGLA, y es el precio de no haberla aplicado antes: cuando el muro es `Requiring X`,
no cierres X y vuelvas a arrancar — leé el fichero donde el programa DECLARA sus deps
de runtime y cerralas todas de una.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Con el `O_NONBLOCK` de TakeDevice (tawasuyu 3dd88f582, receta re-sellada
b3:7ffa9256), gnome-shell arranca en QEMU sobre el backend nativo KMS, no headless:
BACKEND: Opening and taking control of device file '/dev/input/event0' (y event2, event1)
BACKEND: Realizing stage 'MetaStageNative'
KMS: Plane 33 … primary for CRTC 37 · Plane 34 … cursor
Using Wayland display name 'wayland-0'
== gnome-qemu :: compositor OK (wayland-0) — el shell ES el display server
El muro gráfico que este runbook anunciaba como «el que viene después» NUNCA
APARECIÓ: los fixes que pagó la campaña KDE y quedaron precargados en
gnome-start-qemu.sh alcanzaron tal cual. mutter crea el renderer gbm y elige card0
como primaria sin quejarse.
Queda un solo muro, y no es un cuelgue: el shell sale con código 1 en
`Requiring AccountsService` — una dep de RUNTIME que la receta ya tiene medida
símbolo por símbolo.
El runbook además CORRIGE su propio diagnóstico anterior (culpaba a libudev-zero) y
deja escrito cómo se refutó, que es lo reusable: una sonda que hace lo mismo que el
código sospechado pero por otro camino, y /proc por hilo ANTES de abortar —porque
gdb no desenrolla a través de musl y el core sólo da `?? ()`.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Dos bugs REALES de arje-logind-compat, encontrados arrancando la imagen y
arreglados (con test) en el árbol de tawasuyu — todavía LOCALES, sin pushear:
1. La sesión se creaba PEREZOSAMENTE. `ensure_user` sólo corría dentro de un
método del Manager, y `write_login_state` vive adentro. Pero mutter no
empieza por D-Bus: lo primero que hace es sd_pid_get_session(), que
arje-sdlogin-compat resuelve LEYENDO /run/systemd/sessions. Huevo y gallina:
el estado en disco sólo se escribía después de un pedido que sólo ocurre si
el estado ya existe. Ahora se crea al arrancar (eager_session).
2. El object path de la Session estaba MAL ESCAPADO: era `/session/_1`. La
convención de systemd (bus_label_escape) codifica `_<hex>` todo lo que no sea
[A-Za-z0-9] **y también el primer carácter si es dígito** ⇒ el id "1" da
`_31`. Importa porque el cliente calcula el path por su cuenta y NO pregunta:
mutter reimplementa la misma regla en meta-dbus-utils.c. Con `_1` no había
nadie sirviendo ahí, la propiedad `Seat` volvía NULL y mutter —que no
chequea— moría de SIGSEGV en get_seat_proxy. Los objetos User NO usan este
escapado (systemd hardcodea `_<uid>`), así que user_path() queda igual.
Y ARJE_LOGIN_STATE=1 YA EXISTÍA: el comentario del daemon dice literalmente "en
arje (sin systemd) el launcher de sesión lo prende. Default off" — y el launcher
es gnome-start. El puente que escribía /run/systemd/ a mano era reinventar esa
perilla; queda de fallback inerte.
Resultado: el shell ya no crashea. Corre con 12 hilos, /dev/dri/card0 abierto
tres veces y /dev/input/event0 abierto — el TakeDevice de logind funciona y el
compositor tiene DRM master e input. Queda bloqueado en
meta_seat_impl_initable_init (meta-seat-impl.c:3154): espera en un condvar a que
la "Mutter Input Thread" avise que inicializó, y nunca avisa. Hipótesis principal
libudev-zero, que ya dio un episodio idéntico en el frente de la USB nvidia.
El gnome-start ahora le fuerza un core con SIGABRT al proceso colgado: sin gdb en
la imagen es la única forma de ver dónde está parado.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
gnome-shell bootea, compila sus esquemas, toma el DRM de virtio-gpu y se declara
Wayland display server. Después SIGSEGV. El backtrace del core no deja dudas:
#4 g_variant_get (value=0x0, "(s&o)") ← GVariant NULO
#5 get_seat_proxy src/backends/meta-launcher.c:407
#6 meta_launcher_new (META_LAUNCHER_FLAG_TAKE_CONTROL)
Mutter pide la propiedad `Seat` del objeto **Session** de logind — `(s&o)` es su
firma estándar (nombre_del_seat, object_path). arje-logind-compat adquiere
org.freedesktop.login1 y sirve el Manager, pero NO expone un objeto Session con
esa propiedad ⇒ la lectura devuelve NULL y mutter desreferencia sin chequear. Que
mutter no valide es fragilidad suya; el hueco es nuestro.
Cinco eslabones hubo que armar antes de llegar a ese muro, ninguno anotado:
1. gschemas.compiled NO se genera con DESTDIR seteado (meson lo dice en el log
del build) ⇒ GSettings abortaba en el primer g_settings_new().
2. GI_TYPELIB_PATH tiene que incluir /usr/lib/gnome-shell: St/Shell/Gvc/Shew se
instalan aparte por ser privados del shell. Es el env sin análogo en KDE.
3. /var/run no existía en la base metal; arje-logind-compat busca el bus en la
ruta legacy y sin el symlink se iba a "modo idle".
4. La política D-Bus de login1 faltaba (system.conf trae <deny own="*"/> y
normalmente la instala systemd). PERTENECE al artefacto de arje: está en el
script de imagen sólo para dejar visible qué falta empaquetar.
5. /run/systemd/{sessions,seats,users} vacíos — libelogind resuelve la C-ABI
sd-login LEYÉNDOLOS y nadie los escribe (el Announce de arje-logind-compat al
bus del fractal falla con "identity mismatch"). gnome-start los escribe A
MANO y está MARCADO COMO ANDAMIO. Con ese puente desaparece el "Failed to
find any matching session".
Gotcha que costó una iteración: `kill -0` TIENE ÉXITO sobre un zombi (el padre no
lo cosechó todavía), así que el script reportaba "sin wayland-0 tras 45s" cuando
el shell había muerto en el primer segundo. Mirando State: de /proc/<pid>/status
sale el código real, 139.
Todo el ciclo (hidratar → imagen → bootear → sacar el core con debugfs → gdb) y
la lista de lo que falta quedan en docs/runbooks/gnome-qemu-desktop.md.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Cómo relanzar (run-qemu-desktop.sh), verificar sin ojos humanos (screendump por el
monitor QEMU + STATUS del serial), reconstruir la imagen, y la tabla de los 7 fixes
que lo hacen andar + los gotchas de operación (serial stale, pkill auto-mata, OVMF
VARS stale → TianoCore). Para relanzar/verificar, no rediagnosticar.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Test real (worker + volumen + helper), no en el papel. Las 3 piezas:
1. worker midió lz4+bzip2 → volumen
2. tras 1 ciclo idle SE AUTO-ELIMINÓ (verificado: el server desapareció solo)
3. volumen SOBREVIVIÓ con los 2 verdicts; helper efímero ccx13 los recogió al
hub y se auto-destruyó
3 bugs cazados EN EL TEST (no adivinados):
- falta --exclude /work: work/=69GB colgó el rsync del up horas
- cpx11 'unsupported' en hel1 (AMD sin stock) → ccx13
- collect llamaba harvest con 'local' (rsync a un worker inexistente): ahora
sólo recoge; clasificar es paso aparte (worker mide, hub clasifica)
+ auto-delete por API REST (curl+metadata), NO hcloud CLI (la golden no lo trae).
El ID propio sale del metadata service, no del nombre.
Cierra los 2 huecos de la 1ª campaña: idle cobrando (ahora auto-delete) y
dependencia de que yo esté viva (ahora el volumen persiste). Runbook:
docs/runbooks/harkaq-granja-volumen.md. Volumen clausurado tras el test (€0).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
El laptop corre arje-zero como init (no systemd, systemctl no existe) y no tiene
crond activo. El crontab que instalé anoche corrió 0 veces: validé que la LÍNEA
corría a mano, nunca que un daemon fuera a dispararla. Mismo patrón que me mordió
toda la sesión — validar la pieza, no el sistema.
Disparo real: scripts/farm/harvest-loop.sh con setsid nohup. Sobrevive el fin de
sesión, no un reboot (eso pediría un servicio /etc/init.d, con root).
+ 2 bugs del harvest arreglados: flock anti-solape (dos ciclos editando+commiteando
a la vez = árbol corrupto) y el rescate rechazaba recetas legítimas por la línea
en blanco que add-deps añade (el + vacío no matcheaba [deps].build).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Estado escrito en el repo y no en mi cabeza: la campaña tiene que sobrevivir a
que yo desaparezca al final del turno. Qué corre, dónde, cómo revisarlo por la
mañana, cómo pararlo, y los rastrillos que ya se pagaron (el cd del cron, el
pull sucio, cargo fuera del PATH).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Toda la variante (b) del SDD 11 §7.2 vivía sólo en scripts/rust-frontier/README
y notas dispersas; el SDD §7.2 y el runbook §8c quedaban en "Pendiente:
linux-headers → bwrap → rust/llvm". Nuevo runbook docs/runbooks/
self-hosting-toolchain.md documenta el end-state:
- las dos categorías de swap y los dos anclajes de of_tree (9adefb82 rustc
Alpine / 7fa6cb4e hammer-rust auto-consistente);
- tabla de las piezas from-source (make/busybox/coreutils/bwrap/linux-headers
/rust/binutils + patch/m4/pkgconf) con hash, flag y si están en-camino;
- las 3 corridas verify (5-swap, rust, capstone 6-swap) con comandos y
resultados ✓ REPRODUCIBLE in-VM;
- el mecanismo --swap (archivo/directorio/rust-overlay);
- gotchas reusables (zig miscompila→gcc, musl 256 TLS keys, CARGO_BUILD_JOBS=1,
zsh :u / word-splitting);
- binutils inerte verificado por bisección.
SDD §7.2 y runbook §8c ahora marcan variante (b) cerrada y enlazan el runbook.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
KVM=1 MEM=24576 SWAP_MAKE=1 SWAP_BUSYBOX=1 ./scripts/selfhost-verify.sh en libre:
la VM reconstruyó los 4/4 con el /toolchain hammerizado (make fbad44ac… +
busybox 56664d70… pisando los de Alpine, busybox compilándose a sí mismo con
hammer-busybox de shell). of_tree(stage1')==EXPECT_REF 9adefb82… ⇒
✓ REPRODUCIBLE: stage1' == stage1, DRIVER_RC=0 (~54 min, arje-zero cu=1 in-VM).
La procedencia del builder deja de ser "todo Alpine" y el auto-alojamiento
sigue bit-a-bit. Siguiente pieza: linux-headers → bwrap → rust/llvm.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Corrida KVM=1 MEM=24576 ./scripts/selfhost-verify.sh en el host (libre/cachyos):
la VM reconstruyó los 4/4 con el toolchain de adentro (arje-zero cu=1 compiló en
27m32s in-VM), of_tree(stage1')=b3:0039b2b9… igualó la referencia ⇒
✓ REPRODUCIBLE: stage1' == stage1 (auto-alojado bit a bit), DRIVER_RC=0.
Cierra el hunt de codegen-units (commit 4c9bcc0): la reproducibilidad de arje-zero
queda confirmada en el bucle completo host↔VM, no sólo host↔host.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
El rebuild in-VM daba ✗ DIVERGENTE (of_tree host 984e002f ≠ VM 94b93585) pese a
que los 4 componentes sellaban bajo el mismo key of_inputs. Bisección por componente
en el host: musl, busybox y hammerd reconstruyen byte-idéntico, y la ensambladura del
rootfs (of_tree) es determinista e independiente del entorno. El culpable era arje-zero:
dos builds del MISMO host daban binarios distintos (Δ ~9.6 KB por .text/.rodata/.eh_frame/
.gcc_except_table) — firma del codegen paralelo de rustc.
Raíz: el workspace de hammer pinea [profile.release] codegen-units=1 (por eso hammerd
reproducía), pero el monorepo tawasuyu no declara perfil → cargo default codegen-units=16,
cuyo reparto del crate en N objetos varía build-a-build.
Fix: el sandbox impone codegen-units=1 para TODAS las crates Cargo (el var de cargo gana
sobre el profile del repo fuente). El lab elimina el no-determinismo en vez de confiar en
upstream (SDD 09 §2). Verificado: dos builds cu=1 de arje-zero → byte-idénticos.
Nueva referencia reproducible 4/4: of_tree(stage1)=b3:0039b2b9… (reemplaza 198f209f… de
cu=16). Actualizados EXPECT_REF (selfhost-verify.sh) y runbook §8b/§8c.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
El veredicto pleno 4/4 in-VM pide KVM + RAM holgada; el host de dev (7.6 GB, sin KVM)
colgó por presión de RAM bajo TCG a los ~17 min del make de musl. Esta tarea traslada
la verificación a una máquina capaz (laptop) en un solo comando.
- scripts/selfhost-verify.sh: pipeline completo — stage0 → stage1 baseline → stage2
(ancla la ref of_tree) → inyecta overlay.ko/e1000.ko del kernel local al toolchain →
ensambla el builder con la ref embebida → empaqueta (cpio --owner=root:root) →
bootea + driver no-interactivo → veredicto. KVM auto-detect; PRESEED=hammerd para el
camino barato (preseed C+arje, sólo hammerd in-VM). Cross-check entre máquinas:
compara su of_tree(stage1) contra EXPECT_REF (198f209f… conocida-buena del dev).
- scripts/drive-rebuild.py: driver no-interactivo parametrizado (env: BUILDER_CPIO,
KERNEL, MEM, CPU, KVM, NET, DEADLINE, LOG). Bootea, espera la shell de arje-zero,
manda rebuild-stage1 y sale 0 si REPRODUCIBLE / 1 si DIVERGENTE. (Versión de repo del
driver ad-hoc que vivía en work/.)
- scripts/boot-builder-vm.sh: añade la NIC e1000 (NET=1 por defecto) — el vendoring Rust
necesita red.
- runbook §8c: documenta la tarea y el muro de RAM del host de dev.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Refresca los 4 componentes (musl, busybox, hammerd, arje-zero — éste re-vendorea el
monorepo) con el toolchain baseline en un store limpio y lo promueve a ./store (el
nativo queda en store-native-bak, gitignored). arje-zero baseline difiere del nativo
⇒ el fix -mcpu=baseline alcanza también al monorepo. Referencia CPU-independiente
full-4/4: of_tree(stage1)=
b3:198f209f5e2c9d3a37411823b2ea42a09074d4e482f044278958b1b86f232dbb (rootfs key
b3:2bd7c91b…, idéntico al del preseed-nativo: el cambio de bytes de arje no movió su
key of_inputs — la escotilla C.2 de nuevo).
Builder re-ensamblado con ese toolchain + hammer baseline + --ref-content 198f209f
(embebida en /etc/hammer/rebuild.env) y repackado a work/builder.cpio.gz (415 MB,
27027 entradas, --owner=root:root). Queda listo para bootear: adentro rebuild-stage1
debe reproducir 198f209f ⇒ ✓ REPRODUCIBLE cerraría el auto-alojamiento 4/4 bit a bit.
.gitignore: ignora /store-*/ (stores scratch/backup) — evita commitear el store.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
El rebuild in-rootfs de Stage 2 cazó un no-determinismo real: stage1 reconstruido
en la VM divergía del host (of_tree host=b3:94a4f1… vs VM=b3:ab615b…), aun con el
seal hash idéntico (el seal es of_inputs: mismo key ≠ mismos bytes).
Diagnóstico (control en el host, sin VM): un rebuild de hammerd en el host es
byte-idéntico al cacheado, así que la receta es determinista host-a-host y el cache
no está stale. La divergencia es del entorno de build de la VM: `zig cc` default a
`-mcpu=native` y hornea la ISA del builder en el C/asm de los build-scripts (blake3,
curve25519-dalek). El host tiene SHA-NI+AVX2; `-cpu Broadwell` (VM bajo TCG) no tiene
SHA-NI ⇒ codegen distinto ⇒ bytes distintos ⇒ of_tree distinto. Misma raíz que el
SIGILL de AVX del runbook §7 (binarios al CPU del builder, no a un baseline genérico).
Fix: `-mcpu=baseline` en TODOS los sitios zig cc — CC/CXX del sandbox, los dos
wrappers Cargo (.hammer-zig-cc) y CC/HOSTCC de la receta de busybox. Las rutas SIMD
del runtime (blake3/sha2) son asm con dispatch en runtime: siguen presentes. Bonus:
cierra el AVX/SIGILL del §7 (corre en qemu64 sin -cpu Broadwell).
Validado en el host: con baseline hammerd cambia de bytes (1672448 vs 1677584 —
confirma que el default no era baseline) y los 3 componentes rebuildan limpio
(stage1 rc=0). Nueva referencia CPU-independiente of_tree(stage1-baseline)=
b3:4408e44e2ec51c3769deffcd64dd1f6c2010d414418937c3fa7930a0ded3f845. Runbook §8c
documenta el cruce del muro Rust-offline (cargo vendor por la NIC, hammerd sellado
in-VM en 74m35s) y este diagnóstico+fix.
Nota (plan C.2): el flag de CPU no entra en of_inputs ⇒ cambio de toolchain/flags da
cache-hit con bytes viejos; cerrar ese "pin de toolchain al hash" es trabajo aparte.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Registra la corrida real (QEMU TCG): la cadena de muros que sólo el rebuild
DENTRO de la VM destapó y que se arreglaron en orden — toolchain sin
bwrap/git/curl, binarios dinámicos vs userland estático (shim del loader), overlay
como módulo no cargado (insmod), y ownership del initramfs (cpio --owner=root).
Resultado: musl y busybox se reconstruyeron y SELLARON dentro de la VM con el
toolchain de adentro (~35-38 min/componente bajo TCG) — auto-alojamiento probado
sobre builds reales. hammerd abortó en `cargo vendor` (deps crates.io no
provistas offline; la VM no tiene red). El 4/4 pleno necesita red en la VM o
crates vendoreadas + un host con KVM/más RAM (idealmente builder desde disco).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
El run en la VM, ya con overlay cargado, fallaba en `bwrap: Can't mkdir /opt/zig:
Permission denied`. Diagnóstico (el rootfs resultó ser tmpfs, no ramfs, así que
no era el fs): los ficheros del builder viajaban con el uid del que lo armó
(1000). En la VM corren como root (0); el userns de bwrap mapea sólo 0→0, así que
el 1000 queda SIN mapear y el copy-up de overlay no puede preservar el owner del
/opt copiado ⇒ EACCES. En el host funciona porque bwrap mapea 1000→0.
Fix: empaquetar el initramfs con `cpio --owner=root:root` (runbook §8c). Revierte
el staging-a-tmpfs (era una hipótesis ramfs equivocada); rebuild-stage1 vuelve a
HAMMER_ROOTFS=/toolchain y documenta el requisito de ownership. 28 tests verdes.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Smoke test real (qemu -cpu Broadwell, initramfs 410 MB gz): el builder rootfs
bootea hasta la shell. arje-zero como PID 1 carga+valida la seed card, instancia
hammerd (pid 60) + console-getty (pid 61), hammerd levanta watcher fanotify +
agent.sock, y la getty deja `~ #` en consola. Mismo boot que Stage 1 pero con el
toolchain adentro — listo para `rebuild-stage1`.
Actualiza la receta de §8c: script boot-builder-vm.sh, MEM=6144, kernel real,
nota de RAM (tmpfs + rebuild en RAM va justo sin KVM).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Al construir el hammer estático musl y armar el builder con --work-cache work,
dos problemas reales (cazados antes de llenar el disco):
1. Recursión. --work-cache work --out work/builder-rootfs deja el destino DENTRO
de la caché: copiar la caché se tragaba el propio builder a medio armar
(work/builder-rootfs/work/builder-rootfs/… sin fondo). Fix: link_or_copy_tree
toma un `skip` (path canónico a no descender), que corta el ciclo.
2. Bloat de sources. --work-cache copiaba TODO work/, incluidos los árboles ya
materializados de work/sources (4 GB, regenerables). Fix: sólo se embeben
work/repos (mirrors git) y work/tarballs (descargas verificadas); de ahí
`fetch` rematerializa los sources en la VM. El builder pasa de ~5 GB a ~750 MB.
+2 tests (recursión termina y no se auto-copia; sources/ no viaja). Runbook §8c
aclara la semántica de --work-cache. El hammer estático musl
(target/x86_64-unknown-linux-musl/release/hammer) sale static-pie linked, listo
para bootear como PID-algo en la VM.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
El único sub-ítem que le quedaba a Stage 2: el rebuild *dentro* del rootfs. El
Stage 1 que booteamos es runtime (musl+busybox+hammerd+arje-zero), sin compilador
— no puede reconstruirse. El builder rootfs es Stage 1 + el toolchain adentro.
Implementa `hammer_bootstrap::builder_rootfs` (variante a pragmática, SDD 11 §7.2):
sobre el Stage 1 rootfs hidratado monta /toolchain (rootfs Alpine = sandbox de
build), /store con la semilla replicada (el hammer de adentro resuelve zig por
hash), /usr/bin/hammer + /etc/hammer/recipes, y el driver /usr/bin/rebuild-stage1
que apunta HAMMER_ROOTFS=/toolchain, corre `bootstrap stage1` y compara stage1'
contra la referencia con `stage2 --verify` (lee SEED_HASH/SEED_KIND/REF_CONTENT
de /etc/hammer/rebuild.env).
- BuilderSpec/BuilderReport + builder_hash lógico (insumos: stage1+semilla+
recetas+binario+tag toolchain+driver) — reproducible y auditable sin hashear el
árbol Alpine; anota línea stage 2 en el manifiesto.
- link_or_copy_tree (hardlink-or-copy, sin chmod: no toca permisos del .dev-fs).
- El builder no se sella (toolchain Alpine no es content-addressed); se ensambla
en out_dir para empaquetar como initramfs.
- CLI `hammer bootstrap builder --stage1 H --seed-hash H [--hammer-bin] [--toolchain]
[--ref-content] [--work-cache] [--out]`. +4 tests (assemble, hash determinista,
sin-ref, stage1 no sellado).
Validado contra el store real: Stage 1 73d7a9be… + semilla 3ce721ec… ⇒ builder
81dad3d9… (1.2 GB con el toolchain). Lo que queda es operacional: bootear en la
VM y correr rebuild-stage1 — runbook §8c documenta la receta (hammer estático
musl, initramfs, qemu -cpu Broadwell, --work-cache para rebuild offline).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Cierra el ◑ de arje-zero sin un rebuild de horas: su único riesgo era el
Cargo.lock generado sin --locked (tawasuyu lo gitignora). Verificado barato —
dos `cargo generate-lockfile` del commit pinned dan un lock byte-idéntico
(resolución determinista) — y el camino de build Rust ya está probado
bit-reproducible vía hammerd.
Los 4 componentes de Stage 1 (musl, busybox, hammerd, arje-zero) están
verificados reproducibles. Lo único que le queda a Stage 2 es el rebuild dentro
de un builder rootfs (auto-alojamiento pleno) — hito aparte.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Tercer componente probado byte-idéntico entre dos builds independientes: el
camino Rust (crt-static + cargo --locked + SOURCE_DATE_EPOCH + paths fijos /src)
reproduce. 3/4 componentes verificados reproducibles (musl, busybox, hammerd).
arje-zero queda ◑: mismo camino, pero vendorea sin --locked (tawasuyu no committea
Cargo.lock) ⇒ el lock generado podría variar entre corridas; committear el lock
en tawasuyu lo cerraría (plan C.2 #5).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
La verificación de reproducibilidad de Stage 2 (dos builds + diff de bytes) probó
que musl reconstruye bit-idéntico pero busybox NO, y cazó dos no-determinismos:
1. Config interactiva: tras editar .config, silentoldconfig prompea por opciones
NEW leyendo stdin → set de applets variable (build no-determinista y flaky).
Fix en busybox.toml: `yes '' | make oldconfig` (defaults, determinista;
1.36.1 no tiene olddefconfig).
2. Headers UAPI del kernel: el config determinista habilita console-tools, que
exige linux/kd.h (zig no la bundlea). Fix: linux-headers en bootstrap-devfs.sh
(zig cc nativo la halla en /usr/include).
Con ambos, musl y busybox reconstruyen bit-idéntico. Runbook §8b documenta la
verificación y deja pendiente: reproducibilidad de los componentes Rust y el
rebuild dentro de un builder rootfs (auto-alojamiento pleno).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Desde la consola del Stage 1 booteado: kill $(pidof hammerd) → arje-zero lo
supervisa de verdad:
Ente disuelto label=hammerd status=Killed(SIGTERM)
Restart programado label=hammerd delay_ms=200
Ente encarnado label=hammerd pid=Some(Pid(64))
Detecta la muerte con su ExitStatus, hace backoff y re-encarna hammerd (pid
59→64). Es la supervisión real del init propio (ADR 0007) que la Fase 5 había
diferido. Runbook §8 y roadmap actualizados. Pendiente: B.2 (exponerlo a la
capa de IA por agent.sock) y atestación A1/A2.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
La corrida real cierra el lazo: con el build nativo crt-static (cargo rustc),
arje-zero y hammerd salen statically-linked (ET_EXEC, sin DT_NEEDED), el rootfs
se sella, y el boot en QEMU (-cpu Broadwell) levanta el sistema:
arje-zero (PID 1) → carga+valida /ente/seed.card.json → bucle primordial →
encarna hammerd (Pid 59) + console-getty (Pid 60) → shell en consola;
hammerd levanta su watcher fanotify y el agent.sock.
Runbook §8: bitácora completa (todos los fixes: gcc/HOSTCC, GNU-ld, rust en el
lab, triple nativo, wrapper saneador, vendoring condicional, AVX→Broadwell,
dinámico→crt-static vía cargo rustc). Roadmap: Stage 1 ◑→✅.
Pendiente: demo del CRASHED real (kill hammerd → restart con backoff; la
supervisión Restart ya corre), bus único (B.2), atestación (A1/A2).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Cierra el último bloqueo del boot que la corrida en QEMU destapó (runbook §8):
arje-zero/hammerd buildeaban DINÁMICOS contra musl (el rust de Alpine es dinámico
por defecto) → DT_NEEDED libc.musl-x86_64.so.1, y nuestro libc.so (musl shared con
zig cc) no exporta memcpy/memset/… → el loader falla y el init muere.
Fix golden-path: para link=static, RUSTFLAGS ahora fuerza
-C target-feature=+crt-static -C relocation-model=static
⇒ binarios AUTOCONTENIDOS (musl dentro), ET_EXEC sin interpreter, como busybox:
sin libc.so, sin loader, sin el soname de Alpine. musl vuelve a --disable-shared
(no se necesita el loader). Boot en QEMU: usar -cpu Broadwell (el qemu64 default no
tiene el AVX que zig emite).
Validado por la corrida real: los 4 componentes buildan y el rootfs se sella; el
kernel arranca el initramfs y ejecuta arje-zero como PID 1. Falta rebuildear
hammerd/arje-zero con crt-static para cerrar el boot (cache-bust + rebuild).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Resuelve el bloqueo Rust de la primera corrida: el rust de Alpine es
x86_64-alpine-linux-musl y --target x86_64-unknown-linux-musl no tiene std.
Cuando recipe.build.target == SANDBOX_NATIVE_TARGET (x86_64-linux-musl, el del
sandbox), se construye NATIVO (sin --target): el std nativo del rust del sandbox
sirve. El wrapper .hammer-zig-cc ahora:
- es un único ejecutable (resuelve el `zig cc` de dos palabras que cargo y cc-rs
mal-parsean),
- SANEA el triple: cc-rs (build scripts, p.ej. blake3) detecta el host triple de
Alpine y pasa --target=x86_64-alpine-linux-musl, que zig rechaza
(UnknownOperatingSystem); lo reescribe a x86_64-linux-musl.
Se usa como CC (cc-rs) y como linker (RUSTFLAGS). El cross real conserva --target.
Validado en VM real: hammerd compila nativo con zig cc y se sella. +1 test (cross
mantiene el triple), detect_cargo actualizado. arje-zero queda bloqueado aparte:
tawasuyu no commitea Cargo.lock (vendor --locked falla) — ver runbook §8.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Primera ejecución del runbook en el host. El userland C builda end-to-end; el
camino Rust queda bloqueado por una decisión de toolchain. Hallazgos verificados:
recipes/busybox.toml — tres incompatibilidades GNU-toolchain ↔ zig, resueltas:
- gcc hardcodeado (CC/HOSTCC = gcc con `=` ignora el env): pasar CC='zig cc'
HOSTCC='zig cc' en línea de comando de make
- flags GNU-ld que zig cc valida y rechaza (--warn-common, -Map, --verbose):
quitarlos de scripts/trylink con sed
Con esto musl 1.2.5 y busybox 1.36.1 compilan, linkean y se sellan.
scripts/bootstrap-devfs.sh — añade rust+cargo al rootfs (las recetas Cargo
corren cargo en el sandbox), con CAVEAT: el rust de Alpine es
x86_64-alpine-linux-musl pero BuildSys::Cargo pide x86_64-unknown-linux-musl
(no instalado, sin rustup) → bloquea hammerd/arje-zero. Decisión de toolchain
abierta (plan C.2).
docs/runbooks/stage1-vm-boot.md §8 — bitácora con la tabla de etapas, los fixes
y las opciones para resolver el triple Rust.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Procedimiento operativo end-to-end para de-riesgar lo construido: stage0 (ingerir
zig) → stage1 (build + ensamblar el rootfs) → empaquetar initramfs (cpio newc +
gzip) → bootear en QEMU con el kernel del host → criterios de éxito.
Fundamentado en los comandos reales del repo (scripts/bootstrap-devfs.sh, la URL
y sha256 de zig 0.16.0, hammer bootstrap stage0/stage1). La prueba clave: matar
hammerd y ver a arje-zero reiniciarlo con backoff — el CRASHED real.
Honesto sobre su estado: es el procedimiento, no un transcript verificado; el
cross-compile y el boot reales aún no se corrieron (ese es el punto). §7
anticipa los ajustes probables (init, /dev/console, getty/tty, -lgcc_s).
Enlazado desde SDD 12 §I2 y el índice de docs.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
sergioandClaude Opus 5