Files
takana/scripts/boot-builder-vm.sh
Sergio 476168bb07 takana etapa 5c: comentarios de scripts, MOTD, y un BUG que introdujo la etapa 4
250 líneas de comentario en 151 scripts. Control verificado: el diff no toca
NI UNA línea que no empiece por #, y la sintaxis de los 151 pasa.

El barrido saltea heredocs y cadenas triples, y el guardián DISPARÓ 3 veces:
las tres eran el MOTD que el script escribe DENTRO de la imagen construida —
texto del producto, no comentario del script. Se cambiaron aparte y a
propósito, que es rebranding, no limpieza.

Y el hallazgo caro:  casaba contra ,
que es el TARGET de tracing — o sea el module_path!, o sea el nombre del crate.
La etapa 4 lo movió a  y el script quedó casando NADA. No fallaba:
imprimía cero atribuciones, indistinguible de un log sin problemas. Comprobado
con el binario (RUST_LOG=info sobre zlib), no deducido. Ahora acepta las dos, y
tiene que seguir aceptándolas porque los logs viejos en disco dicen la vieja.

Además 14 rutas de módulo  en docs, que el barrido anterior no tocó
porque  no es frontera de palabra.
2026-09-09 19:28:48 +00:00

69 lines
2.8 KiB
Bash
Executable File

#!/usr/bin/env bash
# boot-builder-vm.sh — Bootea el builder rootfs (Stage 1 + toolchain) en QEMU para correr el
# rebuild in-rootfs (auto-alojamiento, SDD 11 §7; runbook §8c).
#
# El builder se arma con `takana bootstrap builder … --out work/builder-rootfs` y se empaqueta como
# initramfs (cpio newc + gzip). Aquí lo booteamos con arje-zero como PID 1: levanta hammerd + una
# getty en consola y deja una shell. Desde ahí se corre el driver embebido:
#
# rebuild-stage1
#
# que reconstruye stage1' con el toolchain de adentro y compara su content-hash con la referencia
# (REF_CONTENT en /etc/hammer/rebuild.env) → ✓ REPRODUCIBLE / ✗ DIVERGENTE.
#
# Variables (override por entorno):
# INITRAMFS cpio.gz del builder (default work/builder.cpio.gz)
# KERNEL bzImage/vmlinuz a bootear (default /boot/vmlinuz-linux)
# MEM RAM de la VM en MiB (default 6144; el rootfs vive en RAM + espacio de build)
# CPU modelo de CPU de QEMU (default Broadwell; AVX2 bajo TCG, sin -cpu host sin KVM)
# KVM 1 ⇒ usa -enable-kvm -cpu host si hay /dev/kvm (mucho más rápido)
#
# RAM: el initramfs se desempaqueta a un tmpfs (~1.2 GB) y el rebuild Rust (arje-zero vendorea un
# monorepo) necesita varios GB más, TODO en RAM. Con un host de ~7 GB y sin KVM esto va justo y lento
# (TCG). Si el rebuild muere por OOM, sube MEM (y/o monta un disco para /work en vez de tmpfs).
#
# Uso:
# ./scripts/boot-builder-vm.sh
# MEM=12288 KVM=1 ./scripts/boot-builder-vm.sh
set -euo pipefail
REPO_ROOT="$(cd "$(dirname "$0")/.." && pwd)"
INITRAMFS="${INITRAMFS:-$REPO_ROOT/work/builder.cpio.gz}"
KERNEL="${KERNEL:-/boot/vmlinuz-linux}"
MEM="${MEM:-6144}"
CPU="${CPU:-Broadwell}"
KVM="${KVM:-0}"
[[ -f "$INITRAMFS" ]] || { echo "no existe el initramfs: $INITRAMFS (arma el builder y empaquétalo)" >&2; exit 1; }
[[ -r "$KERNEL" ]] || { echo "no puedo leer el kernel: $KERNEL (set KERNEL=…)" >&2; exit 1; }
accel=()
if [[ "$KVM" == "1" && -w /dev/kvm ]]; then
accel=(-enable-kvm -cpu host)
echo "==> KVM activo (-cpu host)"
else
accel=(-cpu "$CPU")
echo "==> TCG (sin KVM); -cpu $CPU por AVX2. Lento — el rebuild Rust puede tardar."
fi
echo "==> kernel : $KERNEL"
echo "==> initramfs : $INITRAMFS ($(du -h "$INITRAMFS" | cut -f1))"
echo "==> mem : ${MEM} MiB"
echo "==> en la consola, tras el boot: corre rebuild-stage1"
echo
# NIC e1000 (qemu user-mode 10.0.2.0/24): el rebuild Rust hace `cargo vendor` desde crates.io ⇒
# necesita red. El builder la levanta (insmod e1000.ko + eth0 estática). NET=0 la desactiva.
net=()
[[ "${NET:-1}" == "1" ]] && net=(-netdev user,id=n0 -device e1000,netdev=n0)
exec qemu-system-x86_64 \
-m "$MEM" \
-no-reboot -nographic \
"${accel[@]}" \
"${net[@]}" \
-kernel "$KERNEL" \
-initrd "$INITRAMFS" \
-append "console=ttyS0 rdinit=/sbin/init"