1# SDD 32 — El instalador de takana: la cara, los perfiles, y el orden de las preguntas
2
3> **Estado: PARCIAL.** Lo del §2 y §7 está **implementado y medido** (2026-09-23). Lo del §3 al §6
4> está **decidido y no construido**, y se dice cuál es cuál en cada sección.
5> **Nace de un fallo medido en metal**, no de una idea: el §1.
6
7## 1. Lo que pasó, que es de dónde sale todo esto
8
9El usuario bajó el instalador, corrió `takana metal install`, le dijo que sí, y:
10
11> *se voló todo a negro y se quedó así hasta que apagué con el botón de hardware.*
12
13El instalador **estaba vivo del otro lado**. Lo que había pasado es que el orden era *saltá primero,
14elegí después*: toda la conversación —el censo, la elección de partición, la confirmación— ocurría
15**después del `kexec`**, en una máquina cuyo panel puede no volver a encenderse. Un `kexec` no
16reinicia el hardware de vídeo: si el salto sale de una sesión gráfica con la GPU tomada, es normal
17que la pantalla no vuelva hasta el reinicio. Y del otro lado había un instalador pidiendo una tecla
18que nadie podía ver que estaba pidiendo.
19
20Hay además un segundo sospechoso, medido y ya corregido ese mismo día: **el cmdline del salto tenía
21las consolas al revés**. `/dev/console` es la ÚLTIMA `console=` del cmdline, y con `console=tty0`
22antes de `console=ttyS0` el instalador escribía y leía por el **puerto serie** — que un portátil no
23tiene. Los dos caminos dan el mismo síntoma: pantalla negra para siempre.
24
25**No se puede decidir cuál de los dos fue sin repetirlo**, y decirlo importa: arreglar sólo uno y
26declarar el caso cerrado es exactamente cómo vuelve.
27
28De ahí salen las dos conclusiones que ordenan todo el documento:
29
30> **(a) Ninguna pregunta se hace después del salto.**
31> **(b) El salto sólo ocurre si es imprescindible.**
32
33## 2. El orden de las preguntas — IMPLEMENTADO
34
35```
36 censo del terreno ─┐
37 elegir destino │ en el sistema que TODAVÍA funciona
38 elegir perfil y paquetes │ (y con pantalla, teclado y la sesión viva)
39 ver el plan y confirmarlo ─┘
40 │
41 ├── el destino NO es la raíz viva ⇒ se instala DESDE ACÁ, sin saltar
42 │ (la sesión no se muere)
43 └── el destino ES la raíz viva ⇒ se explica qué implica el salto,
44 se pide confirmación, y lo de después
45 va con la respuesta PUESTA: ya no
46 necesita pantalla
47 └── y si esta máquina no puede saltar ⇒ espacio libre, o el USB
48```
49
50Hoy están hechos: el censo, la elección (`takana-install-partition.sh --pick`, que muestra el
51terreno, deja elegir y **no toca nada**), la decisión de si el salto hace falta (`es_raiz_viva`
52sobre el censo), la instalación **sin saltar** cuando el destino está libre, y el salto con la
53elección ya puesta en la cmdline. Falta lo del §3 al §6.
54
55⚠ **`--jump` fuerza el salto** aunque no haga falta. Existe para los arneses y para probarlo a
56propósito; no es el camino normal.
57
58Y el aviso que faltaba: si se detecta una sesión gráfica, el instalador **dice que el salto es
59mucho más sano desde una consola de texto** (Ctrl+Alt+F2). No lo bloquea —hay quien sabe lo que
60hace— pero no deja que sea una sorpresa.
61
62## 3. Las dos caras — DECIDIDO, NO CONSTRUIDO
63
64> *el script vea si tiene gui, abre churay llimphi, sino abre churay-tui.*
65
66| | |
67|---|---|
68| **hay sesión gráfica** | `churay` (la GUI llimphi). Su pestaña «Sistema en disco» ya existe y consume `takana metal survey --json` |
69| **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 |
70| **ninguna de las dos se puede abrir** | el menú de texto, como último recurso, que es lo que hay hoy |
71
72La detección es la misma que ya usa el aviso del salto (`WAYLAND_DISPLAY`/`DISPLAY`/
73`XDG_SESSION_TYPE`), más «¿existe el binario?».
74
75**El motor no cambia** ([ADR 0021](adr/0021-dueno-del-verbo-de-instalar.md)): las tres caras
76—GUI, TUI y el menú de texto— consumen el MISMO censo y el MISMO plan. El día que una de ellas
77clasifique particiones por su cuenta, empieza a ofrecer lo que las otras protegen.
78
79## 4. El plan de pasos — DECIDIDO, NO CONSTRUIDO
80
81> *el instalador arma la serie de pasos de qué formatear y cómo particionar.*
82
83Hoy el instalador **decide y ejecuta en el mismo movimiento**. Lo que falta es partirlo en dos:
84
851. **Planificar**: del estado del disco + las elecciones sale una lista de operaciones ordenada
86 (`crear partición`, `formatear`, `copiar rootfs`, `poblar ESP`, `entrada NVRAM`), cada una con lo
87 que destruye y lo que no.
882. **Enseñar el plan y pedir UN sí.** Es la pantalla que convierte «confío» en «entendí».
893. **Ejecutar**, con el progreso por paso.
90
91Vive en `churay-core` (frontend-agnóstico, con tests) o en takana según dónde quede el motor; la
92decisión no está tomada y **no hace falta tomarla hasta escribir el primer paso**.
93
94## 5. Perfiles y grupos de paquetes — DECIDIDO, NO CONSTRUIDO
95
96> *se eligen los perfiles, por default mirada, pero que si kde, que si gnome, que si también qué
97> grupos de paquetes, que si tools, que si compiladores, que si cuando tengamos hacking.*
98
99Los perfiles **ya existen** y son `docs/state/targets.toml`: `escritorio-kde`, `escritorio-gnome`,
100`escritorio-cosmic`, `escritorio-sway`, `servidor`, `base`. Lo que no existe es elegirlos al
101instalar: hoy el instalador copia **un** rootfs ya armado.
102
103Dos caminos, y el usuario acepta los dos:
104
105| | |
106|---|---|
107| **A · el medio los trae** | el USB/`.run` lleva varias clausuras y se copia la elegida. Medio más grande, instalación sin red |
108| **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 |
109
110**B es más barato y depende de que el SDD 27 esté hecho** (hoy `install` resuelve UN paquete, no un
111perfil). **A funciona hoy mismo** con el precio del tamaño. La decisión sensata es A para el USB
112—que existe justamente para máquinas sin red— y B para el `.run`.
113
114⚠ **`mirada` por defecto**, que es el escritorio de tawasuyu, no uno de los cuatro del catálogo.
115Eso es una decisión de producto y conviene que esté escrita: la distro se presenta con su propio
116escritorio, y KDE/GNOME/COSMIC/sway son alternativas, no el default.
117
118«Herramientas», «compiladores» y «hacking» son **grupos**, no perfiles: se suman a cualquiera. El
119corpus ya tiene 652 recetas selladas que ninguna imagen alcanza —361 Go, 214 Rust, 67 C, casi todas
120de línea de comandos— así que el grupo «herramientas» es **coste de build cero: sólo declararlo**.
121«hacking» no existe todavía y no se inventa acá.
122
123## 6. El formateo tiene que dejar vivir al cifrado de negación plausible
124
125`qullqa` (tawasuyu, `03_ukupacha/qullqa`) guarda datos vitales de modo que **una revisión del equipo
126no produzca sospecha de que existen**. Su pozo es, por diseño, **un dispositivo lleno de aleatorio y
127sin ninguna firma**. Para un instalador ingenuo eso es, palabra por palabra, «una partición vacía
128que se puede usar».
129
130### 6.1 Lo que YA está hecho — el veredicto `CRUDA`
131
132Una partición en la que no se reconoce nada **ya no se marca `✓ se puede usar`**: se marca
133`? sin identificar` y usarla pide una confirmación fuerte —**escribir el nombre del dispositivo**,
134no un «sí», porque un sí se contesta por reflejo—. La GUI la pinta distinto y con su propio aviso.
135
136⚠ Y **el mensaje es el mismo** para un pozo, un disco recién borrado y un contenedor cifrado ajeno.
137No es pereza: un aviso que dijera «esto parece un volumen oculto» delataría exactamente lo que el
138diseño existe para no delatar. Ni el censo ni la cara nombran ninguna hipótesis. Es la misma
139contención que el editor de discos de tawasuyu ya había tenido que implementar (su T16), y se copia
140a propósito en vez de reinventarse.
141
142### 6.2 Lo que falta, con su razón
143
144- **Nunca crear swap en disco.** Un `swapon` sin cifrar anula el documento entero de qullqa (su T9):
145 la llave y el claro terminan en el disco. El reemplazo es **zram** —comprimido en RAM, nunca toca
146 el disco— y `zswap` **apagado**, o se queda con las páginas antes de que lleguen a zram. Hoy el
147 instalador no crea swap; lo que falta es que eso sea una **decisión escrita y verificada**, no una
148 ausencia accidental.
149- **Hibernación prohibida** mientras haya un volumen abierto: escribe la RAM al disco.
150- **Ofrecer dejar sitio.** Que el plan pueda reservar un dispositivo o un hueco sin tabla, sin
151 llamarlo nada. Un instalador que ocupa el disco entero por defecto le quita al usuario la opción
152 de tener un pozo, y el que la necesita no va a pedirla en voz alta.
153- **No rellenar de ceros lo que no se usa.** Un área de ceros y un área de aleatorio se distinguen a
154 simple vista, y la primera dice «acá no hay nada» con demasiada seguridad.
155
156## 7. Lo que ya está, con su prueba
157
158| | prueba |
159|---|---|
160| censo del terreno, con veredicto por partición | `--survey`, `--json`; guardián `install-particion-test.sh` |
161| elegir sin tocar nada (`--pick`) | usado por `takana metal install` |
162| instalar **sin saltar** cuando no hace falta | implementado; el arnés del salto ahora pide `--jump` |
163| el salto, con la elección ya puesta | `metal-salto-test.sh`, 13 comprobaciones sobre el DISCO |
164| el USB, cuando el salto no se puede | `instalador-usb-test.sh --instalar`, 12, arrancando por firmware |
165| un fichero que se baja y hace todo | `takana-os.net/descargas/takana-instalador.run` |
166| la cara gráfica (pestaña, censo, elección) | `churay-core::metal`, 10 tests; `churay-llimphi` |
167
168## 8. Lo que este documento NO decide
169
170- **Dónde vive el planificador de pasos**, si en takana o en `churay-core`. Se decide al escribirlo.
171- **Cómo se eligen los perfiles en el medio USB** (A) contra el repo (B): depende del SDD 27.
172- **El particionado que ENCOGE.** Redimensionar pide desmontar, y eso es física; el instalador ya
173 corre desde fuera del disco destino en los dos caminos, así que es posible — pero no está escrito.
32-instalador-de-usuario.md
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): 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:
- 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.
- Enseñar el plan y pedir UN sí. Es la pantalla que convierte «confío» en «entendí».
- 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). 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 |
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.