Files
takana/docs/state
sergioandClaude Opus 5 11a9ead671 perfiles: metal-tigerlake es una CAPA DE HARDWARE componible, no otra lista por escritorio
El SDD 27 §2 dice que el repo mezcla tres capas —piso, escritorio, extras— en una sola
lista por escritorio, y que esa es la causa de que la composición no esté definida. El
firmware es un cuarto caso que el SDD no nombra y que sigue la misma lógica: no es un
escritorio ni un toolbox, es lo que hace falta para que un METAL CONCRETO arranque con todo
su hardware vivo.

Por eso va como perfil propio y se compone, en vez de duplicarse en los cuatro escritorios:

    scripts/targets.py cli metal-tigerlake escritorio-kde

Otro metal = otro perfil de estos con su propia receta firmware-<plataforma> derivada del
mismo linux-firmware. Ese es el punto de haber partido el firmware en base + derivada.

La máquina, medida con lspci/cpuinfo sobre el metal real:

    CPU    i7-11370H · family 6 · model 140 (0x8c) · stepping 1   ⇒ intel-ucode/06-8c-01
    GPU    TigerLake-LP GT2 [Iris Xe] [8086:9a49]                 ⇒ i915 / xe
    WiFi   Intel Wi-Fi 6 AX201 [8086:a0f0]                        ⇒ iwlwifi
    Audio  500 Series HD Audio [8086:a0c8]                        ⇒ snd_sof_pci_intel_tgl

Y zsh entra en `cli`, no en `base`: base define el shell del SISTEMA (bash) y esto es el
del usuario. Dos hechos distintos, como `paquetes` y `servicios` un piso más abajo.

El runbook deja el encargo para el worker, y su parte útil son los dos muros que aparecieron
al cruzar ficheros que nadie había leído juntos:

  1. takana-live-install.sh:275 bifurca «UEFI ⇒ rama EFI-stub soberana», y metal-usb-sdboot.sh
     dice que el EFI-stub «en el firmware del usuario se cuelga tras Measured initrd PCR 9».
     ES EL MISMO FIRMWARE. El lazo de instalación EFI está validado en OVMF, que no tiene ese
     quirk ⇒ el instalador va a pasar la prueba y colgarse en el metal de destino. La salida
     es llevar el instalador a systemd-boot, que es el camino ya probado en esta máquina.
  2. El instalador reparticiona en MBR el disco entero, y ese disco tiene /home con 893 G
     usados. Si la instalación conserva /home o se lleva el disco con respaldo previo es
     decisión del usuario, no del runbook — y hasta que se decida, no correrlo sobre el NVMe.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-16 15:12:29 -04:00
..