ADR 0018: el arranque por vendor path, MEDIDO — el seguro se cobra

Segunda enmienda, y cierra la primera del mismo día.

El experimento: la MISMA imagen con la ruta fallback pisada con 4K de
basura, dos corridas en OVMF que difieren SÓLO en la NVRAM.

  control (NVRAM limpia) → "No bootable option or device was found",
                            cero líneas del initramfs
  prueba  (con la entrada
           que escribió takana) → BdsDxe: starting Boot0004 "takana"
     from HD(1,GPT,DA80800E-…,0x800,0x30000)/\EFI\takana\takanax64.efi

El firmware imprime el device path que decodificó: 0x800 = LBA 2048 y
0x30000 = 196608 sectores, exactamente los números que takana leyó del
GPT. No es que "arrancó": arrancó POR la entrada que escribimos, con la
fallback destruida. Es el escenario de Windows con el seguro cobrado.

La idempotencia del §2 quedó probada en condiciones reales y no en un
test: la segunda corrida dice "ya dice exactamente esto — no se
reescribe" y "BootOrder ya empieza por Boot0004 — no se toca". La NVRAM
tiene un número finito de escrituras y esto corre en cada arranque.

El parser se validó además contra las CUATRO entradas reales del
firmware (BootManagerMenuApp, EFI Firmware Setup, UEFI Misc Device, EFI
Internal Shell): un vector que nadie escribió para que pasara.

Y la dependencia efibootmgr se retira: no hizo falta.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HHAKWoBqof9XvsYCvDicEj

docs/adr/0018-soberania-del-arranque.md

@@ -1,6 +1,7 @@
 # ADR 0018 — Soberanía del arranque: convivir con otro gestor sin depender de su buena fe
 
-- **Estado:** PROPUESTO — **una decisión abierta** (§Secure Boot). El resto es implementable ya.
+- **Estado:** PROPUESTO, con **§1 y §3 IMPLEMENTADOS y verificados en OVMF** (2026-09-11).
+  Queda **una decisión abierta** (§Secure Boot) y el §2/§4 por implementar.
 - **Fecha:** 2026-09-11
 - **Frontera:** `scripts/install-image-efi.sh`, `scripts/install-image.sh`, `scripts/iso-image.sh`,
   `scripts/metal-usb-sdboot.sh`, `scripts/takana-live-install.sh`, el instalador TUI.
@@ -102,11 +103,42 @@ Hace falta algo que no dependa de haber arrancado:
 > **del host**, no en un fichero `OVMF_VARS`; no hay `virt-firmware`; este OVMF no cae al UEFI Shell,
 > así que el truco del `startup.nsh` tampoco corre).
 >
-> ⇒ **La copia en el vendor path es hoy un seguro que todavía no se puede cobrar solo.** Protege
-> contra que *pisen el fichero*, pero sólo si además existe la entrada NVRAM del §1; sin ella el
-> rescate es manual, desde el menú del firmware, en los firmwares que dejan navegar a un `.efi`
-> arbitrario. **El §3 es condición necesaria y NO suficiente: sin el §1 la mitad del seguro falta.**
-> Eso mueve la receta `efibootmgr` de «dependencia que este ADR crea» a **bloqueante del §3**.
+> ⇒ **La copia en el vendor path es un seguro que todavía no se puede cobrar solo.** Protege contra
+> que *pisen el fichero*, pero sólo si además existe la entrada NVRAM del §1. **El §3 es condición
+> necesaria y NO suficiente: sin el §1 la mitad del seguro falta.**
+>
+> **↳ CERRADO el mismo día por la enmienda de abajo.** El bloqueo se levantó, y no con `efibootmgr`.
+
+> **ENMIENDA 2026-09-11 (2ª) — el §1 está implementado y el arranque por vendor path está MEDIDO.**
+>
+> La entrada NVRAM la escribe takana, no `efibootmgr`. Se intentó primero la vía ajena y el muro se
+> midió: `efivar` 38 con musl/zig-cc choca con `secure_getenv` (no existe en musl), `sys/cdefs.h`
+> (tampoco) y `-Wl,--add-needed` (lld lo rechaza) — tres muros sólo para compilar su generador de
+> tablas, más `popt` arrastrado al sistema instalado. Lo que `efibootmgr` hace en el fondo es
+> **escribir dos ficheros** con una estructura de la spec UEFI estable desde la 2.0. Está en
+> `crates/takana-cli/src/efi_boot.rs` y se usa con `takana boot entry {list,add}`.
+>
+> **El experimento, que es lo que vale:** misma imagen de disco con la ruta fallback **pisada con
+> 4 KiB de basura**, dos corridas en OVMF que difieren **sólo** en la NVRAM.
+>
+> | corrida | NVRAM | resultado |
+> |---|---|---|
+> | control | limpia | `No bootable option or device was found` — cero líneas del initramfs |
+> | prueba | con la entrada que escribió takana | ✅ `BdsDxe: starting Boot0004 "takana" from HD(1,GPT,DA80800E-…,0x800,0x30000)/\EFI\takana\takanax64.efi` |
+>
+> El firmware imprime el device path que decodificó: `0x800` = LBA 2048 y `0x30000` = 196 608
+> sectores, **exactamente** los números que takana leyó del GPT. No es que «arrancó»: es que arrancó
+> **por la entrada que escribimos, con la fallback destruida**. Eso es el escenario de Windows con
+> el seguro cobrado.
+>
+> **Y la idempotencia del §2 quedó probada en condiciones reales**, no en un test: la segunda corrida
+> vuelve a ejecutar el reconciliador y dice «la entrada Boot0004 ya dice exactamente esto — no se
+> reescribe» y «BootOrder ya empieza por Boot0004 — no se toca». Importa más de lo que parece: la
+> NVRAM tiene un número finito de escrituras y esto está pensado para correr en cada arranque.
+>
+> De paso, el parser se validó contra **las cuatro entradas reales del firmware** (`BootManagerMenuApp`,
+> `EFI Firmware Setup`, `UEFI Misc Device`, `EFI Internal Shell`), que es un vector que nadie escribió
+> para que pasara la prueba.
 
 ### 4. El instalador mira el terreno y lo dice en voz alta
 
@@ -162,7 +194,8 @@ es neutral, es **mover el costo a la persona que instala**.
 
 ## Dependencias que este ADR crea
 
-- Recetas nuevas: `efibootmgr` (o `efivar` y hablarle a la NVRAM desde el binario de takana).
-  Si se decide firmar: `sbsigntool`, y `shim`/`mokutil` en la variante shim.
+- ~~Recetas nuevas: `efibootmgr` / `efivar`~~ — **resuelto sin dependencias nuevas**: la NVRAM la
+  escribe `takana boot entry add` (ver la 2ª enmienda). Si se decide firmar seguirá haciendo falta
+  `sbsigntool`, y `shim`/`mokutil` en la variante shim.
 - Los 5 scripts de arriba se parten en «medio removible» y «disco».
 - El instalador TUI gana el informe del terreno del §4.