`/usr/lib/libgcc_s.so` no es una librería: es un ld script —`GROUP ( libgcc_s.so.1 -lgcc )`— y ese
`-lgcc` es libgcc.a, que ninguna receta del corpus proveía. Esta misma la borraba: el
`find -name '*.a' -delete` de la poda, y de paso el `rm -rf /usr/lib/gcc` se llevaba el original.
Medido en la caja con el rust recién sellado: los binarios estáticos compilan y corren, pero
cualquier dylib —y eso incluye TODAS las proc-macros— muere con `unable to find library -lgcc`. O
sea `cargo build` con `derive` imposible sobre takana, con el compilador perfecto. Y no alcanza con
dar `-L /usr/lib`: con eso se resuelven `-lc` y `-lgcc_s`, y entonces aparece justo este `-lgcc`.
Es la misma familia que el hueco que originó esta receta —todo presente, todo reproducible, y el
camino que hace falta no existe—, sólo que del lado del ENLACE en vez del arranque.
libgcc.a se copia a /usr/lib (donde el -L del enlazador ya mira; el gcc completo no está en esta
distro) y se salva de la poda. Y entra un GUARDIÁN 3 que compara lo que el ld script PIDE contra lo
que el artefacto TRAE: si vuelve a quedarse sin libgcc.a, corta.
Radio medido con yupana antes de tocar: 7 dependientes directos, 9 transitivos, 7 imágenes.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
rust selló en el worker (b3:6441302d…, 352 M, 17m47s de build), y con eso no queda ninguna receta en
deuda ni sin construir: base 74/74, cli 142/142, escritorio-mirada 41/41, metal-tigerlake 7/7 y
servidor 175/175.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Tres intentos persiguieron el mismo problema por partes: `-lgcc` no se encuentra, después `-lgcc_s` y
`-lc` en los build scripts del stage2. La causa es una sola: un enlazador invocado SIN driver de C no
conoce los caminos del sistema. Ese `-L /usr/lib`, el directorio privado de gcc y las libs implícitas
las agrega `gcc`, no `ld`. Dárselos a mano es una lista sin fondo, porque cada etapa del bootstrap
enlaza cosas distintas.
Y el intento de dárselos por RUSTFLAGS (_BOOTSTRAP y _NOT_BOOTSTRAP) NO llegó a los build scripts:
comprobado mirando el renglón de enlace, donde `/usr/lib` seguía sin aparecer. Así que la cura va
donde corresponde: `linker = "gcc"` en el `[target.x86_64-alpine-linux-musl]` de bootstrap.toml. De
paso, con gcc de driver los `-Wl,-rpath,…` del bootstrap vuelven a ser válidos —eran lo que había
obligado a `rpath = false`, que se deja igual porque sigue siendo lo correcto con prefijo /usr—.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Con `-lgcc` resuelto, el build avanza y muere más adentro: los build scripts de libc, proc-macro2 y
quote no encuentran `-lgcc_s` ni `-lc`. Mirando el renglón de enlace entero, sus únicos `-L` son sus
propios directorios de build: NO lleva /usr/lib. El enlace de `std` sí lo llevaba —de ahí
`musl-root = "/usr"`—, pero eso aplica al TARGET, no a los binarios de HOST que el bootstrap compila
por el camino.
Es la misma causa de las tres veces: sin driver de C, nadie agrega los caminos del sistema. Se los
damos por RUSTFLAGS en las dos variantes que mira el bootstrap (_BOOTSTRAP para lo que compila el
stage0, _NOT_BOOTSTRAP para stage1+). libc.so, libc.a y libgcc_s.so están los tres en /usr/lib del
lab: comprobado, no supuesto.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
El primer intento dejó el enlace en `configure` y lo comprobó ahí mismo: la comprobación dio ✓ y el
build murió igual, con el log mostrándolo con claridad cruel —«rust: libgcc.a enlazada desde
/usr/lib/gcc/…» y, tres pantallas después, «ld.lld: error: unable to find library -lgcc»—.
La causa es que LAS FASES NO COMPARTEN SISTEMA DE FICHEROS: cada una es un bwrap nuevo con
`--tmp-overlay /`, que es una capa tmpfs DESCARTABLE (lo dice el propio comentario de sandbox.rs).
El enlace se evaporó entre configure y compile. Un guardián que comprueba en la misma fase en la que
escribe confirma algo que ya no será cierto cuando importe: lo que cambia el entorno de una fase se
hace EN esa fase. Ahora va al principio de `compile` y de `install`, que son las que enlazan.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
El build muere a los 6 minutos enlazando libstd.so: `ld.lld: error: unable to find library -lgcc`.
Es la otra cara de lo que la receta ya documentaba para `rpath = false`: al poner ld.lld como
enlazador del triple, se invoca DIRECTO, y el `-L` del directorio privado de gcc lo agrega gcc, no
ld. libgcc_s.so sí está en /usr/lib —por eso `-lgcc_s` pasa y sólo falla el estático—, pero libgcc.a
vive en /usr/lib/gcc/<triple>/<version>/.
Se enlaza a /usr/lib, que el propio renglón de enlace que falla ya busca. La ruta sale de
`gcc -print-libgcc-file-name` y no escrita a mano a propósito: la versión es del LAB, que no entra en
hash_inputs, así que una ruta literal se rompería en silencio el día que el lab mueva de gcc.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Si el push del estado se rechaza porque otro agente empujó primero, el ciclo siguiente se rechaza
IGUAL —nadie rebasa nunca— y el commit del cron se queda local para siempre. Se encontró en la caja:
rama divergente con un `estado: cosecha granja` atascado y la cosecha diciendo «reintenta» cada media
hora sin que nada cambiase. El mensaje tranquilizaba y no era cierto.
Ahora, cuando lo rechazan, llama a `git-sincronizar.sh`, que es la regla 2 ter automatizada: rebasa,
COMPRUEBA por parche que el commit sobrevivió, lo recupera del reflog si no, y empuja. Y si tampoco
puede, lo dice y deja el comando para verlo, en vez de prometer un reintento que no existe.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
linux-firmware sella por primera vez (1,9 G, 4885 ficheros y los 2415 enlaces de WHENCE),
wireless-regdb entra al corpus y firmware-tigerlake deriva sus 55 blobs (wifi=28, i915=15, sof=10).
Con eso `metal-tigerlake` pasa de 2/6 a 7/7 y `cli` sigue en 142/142.
937 selladas, 3 ajenas, 1 en deuda: rust.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
`firmware-tigerlake` cortaba con «falta regulatory.db», y no era un fallo suyo: upstream sacó ese
fichero del tarball de linux-firmware y hoy sólo se publica en su propio proyecto de kernel.org.
Comprobado sobre el artefacto sellado de linux-firmware 20260910: `find -name "regulatory*"` no
devuelve nada.
Lo que pasa sin ella no es «no hay WiFi», que sería fácil de notar: cfg80211 arranca, la tarjeta
asocia, y se queda en el dominio `world` —pierde canales de 5 y 6 GHz y emite a la potencia mínima—.
Un WiFi que funciona y va mal.
La receta NO compila nada: el `make` del proyecto regenera la db y la firma con otra clave, y el
kernel valida contra la que lleva compilada, así que regenerarla la rompería. Copia `regulatory.db` y
su `.p7s` tal cual, y corta si la firma falta —sin firma, cfg80211 ignora la base y volvemos al
dominio world, que es justo lo que veníamos a arreglar—.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Los que faltaban son casi todos de la forma `ath11k/WCN6855/hw2.1/regdb.bin -> ../hw2.0/regdb.bin`:
un `..` no resuelve si el directorio desde el que cuelga todavía no existe, y yo probaba el destino
ANTES del mkdir. Con el directorio creado primero resuelven los 2415 de 2415 — medido sobre el árbol
desempaquetado, no deducido.
Queda dicho en la receta porque la lectura fácil era la contraria: «WHENCE declara enlaces a blobs
que el tarball no trae», que habría llevado a bajar el umbral y sellar un artefacto con 337 firmwares
inalcanzables. Y si el destino de verdad no existe, ahora se borra el directorio vacío que el mkdir
haya dejado: un directorio vacío en el artefacto es exactamente lo que el §3 de CLAUDE.md prohíbe.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Primer intento con el arreglo: 2078 de 2415 (86 %), y el guardián cortó. La causa es que WHENCE
encadena —declara `a -> b` donde `b` es a su vez un enlace que aparece más abajo—, así que en una
sola pasada el destino todavía no existe cuando toca crear el primero. Se repite hasta que una
pasada no agregue nada, con tope de tres. Y ahora salta los que ya existen, para no recontar.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Regenerado tras sellar zsh estático y traer del store de la caja los tres artefactos que sólo vivían
allá (intel-ucode, sof-firmware, linux-generic; verificados por huella de contenido, no por `du`, que
cuenta directorios y difiere entre sistemas de ficheros).
Quedan tres: linux-firmware (nunca construida, bloquea a firmware-tigerlake) y rust en deuda.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Dos defectos medidos el 2026-09-17 al construirla por primera vez en la caja.
1) La receta decía «cp -a preserva los symlinks internos, que es lo que el kernel espera». La premisa
es FALSA: `find -type l` sobre el árbol desempaquetado da 0. Los ~2400 enlaces los crea
copy-firmware.sh al instalar, leyéndolos de WHENCE, y esta receta evita ese script porque pide
rdfind. El resultado habría sido un artefacto de 1,9 G, sellado y reproducible, con iwlwifi MUDO: el
driver pide `iwlwifi-QuZ-a0-hr-b0-77.ucode` en la raíz y el blob vive en intel/iwlwifi/. Justo el
metal al que apunta firmware-tigerlake (TigerLake/AX201) se quedaba sin WiFi. Ahora se crean desde
WHENCE, cuyo destino es relativo al directorio del enlace, y sólo si el destino existe.
2) La aserción de completitud era `> 5000 ficheros`, medida sobre una versión vieja. La 20260910 trae
4889 y el guardián la rechazaba POR COMPLETA. Un umbral escrito a mano envejece y miente en la
dirección cara: frena lo bueno y hace dudar del tarball, que estaba pineado por sha256 y era el
correcto. Ahora se le pregunta a WHENCE, que viaja dentro del tarball y declara cuántos blobs hay.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
El primer build confirmó la predicción que la propia receta traía escrita: `link = "static"` salió
DINÁMICO, contra la libncursesw del lab, y moría con `Error relocating ... symbol not found` —o sea,
habría arrancado en el sandbox de Alpine y no dentro de una imagen—. La causa de fondo es que zsh
carga sus módulos con dlopen; por eso va `--disable-dynamic`, que los mete en el binario.
Pero `--disable-dynamic` solo dejaba un zsh sin `=~`:
zsh:1: failed to load module: zsh/regex
zsh:1: -regex-match not available for regex
Dos explicaciones mías fueron falsas antes de la buena, y quedan escritas en la receta porque las dos
son plausibles y costaron un build cada una: (1) «quedan en link=dynamic, hay que sedearlos a static»
—el sed no cambió nada, los disponibles ya salían static—; (2) «el .mdd evalúa $ac_cv_func_regcomp y
config.status no tiene esas variables, hay que exportarlas» —el configure contesta yes a las cuatro y
el módulo seguía fuera—.
Lo zanjó `configure.ac`, que no opina: con dynamic apagado, un módulo que su .mdd declara `dynamic`
se DESCARTA (link=no) y sólo los que declaran `either` pasan a estático. regex.mdd dice `dynamic` y
complete.mdd dice `either`: por eso había completado y no había `=~`. El arreglo va sobre los .mdd,
antes del configure, y sobrevive a que make regenere config.modules.
Además `--enable-pcre` era una etiqueta, no un hecho: zsh 5.9 sólo habla PCRE1 y el corpus tiene
pcre2; el configure lo decía tres veces. Se quitan la bandera y la dep, que mentían sobre el cierre.
Y el control va EN LA RECETA: la instalación corta si el ELF tiene INTERP o si falta alguno de
{regex, complete, zle, parameter} dentro del binario. Ese guardián es quien atajó los dos intentos
fallidos en vez de sellarlos. Medido sobre el artefacto: statically linked, 16 módulos cargan,
`=~` contesta, 1663 completadores, 14 M.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
`build-state-view.py` traía los cuatro estados del corpus cableados (sealed/debt/never/unhashable) y
contaba TODOS los nodos contra ese diccionario. `build-state.py` emite dos más —`wanted` (hueco
declarado en targets.toml, sin receta) y `ajeno` (imagen de qorpa, que no se construye desde
fuente)—, así que el visor moría con `KeyError: 'ajeno'` y el tablero HTML llevaba sin poder
generarse. O sea: agregar un estado nuevo rompía el tablero entero, en silencio para quien no lo
corriera.
Ahora los de fuera del corpus se cuentan aparte y se NOMBRAN en la leyenda —no se cuelan a la barra,
que es sobre `totals["recipes"]` y pasaría del 100 %—, y cualquier estado que aparezca mañana cae en
esa misma rama en vez de tumbar el visor.
De paso, el grafo regenerado: 930 selladas, 2 en deuda, 5 nunca, 3 ajenas; git ya figura sellado en
su hash nuevo (b3:215742cb…) y no arrastró a nadie, como decía el radio.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
El §6.50 quinquies dejó la caja trayendo fuentes por SSH porque su git no tenía remote-https. Eso era
el síntoma; la causa estaba un paso antes de donde mirábamos —incluida la nota que yo mismo había
escrito, que culpaba al Makefile—: el `configure` de git prueba libcurl con AC_CHECK_LIB, que enlaza
`conftest.c -lcurl` y nada más, y con libcurl estática faltan sus privadas (-lssl -lcrypto -lz).
El test falla, config.mak.autogen se lleva NO_CURL=YesPlease, el Makefile excluye los tres helpers y
conserva git-http-backend —esa asimetría en el artefacto era la firma, y estuvo a la vista desde el
14 de septiembre—. El build termina en verde.
Medido sobre el artefacto: b3:215742cb… trae git-remote-http, -https, git-http-fetch y los ftp, y
CLONA por HTTPS (clone, no ls-remote). En la caja, hidratado y con la reescritura apagada, funcionan
tanto `git clone` como `git clone --mirror`, que es el comando exacto del fetch de takana.
Y el radio, medido en vez de temido: la nota vieja decía «raíz de perfil.base ⇒ radio grande»;
`yupana radio git` dice cero dependientes directos y cero transitivos. El miedo escrito a mano había
sobrestimado el costo de arreglarlo, y eso lo mantuvo roto tres días.
Las reescrituras url.insteadOf quedan retiradas de la caja; el guion se conserva como salida de
emergencia y así lo dice su cabecera.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
El git sellado no traía `git-remote-http` —ni `-https`, ni `git-http-fetch`— pese a tener `curl` en
[deps], y el artefacto mostraba la forma exacta que deja el Makefile cuando NO_CURL está puesto:
`git-http-backend` (el lado servidor, que no usa curl) presente y los tres helpers ausentes.
La causa estaba un paso antes. El tarball de git trae `configure` y takana lo corre; su
`AC_CHECK_LIB` enlaza `conftest.c -lcurl` y nada más, y con libcurl ESTÁTICA eso no resuelve: le
faltan `-lssl -lcrypto -lz`, que son sus privadas. El test falla en silencio, `config.mak.autogen` se
lleva `NO_CURL=YesPlease` y el build TERMINA EN VERDE sellando un git mutilado:
checking for SHA1_Init in -lcrypto... yes
checking for curl_global_init in -lcurl... no ← acá
checking for XML_ParserCreate in -lexpat... no
La cura son tres líneas: `LIBS="$(curl-config --libs)"` al configure (sale de curl-config, no escrito
a mano: si curl gana privadas mañana, las trae solo), `NO_EXPAT=1` porque con curl encendido el
Makefile agrega http-push.o y expat no está en deps, y un GUARDIÁN que corta si `config.mak.autogen`
quedó con NO_CURL=YesPlease — el modo de fallo es silencioso, así que se comprueba el HECHO.
Medido sobre el artefacto, no sobre el git del host: b3:215742cb… trae git-remote-http,
git-remote-https, git-http-fetch y los ftp; y CLONA por HTTPS de verdad —clone, no ls-remote, que es
donde murió la vez del ubsan—: árbol en disco y rev-list contesta.
Radio, medido con yupana: git tiene CERO dependientes transitivos ⇒ el re-sello no arrastra ninguna
reconstrucción. Toca las 7 imágenes que lo incluyen, que es otra cosa.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
puriy-costura era la única de las 36 que NO estaba en el store de la caja —o sea, un fallo de caché
de verdad, no un cache-hit disfrazado de éxito—. La caja la hizo entera y sola: clonó por SSH
(111,7 M de mirror), vendoreó, compiló y selló.
El hash que predice el hub y el que selló la caja son IDÉNTICOS
(b3:7d63655aa5fea3cbc08724887617d7f58b325fcb2e00ac050b1937966c2459e6), que es lo único que prueba que
el transporte no contamina el artefacto; 2,2 M con contenido y el binario corre.
Con esto la caja cumple la condición que puso el usuario para poder borrar gioser —«con capacidad de
compilar tawasuyu y las recetas de takana»— desde FUENTE y por su cuenta, no por artefactos que le
llegan del worker. Los dos negativos del guion también están probados: un repo inexistente lo hace
fallar, y una huella cambiada la rechaza.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Lo que hasta ahora era estado a mano en la caja queda reproducible. Hace las cinco piezas medidas:
reescritura de URLs con url.insteadOf, la clave del host reexpresada SIN puerto (cargo la busca así),
la huella de github.com PINEADA contra la publicada —si no coincide, sale con error en vez de
aceptarla—, la IdentityFile por host, y `net.git-fetch-with-cli = true` para que cargo delegue en el
git de verdad. Además mueve CARGO_HOME fuera de la raíz de 5,9 G, que es lo que tiró la caja.
No mueve ningún hash: la URL es un localizador y no entra en hash_inputs (ADR 0013). Termina con un
control que CLONA de los dos orígenes; si alguno no llega, sale distinto de cero.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
La caja no tiene git-remote-http, así que las 36 recetas que clonan de git.tawasuyu.net y las ~90 de
GitHub no se podían construir ahí. La salida es usar SSH, y sale gratis en hashes porque la URL es un
LOCALIZADOR y no entra en hash_inputs (ADR 0013): mismo commit por otro transporte, mismo artefacto.
No se toca ninguna receta —el worker sigue por HTTPS— sino la caja, con dos `url.insteadOf`.
Tres cosas medidas: (1) cargo vendor clona aparte y con su propio cliente ssh —se plantó por la clave
del host, que la tenía con puerto y cargo la busca sin él, y después por autenticación— y se resuelve
con `net.git-fetch-with-cli = true`; (2) la huella de github.com se PINEA contra la publicada, no se
acepta a ciegas; (3) CARGO_HOME estaba en /root/.cargo, o sea en la raíz de 5,9 G: el vendor bajó
2,7 G, la raíz llegó al 100 % y la caja NO se degradó, se cayó entera —sin HTTP, sin SSH y sin
responder al ping, con Hetzner informando «running»—. Rescate otra vez.
Rastro que deja un ENOSPC y que conviene saber leer: caddy escupiendo «no space left on device», y
mis propios `>>` dejando 105 bytes NULOS al final de /root/.ssh/config —un append que falla por
ENOSPC no deja el fichero como estaba: lo deja extendido y relleno de ceros—.
Reparado en el rescate y permanente: /root/.cargo → /work/cargo-home, poda horaria de logs
(ente-gitea.log había llegado SOLO a 114 M y nadie lo rotaba) y los dos configs reescritos. Tras el
arranque: raíz al 54 %, 18 entes corriendo, los 7 dominios de la caja en 200.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
`install-tawasuyu.sh` y `actualizar-servidor.sh` existen y siguen ahí (el monorepo está clonado en
/work/sergio/tawasuyu), pero lo que hacen es `cargo build --release` + `install -m755` a
/usr/local/bin: producen exactamente la clase de binario que la mudanza encontró irreproducible —2,7
G de sueltos que nadie provee, tres de ellos corriendo desde un inodo BORRADO— y además escriben
servicios en /etc/init.d/, que en esta caja no existe.
La forma de acá, hecha de punta a punta con shuma-tui: receta pinneada ⇒ `takana build` ⇒ sellado
b3:f795ee0f… ⇒ el artefacto viaja por rsync ⇒ symlink desde el store ⇒ `shuma-tui --help` contesta.
El camino completo es el del §6.46 (repo firmado + `takana install --require-signed`), que es lo que
convierte «copiar un binario» en «instalar un paquete».
⚠ Y el límite de hoy: el build NO se puede hacer en la caja para recetas que clonan por HTTPS,
porque su git no tiene remote-https. Las que bajan tarballs con curl sí construyen ahí (hoy sellaron
intel-ucode y sof-firmware); las de tawasuyu se construyen en el worker. Arreglarlo es re-sellar
`git` con libcurl, raíz de perfil.base: unidad propia.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Responde a «¿cómo instalo shuma-tui?». En gioser se instalaba con `actualizar-servidor.sh`:
cargo build --release + install -m755 a /usr/local/bin. Eso deja un BINARIO SUELTO QUE NADIE PROVEE
— la clase que la mudanza encontró irreproducible (2,7 G de ellos, §6.35).
Acá el camino del corpus: receta pineada ⇒ takana build ⇒ artefacto sellado por hash ⇒ se instala
desde el store o desde el repo firmado. El binario de mañana se puede volver a fabricar bit a bit; el
de install -m755, no.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
sudo no andaba por DOS cosas a la vez, y una era el corte de energía: /usr/bin/sudo no tenía el bit
setuid, y /etc/sudoers.d/sergio HABÍA DESAPARECIDO — lo escribí minutos antes del reset del §6.51 y
se fue con el mismo corte que dejó el cortafuegos en NULs. Repuestos los dos, con sync, `sudo id`
devuelve uid=0. `visudo` no está instalado y no hace falta: el drop-in en /etc/sudoers.d/ es la forma
correcta. (doas sigue dando «Operation not permitted» aun setuid; queda como rareza sin explicar.)
LOS REPOSITORIOS ESTÁN EN LA CAJA: los 44 en el gitea mudado el 14-sep (sergio 939 M, tawasuyu
547 M). Lo que faltaba era un CLON DE TRABAJO: sólo estaba /opt/takana, el del hub. Ahora
`~/src → /work/sergio` con tawasuyu clonado (478 M) y su origin al gitea de la caja.
⚠ El taller va en /work y no en el home: la raíz tiene 2,4 G libres y /work 43 G.
⚠ Y clonar acá tiene dos trampas medidas: el git del corpus NO tiene remote-https (no se puede
clonar por HTTPS), y clonar por SSH exige la llave registrada en la CUENTA de gitea, no en el
authorized_keys del sistema. Mientras tanto se clona por ruta del sistema de ficheros, como root
(los dirs de organización son 0700 de gitea) y con `safe.directory`.
`PROY=/work/sergio/tawasuyu claude` abre el agente sobre ese repo — comprobado.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
El primer `ssh -i ~/.ssh/tawasuyu sergio@gioser.net -p 2345` dio «Permission denied (publickey)», y
era exacto: el sshd de la caja tiene `PasswordAuthentication no`, así que la clave sirve para `su` y
la consola, no para SSH. Faltaba `~/.ssh/authorized_keys`, que se creó vacío con la cuenta. Copiadas
las dos llaves de gioser (`tawasuyu` y `sergio@tatata`), entra — y `claude` abre en la misma sesión.
Dos detalles que hacen que se sienta como la máquina de siempre: `gioser.net` ya resuelve a la caja,
y la llave de host es LA MISMA que la de gioser (se copiaron en el cutover del gitea, §6.25),
comprobado: SHA256:ltSl+rgr2Uc… en las dos. Por eso no salta el aviso de «REMOTE HOST IDENTIFICATION
HAS CHANGED» al entrar al nombre de siempre.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Crear una cuenta tiró el servidor. Ninguna de las tres causas era la que parecía:
1. La caja NUNCA tuvo /etc/shadow. Crearlo con todas las cuentas bloqueadas (!) hizo que sshd
RECHAZARA LA LLAVE de root: este sshd no acepta login por llave de una cuenta bloqueada. La forma
correcta acá es la vieja — el hash en el campo 2 de /etc/passwd, sin shadow.
2. La caja NO reinicia por ACPI: `hcloud server reboot` no hizo nada (arje-zero no atiende la señal).
La única forma de reiniciarla desde fuera es `reset`, que es un corte de energía.
3. Y ese corte dejó el reglaset del cortafuegos a MEDIO ESCRIBIR — 5 KB de NULs: ext4 journaló el
tamaño y los datos nunca llegaron al disco. Un fichero medio escrito con `policy drop` y sin los
`accept` es exactamente una caja que arranca, corre todo y no deja entrar a nadie.
⇒ después de escribir algo que el arranque necesita, `sync` ANTES de cualquier reset.
Lo que el rodeo destapó y vale más que el susto:
· EL CORTAFUEGOS NO SE APLICABA EN NINGÚN ARRANQUE (su card sale 78 si nft -c falla, y con el
fichero corrupto fallaba siempre): la caja llevaba días arrancando SIN FILTRAR, en silencio.
Reparado, el arranque ya deja 21 reglas dport, comprobado tras reiniciar.
· netup es DHCP-only y falló dos veces; se le añadió al init una IP estática de respaldo con la
forma de Hetzner (/32 + puerta scope link)… que no corría, porque su guarda miraba /sys y el init
NO MONTA /sys. El diagnóstico que lo probó hubo que escribirlo a FICHERO: sin red, el log tiene
que estar en el disco.
· el mapa real de particiones: sda2 root · sda3 state · sda4 work · sdb store.
El costo, sin adornos: ~20 minutos de caída de los ocho dominios y tres resets duros, uno de ellos
disparado por mí a los 400 s mientras la caja estaba haciendo su trabajo. En esta caja cada
diagnóstico remoto cuesta un ciclo de 6-8 minutos: el primero conviene gastarlo en dejar evidencia
en disco, no en probar una corazonada.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Pedido: «crea mi cuenta sergio con la clave tawasuyu, desde ahí abrir los claudes como lo estoy
haciendo acá con shuma sobre los proyectos».
· cuenta `sergio` uid 1001 (el mismo que en gioser), home /home/sergio, clave verificada
· su propia jaula `claude-sergio`, que concede SU home —su `.claude`: credenciales y memoria— y
NO el de root. Con la instancia de root, sergio moría en «bwrap: Can't mkdir /root/.claude»
· `claude` elige instancia por usuario; `PROY=/otra/ruta claude` abre el agente sobre otro proyecto
· shuma-daemon y shuma-gateway pasan a correr como `sergio`, no como la cuenta de servicio `shuma`:
shuma es su CONSOLA, y cada pestaña que abre tiene que ser una sesión suya — si no, `claude`
buscaría una jaula `claude-shuma` que no existe
⚠ NO se eleva con doas/sudo: en esta caja el setuid NO TOMA («doas: Operation not permitted», con
NoNewPrivs 0 y `/` sin nosuid — queda como deuda entender por qué). No hace falta: `qorpa run`
levanta la jaula con user namespaces y anda sin privilegio, siempre que el directorio de la
instancia sea del usuario.
⚠ Y un detalle que costó una vuelta: sin `shift 2`, el HOME y el proyecto que el lanzador pasa como
posicionales se cuelan COMO ARGUMENTOS del agente — la primera sesión se abrió con el prompt
«/home/sergio», y el agente contestó, con razón, que eso es una ruta y no un comando.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
La memoria se indexa por ruta de trabajo. `qorpa run` deja el shell en `/`, así que las primeras
pruebas usaron el proyecto `-` y el agente arrancaba en blanco aunque sus 163 ficheros estuvieran en
disco. Con `cd /opt/takana` usa `-opt-takana`, que es donde se renombró la memoria traída de gioser
(allá el repo era /mnt/vvv/takana).
Comprobado en la caja, con dos preguntas que sólo puede contestar leyendo:
¿el logo? → «martillo 7×7, cuatro colores exactos» (está en su memoria)
¿la regla 1? → «todo takana build va envuelto en flock, y con -o», con el matiz del lock heredado
O sea: el agente de la caja arranca sabiendo lo que sabe éste.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
$ claude -p "Decí exactamente: CLAUDE CORRIENDO EN LA CAJA"
CLAUDE CORRIENDO EN LA CAJA
Turno real —API, credenciales, respuesta— desde 2.29.29.217. El CLI es un ELF glibc de 360 M y la
caja es musl, así que va enjaulado (ADR 0015, el caso de sergioh-api). La instancia declara red,
nesting y SEIS directorios: /opt/takana, /work/dev-fs, /store, /root/.claude, /root/.ssh (ro) y el
CLI (ro). Es ANCHA y está dicho: un agente que construye, commitea y empuja necesita lo mismo que un
humano; lo que la jaula compra es que el alcance esté escrito y acotado.
⚠ El `takana` que construye NO se instala adentro: sale del store, que ya está concedido — es
estático musl y corre igual dentro de una imagen glibc.
LA CAJA CONSTRUYE: sellados hoy `intel-ucode` (156 signatures) y `sof-firmware` (2 firmware + 8
topologías). Faltaba una pieza que el lab no traía: `.dev-fs/tools` (zig 0.13/0.16 y go, 1 G) — la
imagen del lab empaqueta `alpine/` y nada más, y el primer intento murió con «zig no encontrado».
🧱 Y lo que NO anda, con su rodeo: `takana build` dentro de la jaula muere con «bwrap: Can't mount
proc on /proc» aunque `nesting = true`. No es el anidamiento —un `bwrap --proc /proc` a mano SÍ
funciona adentro— sino el userns anidado del sandbox del build; probado también con `root = false`,
que es la sospecha que el propio código documenta, y falla igual. El rodeo que sí anda, escrito en el
lanzador: pedirle el build al ANFITRIÓN por ssh a 127.0.0.1:22022. Así se selló sof-firmware desde
dentro de la jaula.
Manifiesto y lanzador versionados en scripts/servidor/: una instancia que sólo existe en la caja se
pierde con la caja.
⚠ Pendiente menor: la memoria del agente está en `-mnt-vvv-takana` y allá el repo vive en
/opt/takana ⇒ el índice POR RUTA no coincide y arranca sin memoria del proyecto aunque los 733
ficheros estén en disco.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Con las ocho puertas en verde no queda trabajo técnico: queda decidir. La hoja
(`docs/state/mudanza-decisiones-pendientes.txt`) trae 150 entradas y 31,9 G, ordenadas por tamaño,
con la sugerencia entre corchetes cuando hay un HECHO que la respalde y en blanco cuando sólo lo
sabe el dueño. Se aplica en una pasada con `planear.py --decidir`, sin teclas unitarias.
Y el último rescate antes de cerrar: `/mnt/vvv/gioserv` tenía 26 entradas sin commitear y su remoto
era una RUTA LOCAL de la máquina que se borra. Lo commiteado está a salvo (su HEAD es el mismo que
el del gitea nuevo); lo que no estaba en ningún lado —el diff completo, con `api/main.py` +92/−23, y
los 4 no rastreados— quedó en takana:/work/mudanza-secretos/gioserv-pendiente/, verificado con 0
ficheros faltantes. No reapunté el remoto ni commiteé nada: eso es del dueño del repo.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Con las ocho puertas en verde, lo único que queda de la mudanza son decisiones sobre datos. Esta
hoja las junta todas, ordenadas por tamaño, con lo que la herramienta se anima a sugerir POR UN
HECHO entre corchetes (servido / usado por un proceso vivo / caché / repo limpio con remoto) y en
blanco lo que sólo sabe el dueño.
Se decide editando el fichero y aplicando en una pasada:
python3 scripts/mudanza/planear.py --censo work/mudanza/censo-detalle.toml \
--decidir docs/state/mudanza-decisiones-pendientes.txt --target root@2.29.29.217
⚠ Y dice qué NO cubre, porque una hoja titulada «lo que falta» que omite 329 G se lee mal: no están
`/mnt/vvv` (monorepo, repo, store, rustup — el store ya está respaldado y los repos viven en el gitea
de la caja) ni los servicios y dominios, que ya están decididos y ejecutados.
Va a `docs/state/` y no a `work/`, que está en .gitignore: el fichero donde el usuario decide no
puede vivir sólo en la máquina que la mudanza borra.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
respaldados (manifiesto del Storage Box): 3686
en el store de la caja: 1320
de la caja, NO respaldados: 0 ← la cuenta que decide
errores y reintentos: 0 y 0
Pero la primera corrida no terminó, y el motivo vale por sí solo: se cayó 40 veces con el MISMO
fichero porque una transferencia interrumpida el 11-sep había dejado un parcial en el destino con el
modo del origen (-r--r--r--, el store es de sólo lectura por diseño). Ningún intento posterior puede
reescribirlo: esa ruta quedaba envenenada PARA SIEMPRE, y el bucle la golpeaba cada 60 s llamándola
«corte de red». Arreglado con --chmod=Fu+w (un corte a mitad se retoma) y dando al rsync 23 tres
intentos en vez de cuarenta, nombrando la causa probable al tercero.
🪤 Y dos veces el mismo error mío en la misma tarde: `pgrep -f <patrón>` SE ENCUENTRA A SÍ MISMO —el
patrón está en la línea de comando del propio pgrep y del ssh que lo lanza—, así que «sigue
corriendo» era verdad para siempre y el vigía que armé con esa condición nunca podía dispararse. La
forma correcta es el truco del corchete: `grep "[r]espaldo-storagebox"`. Hermano del `pkill -f` que
mata tu propia shell.
Lo que separa esto del borrado de gioser ya no es técnico: es la decisión del usuario, a mano y
nunca por automatización.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
El guión avisaba en cada corrida de que el commit se había perdido, iba a recuperarlo, y el
cherry-pick le contestaba que el contenido ya estaba. Un guardián que grita siempre se ignora, así
que valía la pena encontrar por qué.
No era git: era la comprobación. El guión corre con `set -o pipefail` y comprobaba con
`git log … | grep -qF "$MSG"`. **`grep -q` sale en cuanto encuentra**, eso le manda SIGPIPE a
`git log`, que termina ≠0, y con `pipefail` la tubería entera se lee como FALLO **aunque el grep haya
encontrado**. Demostrado en una línea:
$ bash -c 'set -o pipefail; seq 1 100000 | grep -q "^5$" && echo OK || echo FALLO'
FALLO
Arreglado capturando la salida antes de comparar: sin tubería, sin SIGPIPE, sin falso positivo.
⇒ Y de paso desmiente lo que el propio guión daba por hecho: de las cinco «pérdidas» de commit que
motivaron escribirlo, al menos las últimas dos fueron ESTE falso positivo, no el rebase. Las
primeras sí están en el reflog con su `(start)`/`(finish)` sin `pick`.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
La primera corrida completa desde la caja (puerta 7) se cayó 40 veces seguidas con el MISMO fichero:
open ".../fonts/dejavu/.rsync-partial/DejaVuSans-Oblique.ttf" failed: No such file… (2)
.. store: corte de red (rsync 23). Intento 39; reanudo en 60s.
!! store: 40 intentos y sigue cayéndose. Dejo lo subido y paro.
No era red. Una transferencia interrumpida el 11-sep dejó ese PARCIAL en el destino con modo
-r--r--r-- (el del origen: el store es de sólo lectura por diseño), y ningún intento posterior puede
reescribirlo. El fallo es ETERNO, y el bucle reintentaba cada 60 s contra esa pared — exactamente lo
que la cabecera de la función de reintento dice que no hay que hacer.
Dos arreglos:
1. `--chmod=Fu+w`: los ficheros del respaldo quedan escribibles por su dueño, así que un corte a
mitad se RETOMA en vez de trabarse. El precio es no conservar el bit de sólo-lectura en la copia;
es bajo: el contenido es lo que se respalda y los permisos los reconstruye el store.
2. Al rsync 23 se le dan TRES intentos, no cuarenta, y al tercero se NOMBRA la causa probable (un
parcial de sólo lectura en el destino) en vez de llamarlo corte de red. El 23 es «some files were
not transferred», que tanto puede ser un cable como una pared.
Comprobado: borrado el parcial envenenado, ese fichero sube a la primera.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2 store entero ✅ 1320 artefactos, 0 vacíos, /store al 62 % tras el gc
4 la granja late allá ✅ §6.43 — con el lab pineado, y la caja gana por uno en los dos grafos
5 el host se instala de su repo ✅ §6.46 — 171 publicados, install --require-signed en verde
7 el respaldo desde la caja ⏳ primera corrida completa en marcha
1,3,6,8 ✅
Lo que separa esto del borrado de gioser ya no es técnico: es la corrida de respaldo terminando y la
decisión del usuario — a mano, con las ocho en verde, nunca por automatización. Y lo que queda vivo
en gioser es trabajo de la mudanza, no servicios: los ~10 G de árboles personales sin decidir.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Estrenando el guión con su propio commit saltó el caso: la comprobación por mensaje dio negativo,
el cherry-pick de recuperación salió con «the previous cherry-pick is now empty» y el guión abortó
con error… teniendo el contenido ya en el árbol.
Ahora distingue los dos casos: vacío ⇒ falso positivo de la comprobación, se aborta el cherry-pick y
se sigue; cualquier otro error ⇒ se aborta, se imprime el reflog y se sale ≠0 para que lo mire un
humano. Lo que importa es que el CONTENIDO esté, no que el sha coincida.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
En dos días, `git pull --rebase` se llevó por delante CINCO commits propios en este árbol
compartido, siempre con el mismo reflog: `commit:` mío, `(start): checkout <otro>`, `(finish):
returning to main`, y ni un `pick` en el medio. El comando no es el culpable —en un repo de juguete
reaplica bien— sino que alguien mueve `refs/heads/main` mientras el rebase está en vuelo.
La receta manual (CLAUDE.md regla 2 ter) funciona: mirar el log y recuperar con reflog +
cherry-pick. Esto es esa receta automatizada, porque **una regla que hay que acordarse de aplicar en
cada push es una regla que un día no se aplica**.
Hace, en orden: anota su HEAD · rebasa · COMPRUEBA que el commit sigue en la rama —por su mensaje,
no por el sha, que el rebase reescribe— · si no está lo recupera del reflog · empuja · verifica que
gitea quedó donde tiene que quedar · y si el espejo de GitHub quedó divergente lo realinea con
`--force-with-lease` (nunca `--force` a secas) y sólo tras comprobar que su contenido ya está en
nuestra historia.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Estaba a medias desde el §5.4 por el lab. Con el lab instalado (§6.43), cerrada en dos movimientos,
los dos en la caja:
publicar: 171 paquetes con expected_hash anclado, 3 sin ancla, índice verificado contra ./trust,
firmado con la clave de release que se mudó el 16-sep. Falló uno: os-release.
instalar: `takana install duf --require-signed --trust ./trust` ⇒ «release: trusted (by release)»,
deps resueltas, apply OK, registrado. Bajo --prefix y --db propios, sin tocar el sistema.
⚠ El matiz honesto vale más que el verde: el artefacto YA ESTABA en el store, así que se ejercitó
resolver + verificar firma + hidratar, NO reproducir desde fuente. Lo que el lab destrabó y sí quedó
probado aparte es el HASH (§6.43, cuatro de cuatro iguales a gioser), que es donde moría antes. Queda
sin ejercitar «paquete que no está en el store» — y en una caja de producción es discutible que se
quiera: un servidor no tiene por qué compilar.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
El paso de poda del latido moría con `/dev/fd/63: No such file or directory` y un `viejos: unbound
variable` de consecuencia. La causa no era el script: la sustitución de procesos de bash necesita
/dev/fd y UNA CAJA TAKANA NO LO TIENE (gioser sí). O sea que ningún `<(...)` de ningún script del hub
funcionaba allá; éste fue el primero en toparse.
Arreglado en los dos lados: /dev/fd -> /proc/self/fd en la caja con Card OneShot en el genesis
(comprobado: `cat <(echo funciona)` responde), y en el script fuera `<(...)` y fuera `df -B1
--output=avail`, que es GNU — sin eso corría pero decía «libres 0.0 G», y un 0 se lee como disco
lleno.
Resultado: 2 árboles podados, 5,4 G. Con el store-gc del §6.44 son 32,2 G recuperados hoy en la
caja: /store al 62 %, /work al 29 %.
⇒ Van dos parches con forma de Card OneShot para cosas que debería hacer el init (hostname y ahora
/dev/fd). Es una lista que conviene no alargar.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
El latido, corrido desde la caja, moría así:
poda-fuentes.sh: line 72: /dev/fd/63: No such file or directory
poda-fuentes.sh: line 73: viejos: unbound variable
⚠ poda de fuentes falló (rc=1) — sigo
El segundo error es consecuencia del primero (el `mapfile` nunca corrió), y el primero no nombra la
causa: **la sustitución de procesos de bash necesita `/dev/fd`, y una caja takana no lo tiene**.
gioser sí: `/dev/fd -> /proc/self/fd`. O sea que NINGÚN `<(...)` de NINGÚN script del hub funcionaba
allá — esto era sólo el primero en toparse.
Dos arreglos, y los dos hacían falta:
1. En el script: `<(...)` fuera (fichero temporal, que anda en cualquier shell y con cualquier /dev)
y `df -B1 --output=avail`, que es GNU, por `df -k` + awk. Es la poda de `work/sources`, justo lo
que un hub necesita para no llenarse.
2. En la caja: `/dev/fd -> /proc/self/fd`, con una Card OneShot en el genesis para que sobreviva al
reinicio (como la de `hostname`). Comprobado después: `bash -c "cat <(echo funciona)"` responde.
Lo correcto a futuro es que lo haga el init o el product-rootfs, no una Card — queda anotado.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
