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| **la cara gráfica instalando, de punta a punta** | medido en QEMU el 2026-09-29 — ver §9 |
168
169## 7.bis La cara gráfica instaló sola (2026-09-29, del lado de tawasuyu)
170
171`churay-tui` **ya existe** (§3 lo daba por no construido) y hay una tercera cara:
172`churay-metal`, la misma pantalla del disco pintada **directo al framebuffer del
173kernel**, para el medio recién arrancado donde no hay compositor. Se armó un medio
174con el paquete del instalador adentro y se booteó en QEMU con UEFI contra un disco
175de 8 GB con una partición cruda. La cadena entera anduvo:
176
177 la cara dibuja el terreno → se recorre con las flechas → se escribe el nombre
178 del destino a mano → takana metal install → instalado y reiniciando
179
180Sobre el disco, con la máquina apagada: `ext4 «hammer-root», 741 inodos usados` y
181`\EFI\takana\takanax64.efi` de 15 MB en la ESP **de ese disco**.
182
183Tres cosas que este lado aprendió, y que quedan dichas por si le sirven a otra
184cara:
185
1861. **`--yes` y `--unattended` no son lo mismo, y la bandera lo dice.** churay
187 pasaba sólo `--yes` —con una razón escrita: su confirmación autoriza el salto,
188 no el formateo, y después del salto el instalador vuelve a preguntar en su
189 propia pantalla—. Eso es correcto **para el salto**. Desde el medio no hay
190 pantalla después: la cara ya mostró el terreno, ya eligió y ya hizo escribir el
191 nombre del disco a mano. Sin `--unattended`, el instalador preguntaba
192 «¿formateo /dev/sdb2? [escribí si]» en una consola que nadie estaba mirando y
193 se quedaba ahí para siempre. Ahora churay distingue los dos casos.
1942. 🔴 **La partición de arranque no es «la primera ESP del censo».** Con el medio
195 enchufado, la primera que el censo trae es **la del medio**: la instalación
196 dejó el sistema en el disco y el cargador y la entrada NVRAM en el pendrive.
197 Se saca el pendrive y la máquina no enciende. churay ahora la cruza con su
198 propia medición y elige la del **mismo disco que el destino**; sin geometría no
199 adivina y deja que takana la deduzca. Puede valer la pena que el censo diga
200 explícitamente a qué disco pertenece cada ESP — el JSON v2 ya trae `disco`,
201 así que quizá sólo falta que la cara lo consuma.
2023. **El paquete viaja entero o no viaja.** `metal install` saca el árbol a
203 instalar del propio `takana-instalador.cpio.gz`; hornear el rootfs y los
204 scripts sueltos no alcanza, y el mensaje de error ya lo decía desde la primera
205 corrida («Pasá `--payload <directorio del paquete>`»). Puesto en
206 `/usr/lib/takana` lo encuentra solo, sin banderas.
207
208Y una que es de este lado pero conviene saber: **`TOOL_<binario>=` funciona y
209salva el caso del initramfs** — resolvió `sfdisk`, `blkid`, `mke2fs`, `mmd`,
210`mcopy` y `mdir` sin store, tal como promete su comentario.
211
212## 7.ter 🟡 ADOPTAR la partición, en vez de formatearla (HECHO 2026-10-01, falta metal)
213
214El caso que hoy no tiene salida buena: **una sola partición con un Linux adentro
215y el `/home` adentro de esa misma partición**. Es el más común de todos, y es el
216que peor resuelve formatear — lo único irreponible de una máquina es el `/home`
217de quien la usa.
218
219De las tres salidas posibles, sólo una sirve:
220
221| | |
222|---|---|
223| **formatear** | se pierde el `/home` |
224| **instalar encima sin formatear** | quedan **dos juegos de `/etc`**, dos de paquetes y nada que diga cuál manda. No es una opción |
225| **adoptar** | el sistema viejo se muda a un subdirectorio y el `/home` se queda donde está |
226
227**Lo que hace barata la tercera:** mover dentro del mismo filesystem es un
228`rename(2)` — instantáneo y sin copiar un byte. Mudar `bin boot etc lib opt root
229sbin srv usr var` a `/sistema-anterior/` no cuesta espacio ni tiempo. Y el
230`/home` **no se mueve**: se queda y pasa a ser el del sistema nuevo.
231
232El resultado es mejor que un respaldo: el sistema viejo queda **entero y
233accesible**. Se le puede sacar un archivo de su `/etc`, o volver a él. Formatear
234no deja nada.
235
236Las guardas que pedimos, cada una por su motivo:
237
2381. **Comprobar el espacio antes de mover nada** — el sistema nuevo tiene que
239 entrar en lo que queda libre. Descubrirlo a mitad es el peor momento.
2402. **Un `rename` por entrada de primer nivel**, cada uno atómico: un corte deja
241 un árbol a medias pero ningún archivo roto, y el estado se puede leer.
2423. **Una marca de que la mudanza empezó**, para terminarla o deshacerla.
2434. **`/home` no se mueve.** Es el punto entero.
2445. **`lost+found` tampoco**, y si ya existe un `/sistema-anterior` se numera o se
245 para.
2466. Los uid ya están resueltos por `--keep` (2026-09-25): los usuarios se crean
247 con el uid que hay en el `/home`.
2487. El tamaño mínimo cambia de significado: «quedan ≥ N libres **después** de lo
249 que ya hay», no «la partición mide ≥ N».
250
251**Hecho el 2026-10-01**, el mismo día que se pidió:
252
253```sh
254takana metal install --root PARTUUID=… --adopt # no formatea: muda y se queda con el /home
255sh scripts/adoptar-test.sh # 25 comprobaciones, sin root, <1 s
256```
257
258Vive en `scripts/lib/adoptar.sh`, aparte del instalador, **para poder certificarlo sin root**: el
259instalador entero necesita losetup, mount y un disco; estas funciones, sobre directorios, se
260prueban enteras en un segundo. Un mecanismo que sólo se puede probar con el hardware delante es un
261mecanismo que no se prueba — y éste es el que decide si alguien pierde su `/home`.
262
263Las ocho guardas están puestas, y el banco mide las cinco que pueden salir mal en silencio: que
264`/home` no se mueva, que `lost+found` tampoco, que adoptar dos veces no pise la primera mudanza,
265que un disco de datos (sin forma de sistema) se rechace nombrando lo que vio, y que **si el sistema
266nuevo no entra no se mueva nada**. Esa última lleva su propio brazo de control: el mismo árbol, con
267el `df` de verdad, sí entra — sin eso el verde también lo daría una guarda que rechaza siempre.
268
269El `/home` de adentro se cosecha con **el mismo código** que el `/home` de `--keep`
270(`scripts/lib/usuarios-del-home.sh`): es la misma pregunta —cómo hace el sistema nuevo para que esos
271archivos sigan siendo de quien son— y dos implementaciones divergen en el caso raro, con el síntoma
272de un escritorio que no puede escribir en su propia carpeta.
273
274Lo que el banco **no** cubre, y se dice para que nadie lo lea como «probado entero»: montar un ext4
275de verdad y ponerle la etiqueta con `e2label`. Eso es metal.
276
277Del lado de churay ya está la mitad que le toca: `foreign-fs` lee la raíz del
278volumen **sin montarlo** y dice si la forma del árbol es la de un sistema (`etc`
279más programas) y si el `/home` está adentro — por la forma y no por un archivo
280concreto, así que vale para cualquier distribución sin conocerla. Y la propuesta
281automática ya ordena `adoptar` por encima de `formatear con datos` y por debajo
282del espacio sin asignar.
283
284## 8. Lo que este documento NO decide
285
286- **Dónde vive el planificador de pasos**, si en takana o en `churay-core`. Se decide al escribirlo.
287- **Cómo se eligen los perfiles en el medio USB** (A) contra el repo (B): depende del SDD 27.
288- **El particionado que ENCOGE.** Redimensionar pide desmontar, y eso es física; el instalador ya
289 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 |
| 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:
--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.
- 🔴 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.
- 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:
- 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.
- 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.
- Una marca de que la mudanza empezó, para terminarla o deshacerla.
/home no se mueve. Es el punto entero.
lost+found tampoco, y si ya existe un /sistema-anterior se numera o se
para.
- Los uid ya están resueltos por
--keep (2026-09-25): los usuarios se crean
con el uid que hay en el /home.
- 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ó:
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.