sergio/takana

Tres veces hizo falta el log del kernel de la maquina del operador para diagnosticar el wifi, y las
tres veces el unico que habia era un /dmesg.log del 12-oct escrito a mano. `hammerd` no recoge el
klog —es el watcher de ficheros y el diario de mutaciones— asi que cuando la maquina se apaga el
arranque se pierde entero, y «el firmware no carga» no se puede diagnosticar sin ver que pidio el
kernel y que contesto el loader.

Hoy eso costo una conclusion falsa evitada por poco: el dmesg disponible mostraba
«Direct firmware load for iwlwifi-QuZ-a0-hr-b0-77.ucode failed» y era del 12-oct, DOS DIAS ANTES de
que el firmware se pusiera. Verificado aparte: el blob esta integro y con el mismo sha256 en los
tres sitios (la artix de origen, /lib/firmware de la raiz y el initramfs del ESP).

Espera 20 s antes de volcar: el .ucode del wifi se pide a los 0,49 s, pero un USB enchufado o un
driver lento aparecen despues y un volcado inmediato los perderia. Guarda el arranque ANTERIOR
(el sintoma casi siempre se compara con «antes andaba»), y al dmesg le agrega `ip -br link`, el
filtro de lo que el loader pidio, y el listado de /lib/firmware que la raiz ofrece — las tres
preguntas que uno hace justo despues de leer el dmesg.

Se instala como Ente de arje (exec /bin/busybox sh …) y termina en `exec sleep`, porque un Ente que
TERMINA lo reinicia arje en bucle. Puesto en la maquina del operador con su ULID y validado con
`arje-zero --attest-check` — que rechazo el primer intento porque mi ULID llevaba I, O y U, que
Crockford base32 no admite: esa guarda evito dejar una semilla ilegible, o sea una maquina que no
arranca.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

diff --git a/scripts/bitacora-arranque.sh b/scripts/bitacora-arranque.sh
new file mode 100755
index 00000000..898ad214
--- /dev/null
+++ b/scripts/bitacora-arranque.sh
@@ -0,0 +1,35 @@
+#!/bin/sh
+# bitacora-arranque.sh — el dmesg de CADA arranque, en disco.
+#
+# ── Por qué existe ───────────────────────────────────────────────────────────────────────────────
+# Tres veces hizo falta el log del kernel de esta máquina para diagnosticar el wifi, y las tres
+# veces el único que había era un `/dmesg.log` del 2026-10-12 escrito a mano. `hammerd` no recoge el
+# klog (es un watcher de ficheros y el diario de mutaciones), así que cuando la máquina se apaga el
+# arranque se pierde entero — y «el firmware no carga» no se puede diagnosticar sin ver qué pidió el
+# kernel y qué contestó el loader.
+#
+# Espera a que el kernel haya terminado de probar el hardware: el `.ucode` del wifi se pide a los
+# 0,49 s, pero un USB enchufado o un módulo lento aparecen más tarde, y un volcado inmediato los
+# perdería. Veinte segundos cubren un arranque normal con margen.
+#
+# Y guarda el arranque ANTERIOR: el síntoma casi siempre se compara con «antes andaba».
+set -u
+sleep 20
+mkdir -p /var/log
+[ -f /var/log/dmesg-arranque.log ] && mv -f /var/log/dmesg-arranque.log /var/log/dmesg-arranque.log.1
+{
+	echo "=== dmesg · $(date -u '+%Y-%m-%dT%H:%M:%SZ') · uptime $(cut -d. -f1 /proc/uptime 2>/dev/null)s ==="
+	dmesg 2>&1
+	echo
+	echo "=== interfaces de red (ip -br link) ==="
+	ip -br link 2>&1 || echo "(sin ip)"
+	echo
+	echo "=== lo que el loader de firmware pidió y no encontró ==="
+	dmesg 2>/dev/null | grep -iE "firmware|ucode" || echo "(nada sobre firmware: o cargó todo, o el driver no pidió)"
+	echo
+	echo "=== /lib/firmware que la raíz ofrece ==="
+	ls -1 /lib/firmware 2>&1 | head -40
+} > /var/log/dmesg-arranque.log 2>&1
+chmod 644 /var/log/dmesg-arranque.log
+# Un Ente que termina lo reinicia arje en bucle: se queda quieto después de hacer su trabajo.
+exec sleep 2147483647