# SDD 32 — El instalador de takana: la cara, los perfiles, y el orden de las preguntas

> **Estado: PARCIAL.** Lo del §2 y §7 está **implementado y medido** (2026-09-23). Lo del §3 al §6
> está **decidido y no construido**, y se dice cuál es cuál en cada sección.
> **Nace de un fallo medido en metal**, no de una idea: el §1.

## 1. Lo que pasó, que es de dónde sale todo esto

El usuario bajó el instalador, corrió `takana metal install`, le dijo que sí, y:

> *se voló todo a negro y se quedó así hasta que apagué con el botón de hardware.*

El instalador **estaba vivo del otro lado**. Lo que había pasado es que el orden era *saltá primero,
elegí después*: toda la conversación —el censo, la elección de partición, la confirmación— ocurría
**después del `kexec`**, en una máquina cuyo panel puede no volver a encenderse. Un `kexec` no
reinicia el hardware de vídeo: si el salto sale de una sesión gráfica con la GPU tomada, es normal
que la pantalla no vuelva hasta el reinicio. Y del otro lado había un instalador pidiendo una tecla
que nadie podía ver que estaba pidiendo.

Hay además un segundo sospechoso, medido y ya corregido ese mismo día: **el cmdline del salto tenía
las consolas al revés**. `/dev/console` es la ÚLTIMA `console=` del cmdline, y con `console=tty0`
antes de `console=ttyS0` el instalador escribía y leía por el **puerto serie** — que un portátil no
tiene. Los dos caminos dan el mismo síntoma: pantalla negra para siempre.

**No se puede decidir cuál de los dos fue sin repetirlo**, y decirlo importa: arreglar sólo uno y
declarar el caso cerrado es exactamente cómo vuelve.

De ahí salen las dos conclusiones que ordenan todo el documento:

> **(a) Ninguna pregunta se hace después del salto.**
> **(b) El salto sólo ocurre si es imprescindible.**

## 2. El orden de las preguntas — IMPLEMENTADO

```
   censo del terreno          ─┐
   elegir destino              │  en el sistema que TODAVÍA funciona
   elegir perfil y paquetes    │  (y con pantalla, teclado y la sesión viva)
   ver el plan y confirmarlo  ─┘
        │
        ├── el destino NO es la raíz viva  ⇒  se instala DESDE ACÁ, sin saltar
        │                                     (la sesión no se muere)
        └── el destino ES la raíz viva     ⇒  se explica qué implica el salto,
                                              se pide confirmación, y lo de después
                                              va con la respuesta PUESTA: ya no
                                              necesita pantalla
                 └── y si esta máquina no puede saltar ⇒ espacio libre, o el USB
```

Hoy están hechos: el censo, la elección (`takana-install-partition.sh --pick`, que muestra el
terreno, deja elegir y **no toca nada**), la decisión de si el salto hace falta (`es_raiz_viva`
sobre el censo), la instalación **sin saltar** cuando el destino está libre, y el salto con la
elección ya puesta en la cmdline. Falta lo del §3 al §6.

⚠ **`--jump` fuerza el salto** aunque no haga falta. Existe para los arneses y para probarlo a
propósito; no es el camino normal.

Y el aviso que faltaba: si se detecta una sesión gráfica, el instalador **dice que el salto es
mucho más sano desde una consola de texto** (Ctrl+Alt+F2). No lo bloquea —hay quien sabe lo que
hace— pero no deja que sea una sorpresa.

## 3. Las dos caras — DECIDIDO, NO CONSTRUIDO

> *el script vea si tiene gui, abre churay llimphi, sino abre churay-tui.*

| | |
|---|---|
| **hay sesión gráfica** | `churay` (la GUI llimphi). Su pestaña «Sistema en disco» ya existe y consume `takana metal survey --json` |
| **no hay** | `churay-tui`, que **todavía no existe**. Hoy el hueco lo tapa el menú de texto del propio instalador, que funciona pero no es una cara |
| **ninguna de las dos se puede abrir** | el menú de texto, como último recurso, que es lo que hay hoy |

La detección es la misma que ya usa el aviso del salto (`WAYLAND_DISPLAY`/`DISPLAY`/
`XDG_SESSION_TYPE`), más «¿existe el binario?».

**El motor no cambia** ([ADR 0021](adr/0021-dueno-del-verbo-de-instalar.md)): las tres caras
—GUI, TUI y el menú de texto— consumen el MISMO censo y el MISMO plan. El día que una de ellas
clasifique particiones por su cuenta, empieza a ofrecer lo que las otras protegen.

## 4. El plan de pasos — DECIDIDO, NO CONSTRUIDO

> *el instalador arma la serie de pasos de qué formatear y cómo particionar.*

Hoy el instalador **decide y ejecuta en el mismo movimiento**. Lo que falta es partirlo en dos:

1. **Planificar**: del estado del disco + las elecciones sale una lista de operaciones ordenada
   (`crear partición`, `formatear`, `copiar rootfs`, `poblar ESP`, `entrada NVRAM`), cada una con lo
   que destruye y lo que no.
2. **Enseñar el plan y pedir UN sí.** Es la pantalla que convierte «confío» en «entendí».
3. **Ejecutar**, con el progreso por paso.

Vive en `churay-core` (frontend-agnóstico, con tests) o en takana según dónde quede el motor; la
decisión no está tomada y **no hace falta tomarla hasta escribir el primer paso**.

## 5. Perfiles y grupos de paquetes — DECIDIDO, NO CONSTRUIDO

> *se eligen los perfiles, por default mirada, pero que si kde, que si gnome, que si también qué
> grupos de paquetes, que si tools, que si compiladores, que si cuando tengamos hacking.*

Los perfiles **ya existen** y son `docs/state/targets.toml`: `escritorio-kde`, `escritorio-gnome`,
`escritorio-cosmic`, `escritorio-sway`, `servidor`, `base`. Lo que no existe es elegirlos al
instalar: hoy el instalador copia **un** rootfs ya armado.

Dos caminos, y el usuario acepta los dos:

| | |
|---|---|
| **A · el medio los trae** | el USB/`.run` lleva varias clausuras y se copia la elegida. Medio más grande, instalación sin red |
| **B · ligera y después** | se instala una base chica y los perfiles se ponen después con `takana install <perfil>` ([SDD 27](27-perfiles-instalables-y-el-instalador.md)). Medio chico, pero pide red |

**B es más barato y depende de que el SDD 27 esté hecho** (hoy `install` resuelve UN paquete, no un
perfil). **A funciona hoy mismo** con el precio del tamaño. La decisión sensata es A para el USB
—que existe justamente para máquinas sin red— y B para el `.run`.

⚠ **`mirada` por defecto**, que es el escritorio de tawasuyu, no uno de los cuatro del catálogo.
Eso es una decisión de producto y conviene que esté escrita: la distro se presenta con su propio
escritorio, y KDE/GNOME/COSMIC/sway son alternativas, no el default.

«Herramientas», «compiladores» y «hacking» son **grupos**, no perfiles: se suman a cualquiera. El
corpus ya tiene 652 recetas selladas que ninguna imagen alcanza —361 Go, 214 Rust, 67 C, casi todas
de línea de comandos— así que el grupo «herramientas» es **coste de build cero: sólo declararlo**.
«hacking» no existe todavía y no se inventa acá.

## 6. El formateo tiene que dejar vivir al cifrado de negación plausible

`qullqa` (tawasuyu, `03_ukupacha/qullqa`) guarda datos vitales de modo que **una revisión del equipo
no produzca sospecha de que existen**. Su pozo es, por diseño, **un dispositivo lleno de aleatorio y
sin ninguna firma**. Para un instalador ingenuo eso es, palabra por palabra, «una partición vacía
que se puede usar».

### 6.1 Lo que YA está hecho — el veredicto `CRUDA`

Una partición en la que no se reconoce nada **ya no se marca `✓ se puede usar`**: se marca
`? sin identificar` y usarla pide una confirmación fuerte —**escribir el nombre del dispositivo**,
no un «sí», porque un sí se contesta por reflejo—. La GUI la pinta distinto y con su propio aviso.

⚠ Y **el mensaje es el mismo** para un pozo, un disco recién borrado y un contenedor cifrado ajeno.
No es pereza: un aviso que dijera «esto parece un volumen oculto» delataría exactamente lo que el
diseño existe para no delatar. Ni el censo ni la cara nombran ninguna hipótesis. Es la misma
contención que el editor de discos de tawasuyu ya había tenido que implementar (su T16), y se copia
a propósito en vez de reinventarse.

### 6.2 Lo que falta, con su razón

- **Nunca crear swap en disco.** Un `swapon` sin cifrar anula el documento entero de qullqa (su T9):
  la llave y el claro terminan en el disco. El reemplazo es **zram** —comprimido en RAM, nunca toca
  el disco— y `zswap` **apagado**, o se queda con las páginas antes de que lleguen a zram. Hoy el
  instalador no crea swap; lo que falta es que eso sea una **decisión escrita y verificada**, no una
  ausencia accidental.
- **Hibernación prohibida** mientras haya un volumen abierto: escribe la RAM al disco.
- **Ofrecer dejar sitio.** Que el plan pueda reservar un dispositivo o un hueco sin tabla, sin
  llamarlo nada. Un instalador que ocupa el disco entero por defecto le quita al usuario la opción
  de tener un pozo, y el que la necesita no va a pedirla en voz alta.
- **No rellenar de ceros lo que no se usa.** Un área de ceros y un área de aleatorio se distinguen a
  simple vista, y la primera dice «acá no hay nada» con demasiada seguridad.

## 7. Lo que ya está, con su prueba

| | prueba |
|---|---|
| censo del terreno, con veredicto por partición | `--survey`, `--json`; guardián `install-particion-test.sh` |
| elegir sin tocar nada (`--pick`) | usado por `takana metal install` |
| instalar **sin saltar** cuando no hace falta | implementado; el arnés del salto ahora pide `--jump` |
| el salto, con la elección ya puesta | `metal-salto-test.sh`, 13 comprobaciones sobre el DISCO |
| el USB, cuando el salto no se puede | `instalador-usb-test.sh --instalar`, 12, arrancando por firmware |
| un fichero que se baja y hace todo | `takana-os.net/descargas/takana-instalador.run` |
| la cara gráfica (pestaña, censo, elección) | `churay-core::metal`, 10 tests; `churay-llimphi` |
| **la cara gráfica instalando, de punta a punta** | medido en QEMU el 2026-09-29 — ver §9 |

## 7.bis La cara gráfica instaló sola (2026-09-29, del lado de tawasuyu)

`churay-tui` **ya existe** (§3 lo daba por no construido) y hay una tercera cara:
`churay-metal`, la misma pantalla del disco pintada **directo al framebuffer del
kernel**, para el medio recién arrancado donde no hay compositor. Se armó un medio
con el paquete del instalador adentro y se booteó en QEMU con UEFI contra un disco
de 8 GB con una partición cruda. La cadena entera anduvo:

    la cara dibuja el terreno → se recorre con las flechas → se escribe el nombre
    del destino a mano → takana metal install → instalado y reiniciando

Sobre el disco, con la máquina apagada: `ext4 «hammer-root», 741 inodos usados` y
`\EFI\takana\takanax64.efi` de 15 MB en la ESP **de ese disco**.

Tres cosas que este lado aprendió, y que quedan dichas por si le sirven a otra
cara:

1. **`--yes` y `--unattended` no son lo mismo, y la bandera lo dice.** churay
   pasaba sólo `--yes` —con una razón escrita: su confirmación autoriza el salto,
   no el formateo, y después del salto el instalador vuelve a preguntar en su
   propia pantalla—. Eso es correcto **para el salto**. Desde el medio no hay
   pantalla después: la cara ya mostró el terreno, ya eligió y ya hizo escribir el
   nombre del disco a mano. Sin `--unattended`, el instalador preguntaba
   «¿formateo /dev/sdb2? [escribí si]» en una consola que nadie estaba mirando y
   se quedaba ahí para siempre. Ahora churay distingue los dos casos.
2. 🔴 **La partición de arranque no es «la primera ESP del censo».** Con el medio
   enchufado, la primera que el censo trae es **la del medio**: la instalación
   dejó el sistema en el disco y el cargador y la entrada NVRAM en el pendrive.
   Se saca el pendrive y la máquina no enciende. churay ahora la cruza con su
   propia medición y elige la del **mismo disco que el destino**; sin geometría no
   adivina y deja que takana la deduzca. Puede valer la pena que el censo diga
   explícitamente a qué disco pertenece cada ESP — el JSON v2 ya trae `disco`,
   así que quizá sólo falta que la cara lo consuma.
3. **El paquete viaja entero o no viaja.** `metal install` saca el árbol a
   instalar del propio `takana-instalador.cpio.gz`; hornear el rootfs y los
   scripts sueltos no alcanza, y el mensaje de error ya lo decía desde la primera
   corrida («Pasá `--payload <directorio del paquete>`»). Puesto en
   `/usr/lib/takana` lo encuentra solo, sin banderas.

Y una que es de este lado pero conviene saber: **`TOOL_<binario>=` funciona y
salva el caso del initramfs** — resolvió `sfdisk`, `blkid`, `mke2fs`, `mmd`,
`mcopy` y `mdir` sin store, tal como promete su comentario.

## 7.ter 🟡 ADOPTAR la partición, en vez de formatearla (HECHO 2026-10-01, falta metal)

El caso que hoy no tiene salida buena: **una sola partición con un Linux adentro
y el `/home` adentro de esa misma partición**. Es el más común de todos, y es el
que peor resuelve formatear — lo único irreponible de una máquina es el `/home`
de quien la usa.

De las tres salidas posibles, sólo una sirve:

| | |
|---|---|
| **formatear** | se pierde el `/home` |
| **instalar encima sin formatear** | quedan **dos juegos de `/etc`**, dos de paquetes y nada que diga cuál manda. No es una opción |
| **adoptar** | el sistema viejo se muda a un subdirectorio y el `/home` se queda donde está |

**Lo que hace barata la tercera:** mover dentro del mismo filesystem es un
`rename(2)` — instantáneo y sin copiar un byte. Mudar `bin boot etc lib opt root
sbin srv usr var` a `/sistema-anterior/` no cuesta espacio ni tiempo. Y el
`/home` **no se mueve**: se queda y pasa a ser el del sistema nuevo.

El resultado es mejor que un respaldo: el sistema viejo queda **entero y
accesible**. Se le puede sacar un archivo de su `/etc`, o volver a él. Formatear
no deja nada.

Las guardas que pedimos, cada una por su motivo:

1. **Comprobar el espacio antes de mover nada** — el sistema nuevo tiene que
   entrar en lo que queda libre. Descubrirlo a mitad es el peor momento.
2. **Un `rename` por entrada de primer nivel**, cada uno atómico: un corte deja
   un árbol a medias pero ningún archivo roto, y el estado se puede leer.
3. **Una marca de que la mudanza empezó**, para terminarla o deshacerla.
4. **`/home` no se mueve.** Es el punto entero.
5. **`lost+found` tampoco**, y si ya existe un `/sistema-anterior` se numera o se
   para.
6. Los uid ya están resueltos por `--keep` (2026-09-25): los usuarios se crean
   con el uid que hay en el `/home`.
7. El tamaño mínimo cambia de significado: «quedan ≥ N libres **después** de lo
   que ya hay», no «la partición mide ≥ N».

**Hecho el 2026-10-01**, el mismo día que se pidió:

```sh
takana metal install --root PARTUUID=… --adopt       # no formatea: muda y se queda con el /home
sh scripts/adoptar-test.sh                            # 25 comprobaciones, sin root, <1 s
```

Vive en `scripts/lib/adoptar.sh`, aparte del instalador, **para poder certificarlo sin root**: el
instalador entero necesita losetup, mount y un disco; estas funciones, sobre directorios, se
prueban enteras en un segundo. Un mecanismo que sólo se puede probar con el hardware delante es un
mecanismo que no se prueba — y éste es el que decide si alguien pierde su `/home`.

Las ocho guardas están puestas, y el banco mide las cinco que pueden salir mal en silencio: que
`/home` no se mueva, que `lost+found` tampoco, que adoptar dos veces no pise la primera mudanza,
que un disco de datos (sin forma de sistema) se rechace nombrando lo que vio, y que **si el sistema
nuevo no entra no se mueva nada**. Esa última lleva su propio brazo de control: el mismo árbol, con
el `df` de verdad, sí entra — sin eso el verde también lo daría una guarda que rechaza siempre.

El `/home` de adentro se cosecha con **el mismo código** que el `/home` de `--keep`
(`scripts/lib/usuarios-del-home.sh`): es la misma pregunta —cómo hace el sistema nuevo para que esos
archivos sigan siendo de quien son— y dos implementaciones divergen en el caso raro, con el síntoma
de un escritorio que no puede escribir en su propia carpeta.

Lo que el banco **no** cubre, y se dice para que nadie lo lea como «probado entero»: montar un ext4
de verdad y ponerle la etiqueta con `e2label`. Eso es metal.

Del lado de churay ya está la mitad que le toca: `foreign-fs` lee la raíz del
volumen **sin montarlo** y dice si la forma del árbol es la de un sistema (`etc`
más programas) y si el `/home` está adentro — por la forma y no por un archivo
concreto, así que vale para cualquier distribución sin conocerla. Y la propuesta
automática ya ordena `adoptar` por encima de `formatear con datos` y por debajo
del espacio sin asignar.

## 8. Lo que este documento NO decide

- **Dónde vive el planificador de pasos**, si en takana o en `churay-core`. Se decide al escribirlo.
- **Cómo se eligen los perfiles en el medio USB** (A) contra el repo (B): depende del SDD 27.
- **El particionado que ENCOGE.** Redimensionar pide desmontar, y eso es física; el instalador ya
  corre desde fuera del disco destino en los dos caminos, así que es posible — pero no está escrito.