gioser

sergio/takana

> Una distribución Linux construida con un laboratorio funcional y hermético en el > sótano, y una terminal mutable, clásica y anárquica en el piso de arriba — diseñada > desde el suelo para que una IA programadora entienda, modifique y co…

TOML 815Rust 56Shell 37Markdown 291229 Definiciones

⎇ 4b1f19d8d85eda4740af94810b184b1d192427f6 docs/32-instalador-de-usuario.md Markdown · 289 líneas · 16.9 KB Historia crudo

feat(instalador): adoptar la particion en vez de formatearla, con la mudanza de verdad 4b1f19d8d · sergio ·

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áficachuray (la GUI llimphi). Su pestaña «Sistema en disco» ya existe y consume takana metal survey --json
no haychuray-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 abrirel 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:

  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 traeel USB/.run lleva varias clausuras y se copia la elegida. Medio más grande, instalación sin red
B · ligera y despuésse 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

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 faltaimplementado; el arnés del salto ahora pide --jump
el salto, con la elección ya puestametal-salto-test.sh, 13 comprobaciones sobre el DISCO
el USB, cuando el salto no se puedeinstalador-usb-test.sh --instalar, 12, arrancando por firmware
un fichero que se baja y hace todotakana-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 puntamedido 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:

formatearse pierde el /home
instalar encima sin formatearquedan dos juegos de /etc, dos de paquetes y nada que diga cuál manda. No es una opción
adoptarel 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ó:

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