«Empieza aquí» de `ENCINA-OS.md` §7, del 2026-08-08 al 2026-08-25: el archivo de por dónde se empezó

Qué es esto. Todo lo que ENCINA-OS.md §7 tenía el 2026-08-28 por debajo de su título, movido verbatim aquí por la tarea 7 de refactorizacion.md: CLAUDE.md manda leer §7 «siempre primero, la tarea en curso y sólo esa», y §7 medía 1 772 líneas —el archivo de por dónde se empezó, no por dónde empezar—. Los bloques van en el orden en que estaban: el más reciente arriba («AL DÍA, 2026-08-25») y hacia abajo el pasado, cada uno con su fecha en el título; al final, lo que §7 conservaba de E1 y de E2. No se ha reescrito ni una línea: lo único que cambia son los enlaces relativos, que desde tareas/cerradas/ necesitan dos niveles más (6 líneas), y el control es que el fichero menos esa corrección es byte a byte lo que había. Las referencias §4.NN siguen resolviendo contra mediciones/ como siempre.

AL DÍA, 2026-08-25: LA FASE 1 ESTÁ COMPLETA — 1a en el hierro amd64, 1b en el banco arm64 con 0.1.17 y el veredicto de Jorge

1a, cerrada (§4.78 y sus tres enmiendas): fila g pagada sin red en el Acer, la bellota cerrada con Yaru-sage-dark contestado, verificar-instalacion.sh 65/0 dentro, «Hierro AMD» 3 de 3.

1b, lo medido hoy (§4.79):
medios/encina-os-arm64.iso    63f360dd755251d1…   3 721 265 152 bytes   encina-branding 0.1.17
seis pasadas en tres commits (c086466, 3e1ed01, e3950f4): UNA huella, cmp mudo; distinta de cd84d2ec (control)
xorriso -report_system_area: MBR cyl-align-all, CERO líneas GPT, tabla idéntica a cd84d2ec  <- §4.74(b) ya no es deducción
encina-entrega-63f360dd (sufijo C0): arranca, «Disposición del teclado» en español sobre el fondo de Encina a los ~2 min
Y un instrumento que mentía, arreglado con su control: fabricar-iso.sh daba [FALLO] en el paso 10 sobre un medio correcto — el bash 3.2 de macOS y un array vacío bajo set -u (trampa 59). Las cuatro pasadas «rojas» tienen la misma huella que las dos verdes: la ISO no dependía del arreglo.

Y MÁS TARDE EL MISMO DÍA (§4.79, enmienda): Jorge contestó las cinco pantallas, la máquina levantó, y el verificador dentro dio 65 / 0 / 0 / 0 —tecleado por el agente, salida por el buzón con sus tres controles, la contraseña de Jorge—. Tres pantallas de sesión tomadas y miradas (design/capturas/despues/entrega-63f360dd/).

Y con el reinicio autorizado, las tres del arranque en frío con dos pasadas: las seis pantallas están tomadas (Plymouth invisible en la VM, GDM con la encina y el recuadro naranja ya aceptado).

Y EL VEREDICTO, DADO: «las capturas las veo todas bien». Las dos casillas de aspecto/5-cierre.md y la de marca-del-medio.md, marcadas. LA FASE 1 ESTÁ COMPLETA: las dos ISOs funcionan de verdad, en hierro amd64 y en el banco arm64. Lo siguiente es la fase 2, la refactorización entera (tareas/refactorizacion.md), que invalida a propósito estas dos huellas. Con el veredicto se cierran, si toca, las dos casillas de aspecto/5-cierre.md y la de marca-del-medio.md. Después, la fase 2.

LA TAREA EN CURSO, 2026-08-23: EL FALLO DEL INSTALADOR amd64 NO SE REPRODUCE, Y EL RELOJ QUE LO EXPLICA ES DE UBUNTU

Todo con su control en MEDICIONES.md §4.65 —la predicción comprometida en el commit 0a5c636 antes de arrancar ninguna VM, el marcador en (g), el conteo de arranques en (h), el instrumento nuevo en (i), el registro en (j), el control que separa en (k) y lo medido contra lo deducido en (l)—. Los cuatro registros, en design/registros/amd64-e6/.

TRES ARRANQUES DEL MISMO BUNDLE, TRES RESULTADOS DISTINTOS:
2026-08-22 noche  -> «Se produjo un problema ... ubuntu-desktop-bootstrap»
2026-08-23 02:34  -> la SESION GRAFICA se muere: «Algo salio mal»  (otro fallo)
2026-08-23 03:11  -> EL INSTALADOR VA: «Disposicion del teclado», en español
Y el de las 03:11 se dejó solo 5 h 33 min —con un sueño del anfitrión de por medio— y seguía en la misma pantalla. Sin manos no se cae. Así que «el instalador amd64 se cae» no se puede escribir: es la octava atribución falsa, y la ha parado contar arranques (§4.59).

YA SE PUEDE LEER EL REGISTRO DE DENTRO, que anoche no se pudo: Alt+F2 → «Ejecutar una orden» → wget --post-file contra un buzón del Mac, con sus tres controles delante (SCRIPTS.md, la vía nueva). curl no está en la sesión viva; wget sí. Trampas 57 y 58.

Y LO QUE EL REGISTRO NOMBRA ES UN RELOJ, no un paquete ni la capa:
INFO subiquity_server: Waiting server up to 90 seconds     <- literal, del frontal

                                 reintentos   s hasta el zocalo
ISO OFICIAL amd64 (sin Encina)       82            84,26
NUESTRO medio amd64 (8924f148)       81            82,03
presupuesto del frontal               -            90,00
LA OFICIAL ESTÁ PEOR QUE LA NUESTRA. El reloj es de Ubuntu y el margen se lo come el banco emulado, con Encina y sin Encina. Ese es el control que §4.64(l) pedía, en una forma mejor y de un solo arranque: se supo al leer (j) que el reloj corre antes de que el seed exista, así que «la oficial + nuestro seed» ya no era el control.

Y EL CONTROL SALE POR DONDE NO SE ESPERABA, §4.65(p): LA ISO OFICIAL SE ROMPE IGUAL. Con 2 CPU, la oficial amd64 —cero líneas de Encina— dejó plymouthd abortado con su backtrace y acabó en «Oh no! Something has gone wrong», que es la misma pantalla que nuestro medio dio a las 02:34. El conteo va 2 de 4 el nuestro y 1 de 2 la oficial: los dos fallan, y en la misma proporción. Eso es el criterio 1 de §4.59 —un control conocido-bueno que falla— y es lo que contesta «de quién es».

Y UN MODELO TUMBADO POR EL CAMINO: con la mitad de CPU el servidor tardó menos (65,83 s contra 82,03), así que esos segundos no los manda la CPU del invitado.

LO QUE FALTA, Y AHORA TIENE NOMBRE: un arranque roto no se puede leer —Alt+F2 no abre nada, Alt+F1/F3/F4 no cambian de consola—. La vía apuntada y no pagada: editar la línea del núcleo en GRUB y añadir console=ttyS0, que levanta un getty en el Serial = Ptty que el bundle ya trae. Con eso sí se podría cazar el ubuntu_bootstrap.log. Lo que sigue valiendo: cazar un arranque que se caiga y sacarle el ubuntu_bootstrap.log. Si sus reintentos llegan a ~90 s, la hipótesis del reloj queda probada; si se cae por otra cosa, se tacha. Hasta entonces es deducción con su aritmética y así está escrita.

Y LO QUE SIGUE ES EL HIERRO, que ya tiene máquina: un portátil AMD A9 de 7ª generación y un pincho. La receta, con sus controles, está abajo. Nada de la emulación lo sustituye: es lo único que desata amd64 de la emulación y lo único que contesta Plymouth.

LA RECETA DEL HIERRO — amd64 en el portátil AMD A9 (7ª gen)

0. LA PREMISA, antes de grabar nada. Lo que se graba es lo que se cree:
shasum -a 256 medios/encina-os-amd64.iso        ->  3d5d12a9bda40068…     (desde el 2026-08-24: lleva encina-branding 0.1.17 —el desvío de la bellota—, §4.76 y §4.77)
(Historial: 8924f1484a74de93… era el 0.1.15 —el medio del que se instaló el Acer; su encina-os-amd64-0115.iso ya no está en medios/— y 68cf0f44… el 0.1.16, fabricado el 2026-08-23 y NUNCA arrancado: queda en medios/encina-os-amd64-0116.iso y su borrado es de Jorge. Las huellas del paso 1 de abajo son las del medio VIGENTE, recalculadas sobre el fichero; las anteriores se dejan tachadas.)

1. GRABAR EL PINCHO, y comprobarlo leyendo del dispositivo —no mirando el diálogo del grabador—. La lectura de vuelta compara la ISO entera, y su control negativo es gratis: un byte de menos ya tiene que dar otra huella.
diskutil list                                   # identificar el pincho, el EXTERNO
diskutil unmountDisk /dev/diskN
sudo dd if=medios/encina-os-amd64.iso of=/dev/rdiskN bs=4m
sync
N=$(stat -f %z medios/encina-os-amd64.iso)      # 6849232896
B=$(( N/1048576 + 1 ))                          # 6532 MiB: se pasa A PROPOSITO
sudo dd if=/dev/rdiskN bs=1m count=$B | head -c "$N"       | shasum -a 256  ->  3d5d12a9…  [OK]   (~~68cf0f44…~~ ~~8924f148…~~)
sudo dd if=/dev/rdiskN bs=1m count=$B | head -c "$((N-1))" | shasum -a 256  ->  0b5a1af9…  <- el CONTROL: (~~5d94f8b9…~~ ~~0ad9f99a…~~)
                                                             si diera lo mismo, la
                                                             comprobación no compara nada
dd lee de más y head -c corta en el byte exacto, así que la forma vale para cualquier ISO y no hay que rehacer la cuenta al cambiar de medio. Las dos órdenes están ejecutadas contra el fichero antes de escribirlas aquí —positivo 8924f148…, control 0ad9f99a…—, así que las dos huellas de arriba son medidas y no esperadas. Si se prefieren bloques exactos: 6 849 232 896 = 65 536 × 104 511, o sea bs=64k count=104511 —también comprobado— y su control es count=104510.

ENMIENDA DEL 2026-08-23, ANTES DE GRABAR NADA: LA CUENTA QUE HABÍA AQUÍ ERA FALSA Y HABRÍA DADO UN [FALLO] QUE NO ERA. Este paso decía «la ISO mide 6 849 232 896 bytes = 6 531 MiB exactos», y de ahí salían count=6531 y su control count=6530. No son exactos, y basta la división:
6 849 232 896 / 1 048 576 = 6531,9375 MiB
6531 MiB                  = 6 848 249 856 bytes   <- 983 040 bytes DE MENOS
O sea que count=6531 lee 960 KiB menos que la ISO, y su huella no puede ser 8924f148… ni con el pincho perfectamente escrito. Y el control no habría avisado: count=6530 habría seguido diciendo «otra cosa», que es exactamente lo que dice cuando todo va bien. La lectura natural del resultado —«el pincho está mal escrito» o «el dd se ha dejado bytes»— habría sido una atribución falsa más, la novena, y sobre hierro recién estrenado, que es donde más barato sale creerse cualquier cosa. Se cazó haciendo la división, que es lo que había que hacer al escribirla.

Lo que se creía, dejado al lado: que el tamaño de una ISO redondea a MiB enteros y que por eso bs=1m count=<MiB> la lee entera. Ninguna de las dos que hay en medios/ lo cumple —la oficial amd64 son 6 655 619 072 bytes, o sea 6347,29 MiB—, así que la trampa no era de esta receta sino de la forma, y por eso se sustituye la forma y no el número.

2. EL CONTROL DEL ARRANQUE, y va DESPUÉS y no antes — con su motivo. §4.64(b2) lo pedía delante; si el nuestro arranca, no hace falta: un positivo no necesita el negativo. Sólo si el nuestro NO arranca se graba medios/ubuntu-24.04.4-desktop-amd64.iso 3a4c9877… en el mismo pincho y el mismo portátil, y hasta entonces no se escribe nada: sin ese control, un «no arranca» no distingue el medio de un arranque seguro activado, de un pincho mal escrito o de la máquina. Por eso esa ISO no se ha borrado.

3. EN LA BIOS: arranque UEFI, no legacy/CSM. Motivo medido: la ESP es byte a byte la oficial y la cadena firmada está intacta, así que el arranque seguro debería pasar. El BIOS heredado tiene una pregunta abierta que nadie ha contestado —el pvd_lba que pasa de 16 a 64 en el eltorito.img, §4.64(j)—, así que si se prueba en ese modo, se prueba sabiendo que es terreno sin medir.

4. QUÉ MIRAR, en orden, y qué es [OJOS] de verdad:

qué qué significa

a el menú de GRUB dice «Probar o instalar Encina OS» la marca del medio viaja

b el splash del MEDIO dirá «Ubuntu» NO ES UN FALLO. Está declarado en D23: watermark.png y bgrt-fallback.png viven en el initrd, antes de que exista ninguna capa. La capa de marca no puede llegar ahí

c sesión viva: fondo de Encina y «ENCINA OS / Versión 24.04 LTS / Edición ‘La Mancha’» ya medido en emulación

d el instalador en español, cinco pantallas ya medido en emulación

e CON RED: que termine, y dentro sudo ./imagen/verificar-instalacion.sh --forma e3 --visibles 27 el positivo de extremo a extremo en amd64

f el splash de la MÁQUINA INSTALADA: ahí sí tiene que salir la encina ESTE es el [OJOS] de Plymouth, y no el del medio. Lo pone encina-branding: registra default.plymouth con prioridad 200 y corre update-initramfs -u (R7), y el tema es ModuleName=script, no bgrt (R6)

f COBRADO EL 2026-08-23 en el Acer Aspire ES1-524 (AMD A9), con foto (§4.70a). Y dos cosas que el hierro enseñó el mismo día y ninguna VM había enseñado: el segundo arranque se queda en negro tras Plymouth, y no es de Encina —el saludador toma tty1 y no presenta; sudo systemctl restart gdm lo resuelve; frecuencia y registro [OMIT], §4.70b—, y el modo oscuro de Ajustes se lleva la bellota del dock (§4.70c), que sí es de producto y tiene casilla en tareas/aspecto/5-cierre.md. Las filas a, d, e, g siguen sin desglosar — y la e PASÓ esa misma noche por ssh (§4.70e): 61/1/1/0, el [FALLO] es que Jorge volvió atrás en el instalador y el [AVISO] es firmware-updater, que amd64 siembra: en amd64 son --visibles 28. Quedan a y d como [OJOS] y g sin hacer

f EL NEGRO, CAZADO LA MISMA NOCHE POR ssh (§4.70b, enmienda): NO era carrera ni azar, era 0 de 5. amdgpu no va en el initrd (diseño de Ubuntu), tarda 17 s en cargar en ese A9, y mutter 46.2 se rompe al pasar de simpledrm a amdgpu en caliente. Remedio en el hierro, 3 de 3, y de los tres medidos el que no nombra hardware (§4.70f): /etc/systemd/system/gdm.service.d/encina-espera-gpu.conf con [Unit], Wants=systemd-udev-settle.service, After=systemd-udev-settle.service. Si el portátil de prueba es AMD, hazlo antes de juzgar nada de la sesión; y si no se hace, un [FALLO] del segundo arranque es de esto y no del medio. Desde la noche del 2026-08-23 ese fichero lo pone encina-branding 0.1.16 (§4.72), y en el Acer, desde el .deb, da 3 de 3 con saludador mirado (§4.73): un medio refabricado con 0.1.16 ya no necesita la mano; el vigente (0.1.15) sí

g SIN RED: repetir si se cae, el sitio donde mirar ya está escrito: curthooks, §4.63(t). Sería el límite declarado del producto, no un fallo del portátil

	qué	qué significa
a	el menú de GRUB dice «Probar o instalar Encina OS»	la marca del medio viaja
b	*el splash* del MEDIO dirá «Ubuntu»**	NO ES UN FALLO. Está declarado en D23: `watermark.png` y `bgrt-fallback.png` viven en el `initrd`, antes de que exista ninguna capa. La capa de marca no puede llegar ahí
c	sesión viva: fondo de Encina y «ENCINA OS / Versión 24.04 LTS / Edición ‘La Mancha’»	ya medido en emulación
d	el instalador en español, cinco pantallas	ya medido en emulación
e	CON RED: que termine, y dentro `sudo ./imagen/verificar-instalacion.sh --forma e3 --visibles 27`	el positivo de extremo a extremo en `amd64`
f	*el splash* de la MÁQUINA INSTALADA: ahí sí tiene que salir la encina**	ESTE es el `[OJOS]` de Plymouth, y no el del medio. Lo pone `encina-branding`: registra `default.plymouth` con prioridad 200 y corre `update-initramfs -u` (R7), y el tema es `ModuleName=script`, no `bgrt` (R6)
f		COBRADO EL 2026-08-23 en el Acer Aspire ES1-524 (AMD A9), con foto (§4.70a). Y dos cosas que el hierro enseñó el mismo día y ninguna VM había enseñado: el segundo arranque se queda en negro tras Plymouth, y no es de Encina —el saludador toma tty1 y no presenta; `sudo systemctl restart gdm` lo resuelve; frecuencia y registro `[OMIT]`, §4.70b—, y el modo oscuro de Ajustes se lleva la bellota del dock (§4.70c), que sí es de producto y tiene casilla en `tareas/aspecto/5-cierre.md`. Las filas a, d, e, g siguen sin desglosar — y la e PASÓ esa misma noche por `ssh` (§4.70e): 61/1/1/0, el `[FALLO]` es que Jorge volvió atrás en el instalador y el `[AVISO]` es `firmware-updater`, que amd64 siembra: en amd64 son `--visibles 28`. Quedan a y d como `[OJOS]` y g sin hacer
f		EL NEGRO, CAZADO LA MISMA NOCHE POR `ssh` (§4.70b, enmienda): NO era carrera ni azar, era 0 de 5. `amdgpu` no va en el initrd (diseño de Ubuntu), tarda 17 s en cargar en ese A9, y mutter 46.2 se rompe al pasar de `simpledrm` a `amdgpu` en caliente. Remedio en el hierro, 3 de 3, y de los tres medidos el que no nombra hardware (§4.70f): `/etc/systemd/system/gdm.service.d/encina-espera-gpu.conf` con `[Unit]`, `Wants=systemd-udev-settle.service`, `After=systemd-udev-settle.service`. Si el portátil de prueba es AMD, hazlo antes de juzgar nada de la sesión; y si no se hace, un [FALLO] del segundo arranque es de esto y no del medio. Desde la noche del 2026-08-23 ese fichero lo pone `encina-branding` 0.1.16 (§4.72), y en el Acer, desde el `.deb`, da 3 de 3 con saludador mirado (§4.73): un medio refabricado con 0.1.16 ya no necesita la mano; el vigente (0.1.15) sí
g	SIN RED: repetir	si se cae, el sitio donde mirar ya está escrito: `curthooks`, §4.63(t). Sería el límite declarado del producto, no un fallo del portátil

| g | | PAGADA EL 2026-08-25 (§4.78, testimonio de Jorge): la instalación sin red desde el medio 3d5d12a9… (0.1.17) TERMINÓ y la máquina funciona — y la bellota sobrevive a oscuro↔claro en el hierro, que es el desvío de §4.76 trabajando donde §4.70c la perdió. Lo que queda con nombre: el dconf read antes/después con cierre de sesión (bellota, su otra mitad), tres arranques seguidos con saludador contados («Hierro AMD»), y verificar-instalacion.sh --forma e3 --visibles 28 dentro |

EL ORDEN DE TODO LO QUE QUEDA, decidido por Jorge el 2026-08-23: PUBLICAR ES LO ÚLTIMO

Tres fases, y no se solapan. El desarrollo detallado, en TAREAS.md, «El orden cambia el 2026-08-23» —donde queda dejado al lado el orden anterior, que ponía publicar antes de la refactorización y no era falso, sólo protegía otra cosa—.
1.  QUE LAS ISOs FUNCIONEN DE VERDAD   <- AQUI ESTAMOS
      a) el hierro amd64: la receta de arriba, en el portatil AMD A9
      b) la vuelta unica arm64: branding 0.1.17 (era 0.1.16, y antes 0.1.15; el drop-in
         de gdm entro el 2026-08-23 noche, §4.72, y el desvio de la bellota el 24, §4.76),
         dos pasadas, instalar y MIRAR
         -> 2026-08-25: MITAD PAGADA. medios/encina-os-arm64.iso 63f360dd…, SEIS pasadas
            una huella (§4.79); arrancado en encina-entrega-63f360dd hasta «Disposicion
            del teclado». Faltan las cinco pantallas (Jorge), el verificador dentro y los [OJOS]
2.  LA REFACTORIZACION ENTERA          tareas/refactorizacion.md, 12 tareas
      se ADELANTA a publicar, y sin la excepcion de las cinco
      la 1 (bancos/enlaces.sh) y la 12 (que es «profesional», escrito) van delante
3.  PUBLICAR                           alojamiento.md + publicar.md
El motivo, en una frase: publicar es el único acto de este proyecto que no se puede deshacer —una release tiene URL, se descarga y activa las dos obligaciones que §2 midió—, y un acto irreversible va detrás de los reversibles. Todo lo demás se rehace en el disco de Jorge sin que nadie se entere.

Y lo que eso obliga a decir ahora, para que no se dé por sabido luego: la huella que se publique no será ninguna de las de hoy. La fase 2 toca imagen/fabricar-iso.sh, así que el medio se refabrica una última vez en la fase 3 con los guiones ya definitivos. Nadie paga dos veces: esa vuelta ya estaba debida por E6 y por encina-branding 0.1.15.

LA TAREA EN CURSO, 2026-08-22 (noche): HAY UN MEDIO amd64 Y ARRANCA CON LA MARCA. EL INSTALADOR SE CAE, Y NO SE SABE DE QUIÉN ES

Todo con su control en MEDICIONES.md §4.64 —la predicción en (a)-(f), el marcador en (g), los hallazgos en (h)-(k) y lo que hay en (l)—. Las tres capturas, en design/capturas/amd64-e6/.
medios/encina-os-amd64.iso   8924f1484a74de93…   6,38 GiB
fabricar-iso.sh: 49 correctas, 0 fallos
y el arm64 rehecho TRES veces: cd84d2ec… BYTE A BYTE las tres
LO QUE FUNCIONA, MEDIDO: el medio arranca en un x86_64 emulado, sale el fondo de Encina, el reloj dice «22 de ago» —el locale se aplicó en las dos líneas de núcleo que la amd64 tiene— y detrás del error hay una sesión viva de Encina OS entera, con su lanzador. O sea que la capa de marca (D23) se monta en amd64 igual que en arm64.

LO QUE NO: «Se produjo un problema … ubuntu-desktop-bootstrap».

Y DE QUIÉN ES ESE FALLO NO SE SABE. El control que hay NO lo separa, y eso se dice antes de que alguien lo dé por sabido: la ISO oficial amd64 sí llegó al instalador —en inglés, en 286 s— pero se quedó en la primera pantalla porque no lleva autoinstall.yaml, así que nunca recorrió el camino donde el nuestro se cae. Lo siguiente son los tres controles de §4.64(l), en ese orden: (1) la ISO oficial amd64 + NUESTRO seed en forma E2; (2) el medio arm64 cd84d2ec… en un bundle igual, que ya se sabe que instala; (3) el registro de dentro.

LO QUE SÍ SE DESCARTA, y está medido: que falte un .deb. banco-autosuficiencia.sh --arq amd64 da 25 de 25 diciendo localhost.

DOS COSAS ESCRITAS QUE CADUCAN HOY:

NO hace falta un constructor amd64 (§4.64 P2), y tareas/despues-de-publicar.md decía que sí. Los cuatro .deb son _all, dpkg-scanpackages indexó los 29 en la VM arm64 y apt-get -s resolvió 394 paquetes para amd64 desde ella, con su control. El portátil hace falta para arrancar, no para fabricar.

La ISO oficial amd64 pesa 6,20 GiB contra 3,30 de la arm64. Para alojamiento.md eso no es un grado más del mismo problema: la entrega pasa de 3,46 GB a ~6,4 GB y hay que publicar dos.

Y UN VERDE FALSO CAZADO, que valía para las dos arquitecturas: las tres huellas de la cadena firmada salían e3b0c442… —la de la cadena vacía— porque la amd64 llama EFI/boot a lo que la arm64 llama efi/boot. Un medio con la cadena de arranque destrozada habría pasado esa comprobación y la de después. Trampas 52-56 de SCRIPTS.md.

LA TAREA EN CURSO, 2026-08-22: LA INSTALACIÓN OCURRE — Y SALE SIN NINGÚN PAQUETE DE ENCINA. Falta UN .deb en el medio

La última casilla del incremento por fin se pagó, y encontró exactamente lo que existía para encontrar (MEDICIONES.md §4.61). El medio p10-capa arrancó, el instalador salió en español, Jorge contestó las cinco pantallas, la instalación terminó y la máquina arranca de su disco, 2 de 2. Lo que bloqueaba desde el 2026-08-17 —«no hay instalación»— está resuelto.
verificar-instalacion.sh --forma e3 --visibles 27, como root:
[OK] 41   [FALLO] 20   [AVISO] 1   [OMIT] 0

dpkg -l encina-branding encina-meta encina-firefox-native autofirma
  no se ha encontrado ningun paquete que corresponda con ...  (los CUATRO)
Y el síntoma se vio en la PRIMERA pantalla, antes de entrar: el logotipo de GDM es el de Ubuntu, donde design/capturas/despues/03-gdm.png tiene la encina. Repetido en los dos arranques.

LA CAUSA, MEDIDA, CON NOMBRE Y VERSIÓN — y es UN paquete:
Inst libnss3 [2:3.98-1build1] (2:3.98-1ubuntu0.2 Ubuntu:24.04/noble-updates ...)
      ^ la UNICA de las 22 lineas de la simulacion que NO dice «localhost»
E: Failed to fetch .../libnss3_3.98-1ubuntu0.2_arm64.deb
   Temporary failure resolving 'ports.ubuntu.com'
imagen/repo-manifiesto.tsv lleva libnss3-tools 2:3.98-1ubuntu0.2 y no lleva libnss3; el -tools exige a su hermano en esa misma versión, así que apt install encina-meta tiene que salir a la red — y en el chroot de curtin no hay DNS, que es lo normal y el propio seed lo mide en su paso 7. Un solo .deb que no se puede traer aborta la transacción entera.

Lo que esto destapa es más grande que un .deb: el medio NO es autosuficiente, y nadie lo sabía porque nadie había instalado sin red. El concepto está bien —el medio lleva su /encina-repo para no necesitarla—; la lista tiene un hueco. No es regresión de un cambio nuestro: es deriva del archivo de Ubuntu, que se mueve mientras el manifiesto no.

DE PASO, DOS CASILLAS QUE SÍ SE CIERRAN:

[OMIT] P5, cerrado. El título de la ventana del instalador dice «Encina OS», leído con xwininfo dentro de la sesión viva y con otra ventana como control. Las capturas no lo enseñaban porque pintan el título de la página.

El instalador NO se recorre sólo con teclado, medido con su control delante: las teclas llegan, pero Tab cicla entre dos paradas y nunca toca «Siguiente»; Intro abre «Detectar». Es un límite del banco, no del producto, y por eso las cinco pantallas las contestó Jorge.

Y EL BANCO SE LLEVA DOS CORRECCIONES, las dos tumbando algo que se creía:

La trampa 45 estaba mal explicada. «Se destrabó con open -a UTM» es falso: los informes de caída de macOS enseñan que el UTM sordo segfaltea y arranca otro (pid 35881 a las 16:34 del 21 — el que la trampa daba por «vivo todo el rato» — y pid 47537 a las 00:16 del 22, 38 s antes del arranque bueno). Habría sido la sexta atribución falsa. Y deja un candidato post-hoc para el 33 % de §4.59.

El tamaño de debug.log no separa nada. El arranque que instaló el sistema entero lo dejó en 2 727 bytes —donde se creía que eso era «VM colgada»—. Trampa 47.

Y HAY UNA TERCERA CORRECCIÓN, QUE ES LA MÁS GRAVE DEL DÍA: LA RED DE SEGURIDAD NO EXISTE. El seed acaba en [ "$ESTADO" = COMPLETO ] || exit 1, con veinte líneas leídas en el código de subiquity que explican por qué eso tiene que enseñar «An error occurred during installation»… y la línea que lo invoca en imagen/autoinstall.yaml acaba en ; true, que se traga el código de salida. Por eso una máquina sin ningún paquete de Encina se entregó diciendo «listo para usarse». Con la red puesta, el hueco del repo se habría cazado en el minuto uno.

AL DÍA, 2026-08-22 (tarde): LOS DOS ARREGLOS Y LA GUARDA, HECHOS. FALTA LA PANTALLA

Los detalles y el marcador, en MEDICIONES.md §4.62. Lo hecho:

El ; true, fuera de imagen/fabricar-seed.sh y de los dos yaml. Y la otra mitad, que no estaba en la lista: fabricar-iso.sh comparaba sólo el trozo del base64 y no la cola, así que no habría visto volver el ; true. Ahora compara la línea entera, medido con su control: sobre un yaml con la cola devuelta, la comprobación vieja da [OK] y la nueva lo rechaza.

libnss3 al manifiesto (28 → 29), cosecha rehecha, 29 de 29 cuadran. De paso, el número de .deb sale del manifiesto y ya no está escrito a mano en construir-todo.sh.

La guarda existe y funciona: imagen/banco-autosuficiencia.sh. Corre en segundos sin arrancar nada y, desde fuera, saca la misma línea que el seed.log escribió dentro de la máquina de anoche. Su control quita simple-scan del índice y lo señala.

Los dos medios, fabricados: …control-sin-libnss3.iso 19587dd4… (el del punto 0, con el repo todavía roto a propósito) y …libnss3.iso cd84d2ec….

Y DOS COSAS QUE TUMBAN LO QUE SE CREÍA:

libnss3 ERA el único hueco, y se predijo que no. Medido sobre las tres transacciones que el seed hace contra el repo, no sólo la primera. No hay una familia de .deb partidos: hay un archivo que se mueve.

La guarda salió CIEGA dos veces, y no por donde se había escrito. No era el dpkg status del constructor: eran las listas de apt. Con las cacheadas en el squashfs, apt dice 0 not upgraded y no pide libnss3; la instalación de verdad decía 356. El instalador refresca las listas por la red de la sesión viva, así que la respuesta depende del día — que es la deriva del archivo, vista por dentro.

full-upgrade NO puede ser autosuficiente y no debe serlo. También murió anoche (rc=100), y meter libnss3 no lo arregla ni tiene que: querría los ~360 paquetes que el archivo ha movido. El bloque 11bis del seed existe para eso. Por eso la guarda no se lo exige.

Y LAS DOS INSTALACIONES DE LA NOCHE, QUE TUMBAN MÁS DE LO QUE CIERRAN (§4.62 (n) y (p)). Ninguna de las dos pagó la casilla, y las dos midieron algo:

Con red: la máquina salió COMPLETA con el medio de 28. ENCINA_ESTADO=COMPLETO, ENCINA_FALTA vacío. Porque esa vez SÍ había DNS en el chroot (rc=0, con su control). O sea que el fallo de §4.61 es INTERMITENTE: el mismo medio entrega una máquina entera una noche y una sin ningún paquete de Encina la siguiente, diciendo «listo para usarse» las dos veces. Se cae con ello una frase que este proyecto daba por establecida —«en el chroot no hay DNS, y eso es lo normal»—, que está en §4.61, aquí y en el propio seed.

Sin red: se cayó curtin en curthooks, ANTES de la late-command. Salió «Se produjo un problema» —y hay captura, la primera de esa pantalla en forma E3— pero no es nuestro exit 1: el seed no dejó ni estado ni registro y subiquity no lo nombra. No cuenta como control. Lo impidió el haber escrito que ENCINA_ESTADO va delante de la pantalla.

ASÍ QUE LA RED DE SEGURIDAD SIGUE SIN EJERCITARSE, y ahora se sabe por qué es difícil: el fallo de §4.61 necesita red en la sesión viva y sin DNS en el chroot a la vez, que es un estado que ocurrió solo y que no se sabe forzar.

LO QUE FALTA, EN ESTE ORDEN:

LA RED DE SEGURIDAD, POR SABOTAJE Y NO POR libnss3. La pregunta no es sobre el repo: es sobre el instrumento —¿una late-command que sale distinto de cero enseña la pantalla?—. Se contesta con red puesta (para que curtin termine) y con un seed que salga 1 a propósito. Y se puede hacer con el seed desatendido, o sea sin manos: es una medición del instrumento, no la casilla, así que la forma E2 no estorba aquí.

Instalar el medio bueno (cd84d2ec…, ya fabricado) y pasar el verificador buscando 0 fallos. Esto no está bloqueado por lo anterior: lo que la red de seguridad protege son las entregas futuras, no la validez de ésta, y para «¿se instala sin red?» ya está banco-autosuficiencia.sh.

Y ENTONCES —y no antes— los [OJOS] de Jorge y la foto del «después». Siguen bloqueados: sin encina-branding sería una captura que miente.

AL DÍA, 2026-08-22 (mañana): LA RED DE SEGURIDAD FUNCIONA. Ejercitada por sabotaje, con su control delante

El detalle en MEDICIONES.md §4.63, con la predicción escrita antes en 81568ca. Aciertos 6 de 6.

LO QUE SE DEMUESTRA, y es la casilla que llevaba desde el 20 sin poder pagarse: un seed que sale distinto de cero para la instalación y lo enseña. Sobre una copia del seed —nunca sobre imagen/encina-seed.sh— con la última línea cambiada a exit 1 incondicional:
CONTROL   (seed sin sabotear)   el seed acaba 09:33:03Z -> SE APAGA SOLA 09:33:18Z
SABOTAJE  (una linea distinta)  el seed acaba 09:53:57Z -> SIGUE ENCENDIDA a las 10:00
                                y en la pantalla: «Se produjo un problema»
Y lo que lo convierte en medición y no en susto: la máquina del sabotaje está COMPLETA. ENCINA_ESTADO=COMPLETO, ENCINA_FALTA vacío, los cuatro paquetes dentro, curtin terminado. No falta un .deb, no falla el repo, no hace falta DNS: la única diferencia con el control es el código de salida. Los dos registros del seed son el mismo trabajo —14 líneas distintas de 1906—.

Y arranca de su disco después de la pantalla, con GDM en español y el logotipo de la encina: la consecuencia 2 del comentario del propio seed, que hasta hoy sólo estaba leída en el código.

LO QUE NO DEMUESTRA, y se dice: está medido en forma E2. Que la pantalla salga igual en forma E3 sigue siendo una deducción —server.py:487,513 pone ERROR en las dos formas, y las 23 capas squashfs de la ISO oficial y del medio de Encina son idénticas byte a byte, medido con su control—. Y E3 de las premisas (que subiquity nombre a encina-seed en su registro) quedó NO MEDIDO: ese registro vive en la sesión viva y no se copia al objetivo si no hay final bueno.

DOS COSAS MÁS QUE SE LLEVA LA VUELTA:

El control hizo su trabajo y cazó un fallo del banco antes de gastar el sabotaje: dos discos virtio del mismo bundle anuncian el MISMO serial —UTM lo saca de los 20 primeros dígitos del Identifier, y los nuestros sólo se diferencian en el último—, y con eso el instalador borró la cabecera del volumen del seed a los 64 s. Trampa 49.

Un instrumento nuevo que quita manos: el registro de una instalación se lee en los BYTES de disco.img, desde el Mac. Las 1906 líneas del seed.log, el estado y los testigos, sin entrar en la máquina y sin canal FAT. Trampa 50. Para ejecutar dentro —el verificador— el canal sigue haciendo falta.

Y ESO YA ESTÁ PAGADO, EL MISMO DÍA: el medio bueno cd84d2ec… instalado en forma E3 con las cinco pantallas contestadas a mano, el canal FAT conectado después (trampa 20), y el verificador dentro como root:
[OK] 63   [FALLO] 0   [AVISO] 0   [OMIT] 0        <- §4.61 daba 41 y 20
encina-meta 0.2.1  encina-branding 0.1.15  encina-firefox-native 0.2.1  autofirma 1.9.1+encina4
ENCINA_ESTADO=COMPLETO   ENCINA_FALTA= (vacio)   REPO ELEGIDO -> /cdrom/encina-repo
El síntoma de §4.61 —el logotipo de GDM era el de Ubuntu— ya no está: la máquina arranca de su disco con la encina.

El único [FALLO] de la primera pasada era del INSTRUMENTO, y llevaba ocho días sin ejecutarse nunca: el bloque 8.5 sólo aceptaba iconos de /usr/share/icons/Yaru/, y nuestro propio index.theme pide Inherits=Yaru-sage,Yaru,hicolor, con Yaru-sage el primero. Los dos se escribieron el mismo día —1d24ac2 y c675c5d, 2026-08-14— contradiciéndose, y en MEDICIONES.md no aparece ni un [OK] ni un [FALLO] de esa línea. Corregido con control nuevo, porque ensanchar una lista blanca es fácil de ensanchar de más (§4.63q).

Y LOS [OJOS] TAMBIÉN, EL MISMO DÍA (§4.63s). Las seis capturas salen de la máquina de la entrega —no del banco— y con el control de dos pasadas:
01 firmware   1 fotograma en las dos  -> TRANSITORIA, no es una pantalla
02 apagada    sha256 6c8d7117… IDENTICO byte a byte
03 GDM        sha256 76c97e89… IDENTICO; 400 px, todos en la franja del reloj
Jorge aprobó cinco. El recuadro naranja de GDM queda aceptado como mal menor —deja de ser casilla y pasa a ser decisión escrita—. Y el par «antes / después» de la primera sesión ya sale en el README: «Le damos la bienvenida a Ubuntu» contra el escritorio de Encina OS entrando directo. De paso cayó una frase vieja del README que decía que el medio todavía lleva marca de Ubuntu.

LO ÚNICO QUE QUEDA DEL BLOQUE, Y NO SE PUEDE PAGAR AQUÍ: PLYMOUTH

Del segundo 8 al 21 la pantalla está apagada y el tema de arranque no se ve. Las dos hipótesis producen la misma captura: si es de UTM, el producto está bien; si es del producto, el arranque de Encina OS es más feo que el de Ubuntu, no más bonito. Aquí no se separan.

Condición de salida, y es una sola: instalar en hierro. Hasta entonces 02-pantalla-apagada.png no cuenta ni a favor ni en contra, y la casilla «Instalar desde cero y mirar la pantalla» se queda sin marcar a propósito, con las otras dos terceras partes de su condición pagadas y medidas.

LA TAREA SIGUIENTE, 2026-08-22 (cierre): amd64 (E6), Y NO PUBLICAR TODAVÍA

Esto cambia el orden que tenía escrito este documento hace tres horas, y lo cambia un dato de Jorge, no una opinión: el portátil donde puede instalar en hierro es Intel/AMD. Y el medio que existe es arm64 puro —bootaa64.efi, Volume Id: EncinaOS 0.2.1 arm64—, así que en ese portátil no arranca.

Las consecuencias, en cadena:

Plymouth no se puede contestar sin amd64. Su única condición de salida es el hierro, y el hierro que hay es Intel.

tareas/despues-de-publicar.md dice de E6: «No es prioridad. Necesita con qué probarlo». Esa razón ha CADUCADO — ya hay con qué probarlo. Una despriorización escrita cuyo motivo se cae se revisa, no se hereda.

Publicar primero sería publicar algo que su propio autor no puede probar en su máquina. No está prohibido, pero hay que decidirlo a sabiendas.

LO QUE CUESTA E6, MEDIDO ESTA NOCHE Y NO ESTIMADO — y es menos de lo que parecía:
los CUATRO paquetes de Encina son _all.deb   -> NO HAY QUE RECONSTRUIRLOS
    autofirma_1.9.1+encina4_all   encina-branding_0.1.15_all
    encina-firefox-native_0.2.1_all   encina-meta_0.2.1_all
el repo offline: 29 .deb = 14 _all + 15 _arm64  -> hay que cosechar QUINCE para amd64
fabricar-iso.sh nombra la arquitectura en 14 lineas (bootaa64/grubaa64/mmaa64 -> x64)
en todos los guiones: 29 lineas
Falta además la ISO base amd64 y un constructor amd64 —el actual es una VM arm64—, que puede ser el propio portátil.

Y UN RIESGO QUE HAY QUE NOMBRAR ANTES DE TOCAR HIERRO, y que en una VM nunca importó: tareas/despues-de-publicar.md declara que la instalación exige red y que meter el núcleo y linux-firmware en el medio cuesta 1 089 MB, de los cuales linux-firmware son 655. En una máquina virtual eso no se nota; en un portátil de verdad es el WiFi. No está medido aquí — está declarado allí—, y conviene medirlo antes de dar por fallida una instalación en hierro por un motivo que no sea el producto.

Lo que bloquea publicar sigue donde estaba —tareas/alojamiento.md, 3,46 GB que no caben en un release de GitHub, y tareas/publicar.md—, pero deja de ser lo siguiente.

Disco: 26,3 GiB. La VM encina-control-sinred (8,2 GiB) lleva la instalación reventada de curthooks y ya no hace falta: es la única que sobra, y borrarla es de Jorge.

Y una consecuencia que ya está escrita donde estaba citada: 59bc3a3c… deja de ser la huella que produce este repositorio, porque los dos arreglos entran en el medio. No es un fallo, es lo que pasa —ya pasó con 95758c9e…—. Por eso medios/encina-os-p10-capa.iso no se borró al hacer sitio: es el único ejemplar de lo que midieron §4.60 y §4.61.

LO ANTERIOR, 2026-08-21: LA REPRODUCIBILIDAD, PAGADA — y por partida doble

construir-todo.sh entero, dos pasadas, la misma huella (MEDICIONES.md §4.60). Era lo más viejo sin pagar: todos los medios salían de fabricar-iso.sh --repo, y la vuelta entre las dos máquinas estaba sin ejercitar.
pasada 1 -> medios/encina-os-r1.iso   sha256 59bc3a3c...e946e1d4   0 fallos
pasada 2 -> medios/encina-os-r2.iso   sha256 59bc3a3c...e946e1d4   0 fallos

[OK]    DOS PASADAS, LA MISMA HUELLA     <- la definicion de terminado
Y LA COINCIDENCIA QUE NO SE BUSCABA VALE MÁS QUE LAS DOS PASADAS: esa huella es la de p10-capa, fabricada el 20 por el otro camino, con fabricar-iso.sh --repo en local. Dos caminos distintos, en días distintos, el mismo medio bit a bit — el largo pasa por git archive HEAD, ssh al constructor Ubuntu, la cosecha de 28 .deb por huella y el Packages generado allí; el corto no sale del Mac. Es reproducibilidad cruzada: descarta que la huella dependa del camino, que es más de lo que pedía la casilla.

[OMIT], y lo dice el propio guion: que arranque. Con el 33 % de §4.59 de por medio eso exige contar, no un arranque. Como r1 es bit a bit p10-capa, lo que se sabe de este medio es lo que §4.59 midió: 4 de 6.

Y UNA TRAMPA DEL ENTORNO, cazada por su control (trampa 45): utmctl start empezó a dar OSStatus error -1712 con encina-dev parada, mientras list y status contestaban tan tranquilos. La conclusión fácil era «encina-dev está rota». El control —arrancar p11, que había arrancado 5 de 6 esa noche— falló igual: el sordo era UTM, y se destrabó con open -a UTM. Habría sido la quinta atribución falsa por el mismo camino.

EL DISCO, resuelto: de 10 GiB a 26. Se borraron p6-trozo, p12, p13 y p14 con sus VMs (14 GiB), y después r1 y r2 (7 GiB más), porque eran el mismo fichero que p10-capa —misma huella—. Se conserva p10-capa: es la que citan §4.58 y §4.59 por nombre y la única con VM registrada, así que se puede volver a arrancar sin fabricar nada. Quedan ocho ISOs.

LO SIGUIENTE:

Los dos [OJOS] de Jorge y las dos últimas casillas de tareas/aspecto/5-cierre.md. Es lo único que queda del incremento, y ya no hay nada delante: la capa se monta, la marca llega, el medio es reproducible y el banco está acotado. Capturas en medios/conteo-arranques/capturas/.

[OMIT] P5, el título de la ventana del instalador, sin medir.

Qué causa el 33 % del banco — acotado, no explicado, con la pista de §4.59f (un fallo exacto por ronda, post-hoc).

LO ANTERIOR, 2026-08-20 (noche): EL FALLO INTERMITENTE ES DEL BANCO, MEDIDO: 33 % Y LOS TRES MEDIOS. La capa queda LIMPIA

18 arranques, 6 rondas intercaladas, veredicto contado y no mirado (MEDICIONES.md §4.59). Era el [OMIT] que contaminaba cualquier medición de arranque en este anfitrión, y ya no lo es:
 brazo   la capa                        arranco
 p10     entera, montada                4 de 6
 p11     vacia, montada                 5 de 6
 p9      presente pero INERTE           3 de 6

 Fisher exacta de una cola, p10 contra p11+p9:  p = 0,6942   (umbral 0,05)
 [OMIT]  NO hay senal. Tasa global de fallo del anfitrion: 6 de 18 = 33 %
LOS TRES BRAZOS FALLAN, incluido p9, que lleva el squashfs dentro pero el núcleo no lo nombra —o sea que arranca como un medio sin capa—. La capa no afecta a la probabilidad de arrancar, y el brazo que sale peor en bruto es justo el de la capa inerte.

Y SE CAE DEL TODO LA CORRELACIÓN DE ubuntu-text.plymouth: era «los dos medios que necesitaron reintento son los dos que lo llevan», y hoy p11 y p9 lo necesitaron sin llevarlo. Con un 33 % de fallo, la tabla de §4.58 —1 de 3 en p10, 1 de 1 en tres medios— es lo que se espera por azar: la probabilidad de que un medio bueno dé 1 de 1 es 0,67. Los cuatro bisecados de ayer no midieron nada del producto.

EL MÉTODO, y es lo que hizo que esto valga: la predicción con sus probabilidades y su umbral se escribió antes de arrancar nada, y el veredicto y su banco antes del experimento —commit 6f04353, fechado antes del primer dato—. El criterio lo aplica veredicto-conteo.py, no yo: quince arranques con tasas cerca del 50 % se leen después como uno quiera.

CUATRO INSTRUMENTOS NUEVOS, todos con su banco y sus sabotajes:

guion qué hace su banco

scripts/veredicto-pantalla.py NEGRA/GRAFICA/INDETERMINADA contando colores, no bytes banco-veredicto.sh: 9 correctas, 0 fallos

scripts/banco-veredicto.sh control por columna, prueba de escala, 3 sabotajes —

scripts/contar-arranques.sh las rondas intercaladas, con la guarda de la trampa 13 —

scripts/veredicto-conteo.py aplica el criterio preinscrito, Fisher sin dependencias --banco: 8 correctas, 0 fallos

DOS COSAS QUE EL DÍA PRODUJO Y NO ESTABAN PREVISTAS, y las dos son mías:

Un fallo EXACTO en cada una de las seis rondas —ni cero, ni dos—, que bajo independencia es una entre 130. Es post-hoc, así que es hipótesis y no resultado, pero es la pista concreta para arreglar el banco en vez de rodearlo: los fallos no son independientes entre sí.

Un fallo de diseño mío (trampa 44): intercalar siempre en el mismo orden confunde el brazo con la posición. Hoy no cambia la conclusión —no hay efecto que esconder—, pero si hubiera salido señal no habría sabido de qué era. La próxima vez se baraja el orden dentro de la ronda.

LO SIGUIENTE, en este orden, y el primero ya no está bloqueado:

construir-todo.sh sigue SIN completarse con el árbol de hoy —todos los medios salieron de fabricar-iso.sh --repo, la vuelta entre las dos máquinas está sin ejercitar— y la segunda pasada de reproducibilidad sigue sin pagarse. Su definición de terminado no es «sale una ISO».

Los dos [OJOS] de Jorge y las dos últimas casillas de tareas/aspecto/5-cierre.md. Ahora hay de verdad qué mirar, y las capturas de los 18 arranques están en medios/conteo-arranques/capturas/.

[OMIT] P5, el título de la ventana del instalador, sin medir.

Y EL DISCO SIGUE MANDANDO: ~12 GiB y nueve ISOs. Este experimento no fabricó ninguna: los tres medios ya estaban en disco y las VMs registradas.

LO ANTERIOR, 2026-08-20 (cierre): LA CAPA SE MONTA. La casilla 3 está HECHA salvo los [OJOS]

LO QUE SE PEDÍA, HECHO Y MEDIDO DENTRO DE LA SESIÓN VIVA (MEDICIONES.md §4.58e). Del 2026-08-15 al 20 esa orden devolvía cero líneas:
encinaos@encinaos:~$ grep encina /proc/mounts
/cow / overlay rw,relatime,lowerdir=/minimal.standard.live.encina.squashfs:
/minimal.standard.live.squashfs:/minimal.standard.squashfs:/minimal.squashfs,…
SON DOS CAMBIOS Y NADA MÁS. La capa se llama minimal.standard.live.encina.squashfs —el nombre es la CADENA: casper la construye quitando puntos y hace panic si un eslabón no existe, así que el nombre no se elige, se hereda— y el grub.cfg lleva layerfs-path=, que pisa al LAYERFS_PATH del initrd (/init:94 lo lee, casper:909 lo reexporta: no hay que tocar el initrd).

Y LA MARCA YA LLEGA: en p12 y p13 el fondo de la sesión viva ya no es el de Ubuntu, es el nuestro. Es lo que la casilla 3 perseguía desde el 15.

LO QUE NO ESTÁ CERRADO, y no se cuela: con la capa entera (30 ficheros) la sesión gráfica no llega —pantalla negra con el cursor de Xorg, dos arranques, con systemd entero en [ OK ] y con IP en el arp—. Bisecado quitando piezas, que es la única forma que produce causas aquí:

medio qué lleva la capa resultado

p10-capa los 30 ficheros NEGRA, dos arranques

p11-vacia 1 fichero que no tapa nada escritorio entero + instalador

p12-sintexto 24: los 6 de texto fuera escritorio + fondo de Encina

p13-desktop 24 + ubuntu.desktop escritorio + fondo de Encina

p14-plymouth 24 + ubuntu-text.plymouth negra, y al 2º arranque ESCRITORIO

p10-capa los 30, otra vez negra, negra, y al 3º ESCRITORIO

LAS DOS ÚLTIMAS FILAS SON LA LECCIÓN DEL DÍA: la pantalla negra era el BANCO, no el producto. En este anfitrión el arranque gráfico falla a veces, y falla igual que un fallo de producto —negra, systemd entero en [ OK ], IP en el arp, debug.log en el rellano de ~92 K—. Con un solo arranque negro se escribió que ubuntu-text.plymouth era la causa; duró dos horas y la tumbó repetir el arranque (§4.58j–l). No queda ni un fichero bajo sospecha.

LAS CINCO PREDICCIONES, escritas antes de fabricar nada: cuatro aciertos y una sin medir. Leído dentro de p10, el medio de producto entero:
PRETTY_NAME="Encina OS 24.04 LTS"     images  slides  whitelabel.yml
NAME="Encina OS"   LOGO=encina-logo
El 2026-08-17 esas mismas órdenes daban NAME="Ubuntu" y «No existe el archivo». [OMIT]: P5, el título de la ventana del instalador — las capturas enseñan el título de la página, no el app-name.

LO SIGUIENTE, en este orden:

Acotar el fallo intermitente del banco. Contamina cualquier medición de arranque que se haga aquí, y hoy costó una causa falsa. Mientras siga, un «no arranca» hay que contarlo —N arranques y N de un control—; un «arranca» vale a la primera.

construir-todo.sh sigue SIN completarse con el árbol de hoy, y la segunda pasada de reproducibilidad sigue sin pagarse. Los medios de hoy salieron todos de fabricar-iso.sh --repo.

Los dos [OJOS] de Jorge y las dos últimas casillas de tareas/aspecto/5-cierre.md. Ahora hay de verdad qué mirar: la sesión viva ya lleva marca.

Y EL DISCO MANDA: quedan ~10 GiB y medios/ tiene nueve ISOs. No cabe otra bisección sin borrar, y qué se borra es de Jorge (p6-trozo está marcada como gastada). Ojo: borrar VMs no libera nada si su ISO es enlace duro, y fabricar-vm-medio.py se niega a fabricar si quedan menos de dos bundles con F6223E90.

LO ANTERIOR, 2026-08-20 (mañana): HAY MEDIO DE PRODUCTO QUE ARRANCA, CON NOMBRE Y VERSIÓN PROPIOS — lo que queda es la capa, la reproducibilidad y los [OJOS]

71f7958c… ARRANCA y enseña «Disposición del teclado» en español, fabricada sin --info-crudo: 0 fallos, 0 avisos, 1 1 1 1 (MEDICIONES.md §4.57h). Es el primer medio que lleva a la vez las dos cosas que hasta ayer eran incompatibles:
.disk/info : EncinaOS 24.04.4 LTS "Nutria Nocturna" - Release arm64 (20260210)
volid      : EncinaOS 0.2.1 arm64        <- NUESTRO nombre y NUESTRA version
rotulo     : Install EncinaOS 24.04.4 LTS
canal      : stable/ubuntu-24.04.4
LA CAUSA, CERRADA POR EXPERIMENTO: el instalador exige que /.disk/info lleve un nombre en clave entre comillas; el contenido da igual ("A B" vale igual que "Noble Numbat"), el LTS solo no basta, y la primera palabra puede ser la nuestra. Ocho ficheros medidos, en §4.57e.

LA DERIVACIÓN DE §4.53 SE HA ROTO, y sin reintroducir «el nombre en dos sitios»: el Volume id no se escribe, se compone de la 1ª palabra de .disk/info (única fuente del nombre) + la versión de encina-meta (cotejada por huella en el paso 2) + la arquitectura. Con su banco y su sabotaje gastado.

EL CODENAME ES UN ESQUEMA: dos palabras aliteradas como Ubuntu, pero en español, con fauna de dehesa —el bosque de encinas— y con la inicial atada a la base (N de Noble), así que dice sobre qué Ubuntu va. ASCII a propósito.

LO QUE QUEDA, y no es poco:

LA CAPA NO SE MONTA (§4.54e). Sin eso no hay marca en la sesión viva: ni fondo, ni título de ventana, ni diapositivas, ni os-release. Candidato medido: layerfs-path= en la línea del núcleo del grub.cfg.

La segunda pasada de reproducibilidad, que sigue sin pagarse.

Los dos [OJOS] de Jorge y las dos últimas casillas de tareas/aspecto/5-cierre.md.

[OMIT] que no se cuela: si un codename de una sola palabra vale, y si vale con tildes o eñes. Ninguna hace falta para el producto tal como queda.

LO ANTERIOR, 2026-08-19 (cierre): la causa, cerrada — un nombre en clave entrecomillado

PROBADO QUITANDO Y PONIENDO (MEDICIONES.md §4.57e). Ocho ficheros:

.disk/info campos instalador

Ubuntu 24.04.4 LTS "Noble Numbat" - Release … 9 funciona (el oficial)

EncinaOS 24.04.4 LTS "Noble Numbat" - Release … 9 funciona

EncinaOS 24.04.4 LTS "A B" - Release … 9 FUNCIONA — codename NUESTRO

EncinaOS 24.04.4 LTS - Release … 7 se cae

Ubuntu 24.04.4 - Release … 6 se cae

EncinaOS 24.04.4 - Release … 6 se cae

EncinaOS 0.2.1 - Release … 6 se cae

Encina OS 0.2.1 - Release … 7 se cae

El LTS solo no basta. La primera palabra puede ser la nuestra. El contenido del codename da igual. Y ni el canal, ni el Volume id, ni el separador, ni el paréntesis tenían nada que ver: murieron todos por experimento.

ESTO DESBLOQUEA TODO LO QUE §4.56 DABA POR BLOQUEADO:
NO hace falta «Noble Numbat»       -> la casilla 2 ni se toca
NO hace falta romper la derivacion -> «EncinaOS 24.04.4 LTS "A B" arm64» = 32 bytes, CABE
NO hace falta --info-crudo         -> es cadena de PRODUCTO: 0 avisos, volid nuestro
construir-todo.sh deja de parar en el 5e
LO QUE QUEDA ES CRITERIO DE JORGE, NO MEDICIÓN:

El nombre en clave de verdad. Presupuesto durísimo: con EncinaOS delante caben 5 bytes de codename ("A B" y nada más); con Encina, 7 (Encina 24.04.4 LTS "Roble" arm64 = 32, … "Ab Cd" arm64 = 32).

Si aun así se rompe la derivación, porque el Volume id arrastra el LTS y las comillas: el USB se rotula EncinaOS 24.04.4 LTS "A B" arm64. Cabe, pero es feo. Ya no es obligatorio; es estética de producto.

[OMIT]: no está medido si un codename de una sola palabra vale —los tres que arrancan llevan dos—. Cuesta un medio.

Y detrás siguen, sin tocar: que la capa no se monta (§4.54e), la segunda pasada de reproducibilidad, y los [OJOS].

LO ANTERIOR, 2026-08-19 (tarde): la causa acotada a LTS "Noble Numbat", que resultó ser sólo las comillas

CERRADA POR EXPERIMENTO (MEDICIONES.md §4.56cc). Se probó quitando y poniendo, no leyendo:

.disk/info campos instalador

Ubuntu 24.04.4 LTS "Noble Numbat" - Release … 9 funciona (el oficial)

EncinaOS 24.04.4 LTS "Noble Numbat" - Release … 9 FUNCIONA — con NUESTRO nombre

Ubuntu 24.04.4 - Release … 6 se cae

EncinaOS 24.04.4 - Release … 6 se cae

EncinaOS 0.2.1 - Release … 6 se cae

Encina OS 0.2.1 - Release … 7 se cae

Dos cosas cerradas de un golpe: la causa es la ausencia de ese trozo, y EncinaOS como primera palabra NO tumba el instalador —las dos filas de 9 campos sólo se diferencian en ella y las dos arrancan—. Por el camino murieron tres hipótesis por experimento: el canal, el sabor y, ayer, la capa, el Volume id y el menuentry.

LO SIGUIENTE, Y ES UNA CONSECUENCIA MEDIDA, NO UNA OPCIÓN: hay que ROMPER LA DERIVACIÓN de §4.53. El .disk/info que arranca da un Volume id derivado de 41 bytes contra los 32 del PVD (§4.56q: con el nombre en clave real no cabe ningún nombre de producto, ni la cadena vacía). El medio de hoy sólo se pudo fabricar porque --info-crudo hace viajar el volumen oficial, así que NO es entregable: dice Ubuntu en el nombre del volumen. Para tener a la vez el fichero que arranca y un Volume id propio, el Volume id tiene que dejar de salir de .disk/info.

Y HAY UNA DECISIÓN DE PRODUCTO QUE ES DE JORGE: el fichero que funciona lleva LTS "Noble Numbat", el nombre en clave de Ubuntu, dentro de la cadena del producto. Es terreno de la casilla 2.

[OMIT] que no se cuela como hecho: cuál de los tres —el LTS, las comillas o el número de campos— es el que importa no está medido; el trozo los restaura a la vez. Lo separa Ubuntu 24.04.4 LTS - Release … (7 campos).

Instrumento nuevo: --info-crudo, para medios de diagnóstico: las tres guardas de marca dejan de parar pero se siguen evaluando y lo dicen, con el .disk/info del producto como control. Sin ella nada de esto se podía fabricar.

Y UN PATRÓN QUE YA NO ES SOSPECHA: cuatro atribuciones falsas seguidas construidas igual —mecanismo leído + control + caso que falla—. Esa forma no produce causas aquí. Marcador de predicciones de la sesión: 1 de 4.

LO ANTERIOR, 2026-08-19 (tarde, a medias): el bisecado baja a un solo trozo

TRES HIPÓTESIS MUERTAS POR EXPERIMENTO EN UNA SESIÓN (MEDICIONES.md §4.56), las tres con predicción escrita antes de arrancar y las tres falsas:

.disk/info campos instalador

Ubuntu 24.04.4 LTS "Noble Numbat" - Release … 9 funciona (el oficial)

EncinaOS 24.04.4 - Release … d81586ae 6 se cae — muere el CANAL

Ubuntu 24.04.4 - Release … 9b1194b9 6 se cae — muere el SABOR

El canal stable/ubuntu-24.04.4 es el del medio oficial, que funciona, y aun así se cae. Y con Ubuntu de primera palabra —sabor válido— también. El separador y el paréntesis están iguales en los dos lados. Queda LTS "Noble Numbat", y las comillas están en el único que funciona y faltan en los cuatro que se caen.

LO QUE YA SE PUEDE DAR POR CERRADO SIN SABER CUÁL GANA: §4.56q mide que con el nombre en clave real no cabe NINGÚN nombre de producto en el Volume id —ni la cadena vacía: LTS "Noble Numbat" consume los 32 bytes enteros—. Así que si gana el trozo, la derivación no cabe; y si gana la primera palabra, el nombre no puede ir en el fichero. En los dos casos hay que romper la derivación que §4.53 unió, y la «tercera vía» de §4.56a deja de ser opcional.

LO QUE FALTA: el medio EncinaOS 24.04.4 LTS "Noble Numbat" - … (b7d287f7), ya fabricado con --info-crudo y sin arrancar todavía: tres intentos, tres pantallas negras con el sistema vivo (log a 92 204 B e IP), que por la trampa 38 no es un resultado. Contesta si nuestro nombre vale una vez restaurado el trozo. Y detrás, separar cuál de los tres —LTS, comillas o recuento— es, con Ubuntu 24.04.4 LTS - Release … (7 campos).

INSTRUMENTO NUEVO: --info-crudo, para medios de diagnóstico. Las tres guardas de marca dejan de parar pero se siguen evaluando y lo dicen, con el .disk/info del producto como control. Sin ella estos medios no se podían fabricar.

Y UN PATRÓN QUE YA NO ES SOSPECHA: van cuatro atribuciones falsas seguidas hechas igual —mecanismo leído + control + caso que falla—. Esa forma no produce causas en este proyecto.

LO ANTERIOR, 2026-08-19 (mañana): EL BISECADO CIERRA — LA CAUSA ES /.disk/info, y lo que falta es saber POR QUÉ y decidir el precio

SE BISECÓ D23 Y HAY RESPUESTA (MEDICIONES.md §4.55). Primero hizo falta el instrumento: fabricar-iso.sh tiene ahora una bandera por mecanismo —--sin-capa, --sin-volid, --sin-info, --sin-menu— y un paso 13 que abre la ISO terminada y comprueba que lleva lo que se pidió, porque todas las demás comprobaciones del guion sacan sus expectativas de la misma bandera que dicen comprobar. Ese lector tiene banco propio de segundos, imagen/banco-mecanismos.sh, con su control gastado.

ISO capa volid info menu instalador

e8a0ead2… 1 1 1 1 se cae

26bf5442… --sin-capa 0 1 1 1 se cae

08392ddc… --sin-volid 1 0 1 1 se cae

4f856618… --sin-info 1 1 0 1 FUNCIONA — «Disposición del teclado»

La capa, el Volume id y el menuentry quedan exonerados POR EXPERIMENTO. Y esto no es lo de §4.54h —mecanismo leído más control más caso que falla, que salió falso—: es quitar una pieza y ver arrancar lo que no arrancaba.

LO QUE FALTA, EN ESTE ORDEN:

Saber POR QUÉ, que no está medido. El candidato sigue siendo el canal de snap de refresh.py, y ahora se ve el agujero de §4.54i: comparó stable/ubuntu-OS con stable/ubuntu-0.2.1, dos canales que no existen ninguno de los dos, así que aquel descarte no valía. La prueba es un .disk/info nuestro cuya segunda palabra sea 24.04.4.

DECIDIR EL PRECIO, Y ES DE JORGE. Esa palabra manda a la vez en el canal, en el rótulo del icono (Install <dos primeras palabras>) y, por derivación, en el Volume id. Con 24.04.4 el medio se rotula «Install EncinaOS 24.04.4» y el volumen «EncinaOS 24.04.4 arm64». La alternativa es romper la derivación que §4.53 unió a propósito.

Y sigue en pie que LA CAPA NO SE MONTA (§4.54e), que es cosa aparte del instalador: sin resolverlo no hay marca en la sesión viva. El candidato medido es layerfs-path= en la línea del núcleo del grub.cfg.

Dos cosas del banco que hay que tener delante: «se ve el instalador» es señal positiva y basta una vez; «pantalla negra» NO es un resultado —salió en tres medios, uno de los cuales arrancó al tercer intento—. Y el _ no llega al invitado: llega como ?, que es comodín del shell (trampa 35).

LO ANTERIOR, 2026-08-17 (tarde): LA CAPA NO SE MONTA — la vuelta única se dio, y tumbó la casilla 3

LA VUELTA ESTÁ DADA Y LOS PASOS 1 Y 2 SALIERON LIMPIOS A LA PRIMERA (MEDICIONES.md §4.54): encina-branding 0.1.15 construido y cotejado por huella (6d9fcd64…, 88 comprobaciones y 0 fallos entre los tres guiones), y la ISO reproducible, ac175f64…, 3 721 265 152 bytes, dos pasadas la misma huella con el control de que la comparación sabe decir «distintas». Los bloques 5e y 11 pasaron en su sitio, y el Volume id se predijo antes de mirarlo y salió el mismo: Encina OS 0.2.1 arm64.

PERO EL PASO 3 —arrancarla— TUMBA LA CASILLA 3 ENTERA: la capa de marca NO SE MONTA NUNCA. Medido dentro de la sesión viva, no deducido:
encina@encina:~$ grep zz-encina /proc/mounts          <- ni una línea
encina@encina:~$ ls /usr/share/desktop-provision/     <- no existe
encina@encina:~$ cat /etc/os-release                  <- NAME="Ubuntu"
La causa, leída en el casper de este mismo medio: hay dos ramas, y la del glob *.squashfs —la que §4.52 describía— sólo corre si $LAYERFS_PATH está vacío. No lo está: vale minimal.standard.live.squashfs, puesto en /conf/conf.d/default-layer.conf dentro del initrd. La lista de capas se construye quitando puntos del nombre, y el lowerdir del invitado lo enseña: minimal.standard.live → minimal.standard → minimal, tres y ni una más. §4.52 buscó layerfs-path —la grafía de la línea de órdenes—, sacó 0, y era verdad; la variable de dentro se llama LAYERFS_PATH y vive en un cpio comprimido. El zz- del nombre no sirve de nada.

LO QUE SIGUE EN PIE, y no es poco: .disk/info funciona —whoami da encina— y el grub.cfg también. Los otros tres mecanismos de D23 están verificados en el medio.

Y UN SEGUNDO HALLAZGO: EL INSTALADOR SE CAE, ES NUESTRO, Y LA CAUSA ESTÁ LEÍDA EN EL CÓDIGO (§4.54h, enmienda del mismo día). El control se gastó y ac0a5721… arranca y enseña el instalador; la nuestra no, en dos arranques distintos. La causa está en subiquity/server/controllers/refresh.py:
release = info.split()[1]                       # de /cdrom/.disk/info
return ("stable/ubuntu-" + release, ...)
La SEGUNDA PALABRA de .disk/info no es un nombre: es el número de versión, y con ella se construye el canal de snap del instalador. Ubuntu 24.04.4 … da 24.04.4; Encina OS 0.2.1 … da OS, o sea el canal stable/ubuntu-OS. Eso explica que el fallo sea silencioso: ni volcado, ni error en el journal, ni Traceback.

Y los dos controles anteriores no valían: los rompí yo. Los tres bundles que fabriqué compartían los Drive.Identifier, y con eso la VM arranca y se cuelga antes de nada —pantalla negra y el debug.log de QEMU congelado en 2 759 bytes—. Con identificadores propios arrancó a la primera.

ENMIENDA DE LA MISMA TARDE (§4.54i): ESA CAUSA ERA FALSA. Se rehízo el medio con EncinaOS 0.2.1 —segunda palabra 0.2.1, canal stable/ubuntu-0.2.1— y el instalador se cae igual (e8a0ead2…). El mecanismo de refresh.py es real y stable/ubuntu-OS era un defecto de verdad, así que el cambio se queda; lo falso era la atribución.

LO QUE SÍ ACOTA ES EL BISECADO, tres ISOs en bundles idénticos:

ISO Qué lleva de más Instalador

ac0a5721… la entregada de E4 funciona

1224b5b1… .deb y seed nuevos, sin D23 funciona

e8a0ead2… + los mecanismos de D23 se cae

La regresión está DENTRO de D23, no en los .deb, ni en el seed, ni en el banco. Quedan tres sospechosos: la presencia de /casper/zz-encina.squashfs —el más gordo, porque es lo único que añade un fichero a /casper—, el Volume id y el resto de .disk/info.

LO SIGUIENTE, EN ESTE ORDEN:

Bisecar D23, y para eso fabricar-iso.sh necesita una bandera por mecanismo —hoy no sabe fabricar sin capa ni sin Volume id—. Empezar por quitar la capa: si con eso arranca, la casilla 3 tiene que resolver dos cosas a la vez, que la capa se monte y que su presencia no tire el instalador.

Decidir por dónde entra la marca de la sesión viva, ahora que la capa suelta no vale. El candidato medido es layerfs-path= en la línea del núcleo del grub.cfg —fichero nuestro, que ya reescribimos— encadenando minimal.standard.live.encina.squashfs. No está probado.

El inventario da verdes falsos para todo lo que aporta la capa: dice «ya no dice Ubuntu» de ficheros que el sistema en marcha no ve. Hay que enseñarle la diferencia entre está en el medio y se monta.

LO QUE SIGUE DEBAJO ES EL ESTADO DE ESTA MAÑANA, y se deja porque explica por qué se llegó hasta aquí — pero su afirmación de que la casilla 3 estaba hecha es la que se acaba de caer.

tareas/marca-del-medio.md está HECHA en lo que se puede hacer sin arrancar: las 4 casillas, 4 de 4 (eran 5, y la del logotipo de la rejilla resultó ser una copia rancia de una ya cerrada). Lo que queda de ese bloque no es trabajo de agente: es un [OJOS] de Jorge, y se cobra en la misma vuelta que las dos últimas casillas de tareas/aspecto/5-cierre.md. Sigue siendo lo que bloquea publicar, junto con los 3,46 GB del alojamiento.

LO QUE HAY QUE HACER, Y EN ESTE ORDEN:

Construir encina-branding 0.1.15 en la VM, porque no está en el disco: en debian-packages/ sólo hay 0.1.7, 0.1.12 y 0.1.13, y la huella que exige fabricar-iso.sh es 6d9fcd64…. Sin esto no se puede fabricar nada, y por eso fabricar-iso.sh no se ha podido ejecutar entero desde el 2026-08-15.

Refabricar la ISO con construir-todo.sh. Su definición de terminado no es «sale una ISO»: es que dos pasadas den la misma huella. Las dos piezas nuevas ya están medidas por separado y las dos son reproducibles —la capa (§4.52e, con su control dentro del guion) y el Volume id (§4.53c)—, pero la ISO entera con las dos dentro no se ha construido ni una vez.

Instalarla y MIRARLA. Es donde se cobran, todos a la vez, el [OJOS] de la casilla 3 —fondo, rótulo e icono del instalador, botón de la rejilla, Acerca de, título de la ventana, dibujos de las páginas y las tres diapositivas; y en máquina de verdad, el menú de GRUB—, el de la casilla 4 —que el medio arranque con el nombre nuevo— y las dos últimas casillas de 5-cierre.md. La orden que separa «la capa no se montó» de «no me gusta» es grep zz-encina /proc/mounts && cat /etc/os-release && whoami.

LA CUARTA CASILLA, HECHA EL 2026-08-17 (MEDICIONES.md §4.53), y su premisa era falsa: el instalador NO usa el nombre del volumen para encontrarse a sí mismo. El medio se llama Encina OS 0.2.1 arm64, derivado de marca/disk-info y no escrito a mano.

Lo primero fue leer quién usa hoy ese nombre, antes de tocarlo, en el código que viaja en el medio: casper encuentra el medio por contenido —¿hay algún *.squashfs en /casper?— y desempata por UUID; apt-cdrom saca el nombre de .disk/info; y subiquity va toda por la ruta /cdrom.

Y lo que podía tumbar la casilla estaba sin medir y sale a favor: el grubaa64.efi FIRMADO hace search --file --set=root /.disk/info, no search --label — leído en el grub.cfg empotrado en su squashfs interno, con search --label a 0 apariciones. La cadena de arranque cuelga del mismo fichero que este proyecto ya reescribe.

La comprobación que decide: contra un medio de control remasterizado sin tocar el nombre, la diferencia son 88 bytes de 3 715 235 840, todos dentro del campo del nombre de los cuatro descriptores. 17 correctas, 0 fallos, y sin precio: md5sum.txt no cubre el PVD y no hay que rehacerlo.

Se resuelve la trampa que la casilla pedía resolver: el paso 10 de fabricar-iso.sh —su comprobación más fuerte— era ciego a este cambio, porque compara fichero a fichero y el Volume id no es un fichero. Hay un paso 11 que lee todos los descriptores.

Y dos defectos salieron de EJECUTAR los bloques nuevos, que hubo que ejecutar aparte porque el guion entero hoy se niega: el nombre se cortaba por número de palabras y se truncaba en silencio; y el número de descriptores no es del formato —la oficial tiene 2 primarios y 2 Joliet, la nuestra 4 y 0—, de donde sale un hallazgo que nadie había medido: remasterizar se lleva el Joliet por delante, y eso pasa desde E3.

LA TERCERA CASILLA, HECHA EL 2026-08-15 SALVO EL [OJOS] (MEDICIONES.md §4.52): aquí sí se tocó el producto, y la pregunta de fondo del bloque está contestada — es D23.

«Reempaquetar o E5» eran dos opciones que resultaron no ser las dos. La marca del medio se pone con los mecanismos que Ubuntu ya trae, y la razón está medida y no admite discusión: el medio no lleva layerfs-path=, así que casper monta todos los *.squashfs de /casper y el último por orden alfabético manda — o sea que una capa de 3 084 288 bytes tapa a una de 1 692 274 688, 549 veces menos. E5 deja de ser lo que desbloquea publicar.

Los dos [OMIT] de §4.51, contestados sobre el código del commit exacto con el que se construyó el snap — y uno estaba MAL PLANTEADO. {{ DISTRO }} no sale de .disk/info ni de os-release: es una constante compilada en el binario, y la única llave que existe (flavor) sólo admite uno de los once sabores de Ubuntu. Las diapositivas se sustituyen, no se parchean. El otro abre la puerta entera: el whitelabel.yml se apunta desde fuera del snap —/usr/share/desktop-provision/, documentado por la propia Canonical— y con él el título de la ventana (app-name), las diapositivas y los dibujos de cada página, sin tocar el snap firmado.

El inventario baja de 31 a 24 apariciones, con los OCHO sitios nombrados uno a uno y 0 fallos en los dos lados. La cuenta no cuadra a propósito: la línea de os-release sigue contando porque dice ID=ubuntu, que D22 manda dejar.

Y el instrumento sacó dos defectos suyos al usarlo: contaba sitios y no valores, así que el número no podía bajar nunca; y su control caducó justo al mejorar el producto, dando un [FALLO] que se leía como instrumento roto.

LO QUE FALTA DE ESTA CASILLA, y no se da por bueno: el splash del arranque —watermark.png y bgrt-fallback.png viven en el initrd, antes de que exista ninguna capa, así que exigen reescribirlo— y el [OJOS]: nadie ha visto nada de esto en pantalla. Se paga en la vuelta única, detrás de la casilla 4.

LA SEGUNDA CASILLA, CERRADA EL 2026-08-15: los términos de Canonical están leídos y lo que obligan está escrito — es D22, con las citas literales en §2.1. Es la única casilla del bloque sin comando que la demuestre, así que lo que la hace verificable es la forma: fuente, fecha de consulta, redirección y huella del texto, y lo leído separado de lo interpretado. Tres cosas que cambian el trabajo que viene:

«Marca no es cadena», y con eso los 39 sitios de §4.51 se reparten en tres pilas: lo que presenta el producto ante el usuario sale; los activos gráficos de Canonical salen aunque no se vean; y la procedencia técnica —ID=ubuntu, los 155 nombres de .deb, Origin: Ubuntu del Release firmado— se queda, y quedarse es lo correcto. Sin este reparto la casilla siguiente no tiene criterio para parar.

La fórmula de atribución es NUESTRA, no de ellos. La política no contiene «derived from Ubuntu» ni ninguna otra autorizada, y no existe ningún documento de Canonical para derivadas (27 entradas en su índice legal, ninguna lo es). Lo que concede es referenciar sin implicar aval.

La ISO de hoy no se puede publicar, y el bloqueo tiene nombre: no son los 60 bytes de .disk/info, son los logotipos dentro del snap firmado de 109 MB. D22 no resuelve la pregunta de fondo del bloque —reempaquetar o E5—: la endurece.

Y dos efectos fuera del bloque: os-release sale a medias de §8 —lo decidido es qué campos cambian; sigue fuera el mecanismo, porque el os-release del medio vive dentro de una capa de 1,69 GB y un dpkg-divert desde un .deb no lo alcanza—, y D6 queda acotada, no debilitada: cubre ID y nunca cubrió NAME.

LA PRIMERA CASILLA, CERRADA HOY (MEDICIONES.md §4.51): el medio dice Ubuntu en 39 sitios, y están todos con su fichero, su cadena y dónde se ve. Leídos sobre 1224b5b1… sin arrancarla y sin gastar VM, con 6 controles delante y 0 fallos, y con instrumento que se queda: imagen/inventario-marca.sh. Lo que hay que saber antes de abrir la siguiente:

El rótulo del icono del instalador no está escrito: se calcula desde /.disk/info —casper-bottom/25adduser, medido con su control: un .disk/info de Encina da Name=Install Encina OS—. Son 60 bytes.

La sesión viva no lleva NI UN fichero de Encina (0, con el control de que el mismo recuento sobre ubuntu da 4 450). encina-branding se instala en el objetivo y no llega al medio: el fondo, el dock y el botón de la rejilla que rodean al instalador son Ubuntu de fábrica, y el fondo vive dentro de una capa de 1,69 GB.

El instalador es un snap de 109 MB —ubuntu-desktop-bootstrap 495— con las diapositivas, los logotipos y el título dentro. Es la frontera real del reempaquetado, y refuerza la decisión de fondo que la tarea ya planteaba (¿reempaquetado o E5?). Trae un whitelabel.yml que mapea cada página a su imagen, y que nadie había nombrado en este repositorio.

Y dos cosas sin medir, escritas a propósito: cuál de las dos fuentes rellena {{ DISTRO }} —/cdrom/.disk/info o /etc/os-release, los dos literales están en el binario— y si el whitelabel.yml se puede apuntar desde fuera del snap.

Lo siguiente es la casilla 4: el nombre del volumen de la ISO, que hoy dice Ubuntu 24.04.4 LTS arm64 … porque el instalador usa el nombre del volumen para encontrarse a sí mismo. HECHA EL 2026-08-17, y la frase que la justificaba era falsa (§4.53a): ni el instalador ni casper ni el GRUB firmado miran la etiqueta. Ya no queda ninguna casilla del bloque; lo que queda es la vuelta única, que es la tarea de arriba.

Por qué le toca ahora: aspecto/ ha cumplido su turno. El 2026-08-15 Jorge dio por bueno lo visual —«como está, está bastante bien, y ya le da un toque personal»— y de sus 16 abiertas quedan 5, todas en tareas/aspecto/5-cierre.md: los bloques 0, 2, 3 y 4 están cerrados enteros y el 1 aplazado por escrito. No se cerraron construyendo nada — se cerraron leyéndolas hasta el final, y las pruebas ya estaban en el disco.

Y el orden de lo que queda, con el argumento de siempre —el precio es por vuelta y no por cambio—: las dos últimas casillas de 5-cierre.md —refabricar la ISO, e instalarla y mirarla— se pagan DESPUÉS de la marca del medio, y una sola vez. Refabricar ahora para meter encina-branding 0.1.15 y otra vez dentro de unos días para meter la marca es pagar dos veces la misma vuelta.

Lo que hay que saber antes de tocar nada, y es de hoy:

NINGUNA DE LAS TRES ISOs DE medios/ ESTÁ AL DÍA, y son tres cosas distintas — medidas con shasum el 2026-08-15, no deducidas del nombre:

Fichero Huella Qué es

encina-os-E4-es-0.2.1.iso ac0a5721… La entregada de E4, y la única de las tres que alguien ha arrancado e instalado (§4.35)

~~encina-os-E4-es-0.2.1-95758c9e.iso~~ 95758c9e… La primera que salió reproducible de este repositorio (§4.39). Nunca arrancada. BORRADA el 2026-08-15 con permiso de Jorge — y df devolvió CERO, porque era un clon de la copia que vive dentro de encina-95758c9e.utm (§4.50). Sigue en disco ahí, y reproducible desde git

encina-os-E4-es-0.2.1-1224b5b1.iso 1224b5b1… La última que produce este repositorio, con encina-branding 0.1.11 dentro (§4.45). Nunca arrancada

O sea que 1224b5b1… es la que ha caducado hoy: lleva 0.1.11 y la buena es 0.1.15 (6d9fcd64…). 95758c9e… ya estaba superada antes.

Se entregan dos cosas naranjas, a propósito y por escrito. El recuadro de selección de usuario de GDM y —fuera de esto— el icono de la Ayuda. El de GDM no se arregla con el acento: el saludador es gnome-shell, el tema del shell de Yaru no tiene variantes, y cambiarlo exige reempaquetar gnome-shell-theme.gresource, que choca con R5. Está medido con captura en tareas/aspecto/4-arranque-y-sesion.md.

El tema de arranque de Encina no lo ha visto nadie. En UTM la pantalla del invitado está apagada todo el arranque. Es un límite del banco, no un resultado sobre el producto, y se levanta arrancando la ISO en una máquina de verdad — o sea en el paso «instalar desde cero y mirar».

El Mac de 2015 es Intel y NO arranca esta ISO, que es arm64. Lo que sí hace es tumbar el motivo escrito de D9: ya hay con qué probar amd64, así que E6 pasa de «no se puede medir» a «no es la prioridad».

guion	qué hace	su banco
`scripts/veredicto-pantalla.py`	`NEGRA`/`GRAFICA`/`INDETERMINADA` contando colores, no bytes	`banco-veredicto.sh`: 9 correctas, 0 fallos
`scripts/banco-veredicto.sh`	control por columna, prueba de escala, 3 sabotajes	—
`scripts/contar-arranques.sh`	las rondas intercaladas, con la guarda de la trampa 13	—
`scripts/veredicto-conteo.py`	aplica el criterio preinscrito, Fisher sin dependencias	`--banco`: 8 correctas, 0 fallos

medio	qué lleva la capa	resultado
`p10-capa`	los 30 ficheros	NEGRA, dos arranques
`p11-vacia`	1 fichero que no tapa nada	escritorio entero + instalador
`p12-sintexto`	24: los 6 de texto fuera	escritorio + fondo de Encina
`p13-desktop`	24 + `ubuntu.desktop`	escritorio + fondo de Encina
`p14-plymouth`	24 + `ubuntu-text.plymouth`	negra, y al 2º arranque ESCRITORIO
`p10-capa`	los 30, otra vez	negra, negra, y al 3º ESCRITORIO

`.disk/info`	campos	instalador
`Ubuntu 24.04.4 LTS "Noble Numbat" - Release …`	9	funciona (el oficial)
`EncinaOS 24.04.4 LTS "Noble Numbat" - Release …`	9	funciona
`EncinaOS 24.04.4 LTS "A B" - Release …`	9	FUNCIONA — codename NUESTRO
`EncinaOS 24.04.4 LTS - Release …`	7	se cae
`Ubuntu 24.04.4 - Release …`	6	se cae
`EncinaOS 24.04.4 - Release …`	6	se cae
`EncinaOS 0.2.1 - Release …`	6	se cae
`Encina OS 0.2.1 - Release …`	7	se cae

`.disk/info`	campos	instalador
`Ubuntu 24.04.4 LTS "Noble Numbat" - Release …`	9	funciona (el oficial)
`EncinaOS 24.04.4 LTS "Noble Numbat" - Release …`	9	FUNCIONA — con NUESTRO nombre
`Ubuntu 24.04.4 - Release …`	6	se cae
`EncinaOS 24.04.4 - Release …`	6	se cae
`EncinaOS 0.2.1 - Release …`	6	se cae
`Encina OS 0.2.1 - Release …`	7	se cae

`.disk/info`	campos	instalador
`Ubuntu 24.04.4 LTS "Noble Numbat" - Release …`	9	funciona (el oficial)
`EncinaOS 24.04.4 - Release …` `d81586ae`	6	se cae — muere el CANAL
`Ubuntu 24.04.4 - Release …` `9b1194b9`	6	se cae — muere el SABOR

ISO	capa volid info menu	instalador
`e8a0ead2…`	1 1 1 1	se cae
`26bf5442…` `--sin-capa`	0 1 1 1	se cae
`08392ddc…` `--sin-volid`	1 0 1 1	se cae
`4f856618…` `--sin-info`	1 1 0 1	FUNCIONA — «Disposición del teclado»

ISO	Qué lleva de más	Instalador
`ac0a5721…`	la entregada de E4	funciona
`1224b5b1…`	`.deb` y seed nuevos, sin D23	funciona
`e8a0ead2…`	+ los mecanismos de D23	se cae

Fichero	Huella	Qué es
`encina-os-E4-es-0.2.1.iso`	`ac0a5721…`	La entregada de E4, y la única de las tres que alguien ha arrancado e instalado (§4.35)
~~`encina-os-E4-es-0.2.1-95758c9e.iso`~~	`95758c9e…`	La primera que salió reproducible de este repositorio (§4.39). Nunca arrancada. BORRADA el 2026-08-15 con permiso de Jorge — y `df` devolvió CERO, porque era un clon de la copia que vive dentro de `encina-95758c9e.utm` (§4.50). Sigue en disco ahí, y reproducible desde `git`
`encina-os-E4-es-0.2.1-1224b5b1.iso`	`1224b5b1…`	La última que produce este repositorio, con `encina-branding` 0.1.11 dentro (§4.45). Nunca arrancada

E3 TERMINADO el 2026-08-10, 9 de 9 (§4.25), y con él la entrega existe: hay una ISO —encina-os-E3-es.iso, 02ab929d…— que se le puede dar a alguien, que recibe en español, y que deja una máquina de Encina OS contestando solo las cinco pantallas que pregunta Ubuntu.

LA MEDICIÓN DE APERTURA DE E4 ESTÁ HECHA, el 2026-08-11 (§4.26), y el criterio general de §10 no lo suprime: lo redefine. Lo que le falta a la máquina de la entrega está nombrado con su comando —ofimática, escáner y ninguna forma de instalar nada—, y el hueco grande no es qué aplicaciones, es que la máquina no puede crecer.

LA VUELTA DE E4 ESTÁ DADA, el 2026-08-12 (MEDICIONES.md §4.31), y con ella Encina OS deja de ser «una máquina que firma» para ser un escritorio que crece: el Snap vuelve declarado (D16, forma (c)), están la tienda, el escáner y el manejador del PDF (D17 y D18), viaja autofirma 1.9.1+encina4, y una instalación incompleta falla a la vista. La máquina es encina-E4-meta, instalada sola en 9 min 52 s: verificar-instalacion.sh --visibles 28 como root da 48 correctas, 0 fallos, 0 avisos, 0 omitidas. ~~La ISO es encina-os-E4-es.iso (aa1ac76a…).~~

LA ISO QUE SE ENTREGA ES encina-os-E4-es-0.2.1.iso (ac0a5721…) DESDE EL 2026-08-13 (MEDICIONES.md §4.35), y la anterior está borrada. aa1ac76a… llevaba dentro encina-meta 0.2.0, o sea que quien la instalara se encontraba las dos tiendas que D18 reescrita había quitado el día antes: E4 estaba terminado 13 de 13 y el entregable no lo reflejaba. Refabricada con el 0.2.1 dentro y probada arrancándola: encina-E4-entrega se instaló sola en 9 min con ESTADO=COMPLETO, su registro dice REPO ELEGIDO -> /cdrom/encina-repo —o sea que el repositorio salió del medio nuevo— y verificar-instalacion.sh --visibles 27 como root da 51 correctas, 0 fallos. La versión va en el nombre a propósito: las dos ISOs pesan exactamente lo mismo, así que el tamaño no las separa y la huella sí.

LO QUE LA VUELTA DEJÓ ABIERTO — dos de las tres cosas están cerradas el 2026-08-12 (MEDICIONES.md §4.32):

~~EL NÚCLEO NO VIAJA EN EL MEDIO.~~ LEÍDO HASTA EL FINAL, y es un LÍMITE DECLARADO como D9, no una deuda. La pregunta estaba mal planteada: no falta una fuente, porque el objetivo ya lee el medio por file:/cdrom cuando curtin instala el núcleo —el registro lo enseña sirviéndole GRUB entero desde ahí—. Lo que falta es el núcleo dentro del archivo indexado del medio, y eso lo cierra la firma de Canonical: tocar Packages rompe Release, y la línea que escribe subiquity no lleva [trusted=yes]. Y la clave apt: del seed no sirve: sin red subiquity borra a propósito todas las partes de sources.list.d del objetivo. El precio, medido y no estimado: 1 089 MB, de los que 655 son linux-firmware, que es Depends:. Queda una salida nombrada y NO medida —re-firmar el dists/ con clave propia, que sobrevive porque va a trusted.gpg.d— y es de Jorge decidir si se compra: el medio pasaría de 3,7 a ~4,7 GB, o sea fuera del DVD de una capa y del límite de 4 GiB de FAT32.
~~EL USUARIO VE DOS TIENDAS.~~ DECIDIDA Y CERRADA EL 2026-08-12/13 (§4.34): se queda el «Centro de aplicaciones» y SALE gnome-software, y D18 se reescribió entera. El usuario ve una tienda, contada y mirada, con el control de que el contador sabe decir 2, 1 y 0; las aplicaciones visibles pasan de 28 a 27 y la que se fue está nombrada. Y el motivo que la reabrió no fue el gusto: D18 había elegido gnome-software sin haber considerado snap-store, porque el día de aquella decisión el seed aún purgaba snapd y esa tienda no existía en la máquina.
~~De la ISO de E4 falta medir dos cosas.~~ CERRADA, y la casilla de AGENTS.md §6quater.1 queda marcada entera. Sobre encina-E4-cinco, creada desde cero y sin ningún CIDATA: el seed salió del quinto sitio (CIDATA -> <no encontrado>, REPO ELEGIDO -> /cdrom/encina-repo) y las cinco pantallas las nombra el propio instalador —telemetry da keyboard, network, storage, identity, timezone, sin locale ni source—, que es mejor prueba que contar capturas. 47 correctas y 2 fallos, los dos del verificador y corregidos con su motivo (§4.32g).

El banco queda en 8,3 GiB libres y 10 VMs: se borró encina-E4-iso —devolvió 10,182 GiB medidos con df— y nació encina-E4-cinco, que hace lo mismo más las dos medidas que faltaban. Sigue sin caber otra vuelta sin limpiar antes.

Y el instrumento para pilotar una VM sin ojos ya existe (§4.32h), que es lo que hizo abandonar §4.31m: el ratón de UTM no llega, el teclado de System Events sí, Ctrl+Alt se lo queda UTM, hay que reactivar la aplicación antes de cada envío, y se teclea carácter a carácter con 0,2 s.

Tres cosas que parecían arreglos y eran del INSTRUMENTO, y conviene tenerlas juntas porque salieron el mismo día: el manejador del PDF (§4.26c se midió por ssh, y en una sesión de escritorio ya estaba atado), el --yaml de fabricar-seed.sh (ya estaba hecho y el documento no se había enterado) y los nombres en inglés de §4.26f (faltaba setlocale()).

El registro de cómo se llegó hasta aquí, que empezaba diciendo «la siguiente tarea no es E4». Son tres cosas, en este orden, y las dos primeras costaron mucho menos que la tercera:

~~EL AGUJERO DE RED, que es de E3 y no de E4.~~ LEÍDO EL 2026-08-11, y sale más grande de lo que decía §4.26e (MEDICIONES.md §4.27). La lectura se hizo en el propio medio de la entrega, sin arrancar nada, y con el control de que el conjunto que se deriva de sus manifiestos reproduce la foto de §4.26g. Tres cosas: (1) Purgar snapd se lleva el .deb de transición, así que el paso 1 ya deja la máquina sin ningún Firefox (§4.16g, medido). (2) Sin red no falta el navegador: falta todo Encina. autofirma pide un JRE y libnss3-tools, encina-meta pide hunspell-es, y ninguno de los tres viaja en el medio —ni en el pool/, y el objetivo no tiene fuente cdrom—, así que apt, que es todo o nada, no instala ni uno de los cuatro .deb. La entrega sin red es Ubuntu sin navegador, y peor que la Ubuntu de la que salió, que al menos conservaba el Snap. Sigue siendo deducción: lo medido es el medio, no la máquina, y el sano y el roto están escritos en §4.27d. (3) El defecto de fondo no es la red: es que el seed no sabía decir que no. «Nunca sale distinto de 0» es una regla del instrumento —se escribió para no quedarse sin datos midiendo— que acabó dentro de la ISO que se entrega. Tercera vez que aparece un criterio de validación disfrazado de producto. Hecho el mismo día, sin gastar VM (nivel 1): el seed comprueba lo que ha dejado y escribe /etc/encina-estado (COMPLETO/INCOMPLETO y qué falta), con su control dentro; verificar-instalacion.sh lo lee; los dos YAML rehechos y comprobados por el camino de vuelta. Lo que falta, y va en la vuelta de E4: decidir si una instalación incompleta falla a la vista (nivel 2, es producto), y que el medio lleve lo que hoy baja de internet (nivel 3), que es la misma obra que decide E4. Ninguna ISO nueva: la entrega sigue siendo 02ab929d… y sigue teniendo el agujero.
~~LA PUERTA DE LA CONVIVENCIA (c), y ya son TRES preguntas, no una.~~ CONTESTADA EL 2026-08-11, las tres (MEDICIONES.md §4.29), sobre un duplicado de encina-E1-meta que se destruyó después —devolvió 0,923 GiB medidos con df, frente a los 9,2 GB que decía du—. (1) La CA sigue llegando al perfil nativo, en 1 segundo — pero no por el mecanismo que lo garantizaba: con un perfil de Snap presente hay_perfiles() da verdad y el vigilante se salta la espera de 90 s de M15(F); funcionó por un flanco posterior de PathChanged, o sea por carambola. (2) También la mete en el del Snap, en 2 segundos y con la misma huella: es el bucle de las tres raíces, escrito a propósito. (3) AutoFirma lee del perfil que se usó el último, y la regla es simétrica a propósito (M6): con el Snap usado el último, el lanzador le pasa el profiles.ini del Snap, y allí no está el certificado de la persona. O sea que en el estado (d) vuelve B4, además de B3, y el daño sigue al último navegador abierto, no es permanente. Y la máquina que tenía que contestarlo no llevaba el paquete: encina-E1-meta tiene autofirma 1.9.1+encina1, sin vigilante — se instaló +encina2 (d5a0ebe1…, el artefacto de §4.13) en el duplicado. De propina salió un defecto que no es del Snap: el paso 2 del postinst ejecuta script.sh como root y deja un almacén NSS de root dentro del perfil que nadie usa, con lo que el servicio del vigilante queda en rojo en todas las sesiones. Es de encina-autofirma y va allí, no aquí.
UNA SOLA VUELTA DE E4, con todo dentro. El precio es por vuelta y no por paquete, así que en la misma van: la convivencia (c) de D16, las aplicaciones decididas, la tienda que salga del punto 2, lo que salga del punto 1, el --yaml pendiente de fabricar-seed.sh (§6ter.4) y imagen/verificar-instalacion.sh reescrito —la casilla «Sin Snap» se sustituye y el control de «25 aplicaciones visibles» deja de valer 25—. Y el .deb que tiene que viajar dentro es autofirma 1.9.1+encina4 (faeca3a9…), no el +encina2 que lleva hoy el medio: es la razón por la que +encina3 y +encina4 se hicieron antes de esta vuelta, porque el ritual de rehacer el seed son cuatro cosas y se paga por vuelta. Cuidado al construir: encina-autofirma/salida/ tiene ya tres .deb de autofirma —d5a0ebe1…, 2d985724…, faeca3a9…—, así que la trampa de §4.13 es peor que nunca: se elige por ruta entera y se comprueba la huella, nunca con ls -t | head -1.

Lo que sigue pendiente de decidir, y es producto: qué ofimática exactamente, y qué tienda. DECIDIDO EL 2026-08-12 por Jorge, y queda UNA sola cosa: D17. No hay suite ofimática ni cliente de correo —los elige el usuario—, no entra Okular, y de serie van el visor de PDF con el manejador atado y simple-scan. Cae con ello la obligación de §4.11 de meter libreoffice-l10n-es y libreoffice-help-es, que era consecuencia de traer LibreOffice de serie; el residuo de D12 se queda en hunspell-es y los language-pack, que ya están.

LA TIENDA ES EL «CENTRO DE APLICACIONES» (D18, reescrita el 2026-08-12). Sostiene a las otras tres (D17): sin ella, «que lo instale el usuario» no se puede cumplir. gnome-software estuvo aquí y salió, con lo medido en §4.26d en contra —4 paquetes y devolvía snapd— y con lo medido en §4.34 a favor de la que se queda: cuesta 0 paquetes porque viaja pre-sembrada en el medio, abre y sirve en arm64 —encuentra LibreOffice y Thunderbird, mirado en pantalla— y no es solo de snaps: su filtro ofrece «Paquetes snap» y «Paquetes de Debian». Las dos vías que tampoco devolvían snapd —gnome-packagekit y synaptic— siguen descartadas por lo mismo de siempre: son gestores de paquetes, no una tienda para un ciudadano. Flathub y el plugin de flatpak quedan fuera a propósito (D18). Y el precio de la decisión nueva, sin maquillar: la tienda deja de estar declarada en un Depends:, porque un .deb no puede declarar un snap; lo que se declara es snapd. Con esto, E4 no tiene ninguna decisión de producto pendiente.

Tres cosas de E4 que ya tienen su forma escrita, para no rediscutirlas en la vuelta:

El manejador del PDF es una medición con dos mitades, no un fichero suelto: xdg-mime query default application/pdf antes y después. Y tiene trampa conocida: varios ficheros compiten y el gnome-mimeapps.list del escritorio gana al mimeapps.list genérico, así que hay que comprobar quién gana, no suponerlo — y R5 prohíbe sobrescribir el conffile de otro paquete: el fichero que se ponga tiene que ser nuestro.
simple-scan cierra el eslabón «escanear» solo hasta donde se puede medir sin hardware. La casilla honrada es «está instalado y el backend de SANE responde»; «escanea de verdad» necesita un escáner y unos ojos. Y hay una pregunta que contestar antes de darlo por cerrado: los escáneres de red modernos son driverless (eSCL/WSD) y eso lo da sane-airscan, no simple-scan — hay que mirar si viaja con él o si es otra línea del Depends:.
El .deb de AutoFirma que viaja es faeca3a9… (+encina4), elegido por ruta entera y huella: hay tres candidatos en salida/.

Y una casilla [OJOS] que cuesta una captura: si el usuario ve los nombres de las aplicaciones en español (§4.26f).

Lo que queda escrito abajo es cómo se llegó hasta aquí, y se conserva porque explica por qué la receta es la que es.

El registro de cuando E3 estaba abierto, que empezaba aquí: E1 (12 de 12) y E2 (6 de 6) están terminados; lo que queda de esta sección es el registro de cómo se llegó, que se conserva porque explica por qué la receta es la que es.

Lo que E3 ya tiene medido el día que se abre, y no hay que volver a preguntarlo (MEDICIONES.md §4.21, las dos mediciones baratas hechas antes de tocar xorriso):

El banco de UTM no aplica Secure Boot, y no puede. No está desactivado: el firmware que UTM arranca —edk2-aarch64-code.fd, leído de la orden de QEMU real, no del fichero de configuración— es un EDK II compilado sin él. No existen PK, KEK, db ni SetupMode, mokutil responde «This system doesn't support Secure Boot», y el núcleo dice secureboot: Secure boot disabled. Todo con el control de que sí se ven las otras 32 variables EFI y se lee una de verdad.
Pero la cadena firmada está y se recorre: MokListRT y SbatLevelRT existen, y las escribe el shim. De ahí sale la regla dura de E3: no se toca ninguno de los tres binarios firmados (bootaa64.efi, grubaa64.efi, mmaa64.efi), porque si se rompieran este banco no se daría cuenta.
Y de ahí sale un límite declarado, no una deuda: E3 no puede demostrar aquí que la ISO arranque en una máquina con Secure Boot activo. Se dice, como D9 dice lo de amd64, y no se disfraza de casilla verde.
El seed va dentro de la ISO: /cdrom/autoinstall.yaml. Es el quinto sitio que mira select_autoinstall (server.py:889-924), la ruta es literal (server.py:73-75, con raíz / en ejecución real), y /cdrom es el medio, medido en el casper que viaja en esta misma ISO. E3 no necesita el volumen CIDATA para nada.
El CIDATA va CUARTO, o sea que le gana al seed de la ISO. A favor: la ISO de E3 sigue siendo anulable sin tocarla. En contra, y hay que escribirlo en la medición: un volumen olvidado en la VM secuestraría la prueba de E3 en silencio, y la instalación saldría bien midiendo el seed equivocado.
Si alguna vez hiciera falta la palabra, va en boot/grub/grub.cfg, suelta, en la línea linux /casper/vmlinuz. Es el único grub.cfg de todo el medio: la partición EFI tiene tres binarios y cero ficheros de configuración, y el GRUB firmado no lleva el menú dentro (con su control de que strings sí encuentra cosas en ese binario). Y md5sum.txt cubre ese fichero: quien lo edite y no lo actualice deja una ISO que arranca y que falla la comprobación de integridad del propio medio. Con la forma decidida (punto 7), E3 no lo necesita y no lo toca.
LA FORMA DE E3, decidida el 2026-08-10: la ISO PREGUNTA, como Ubuntu (AGENTS.md §6ter.0). Teclado, red, disco, usuario y zona horaria los elige quien instala —las cinco secciones van listadas por su nombre real en el código de esta ISO—, y el seed aporta solo lo de Encina. Con dos excepciones deliberadas, y las dos son producto y no preferencia: source va fijo a ubuntu-desktop-minimal —Encina OS se construye sobre la mínima y lo que va encima lo declara encina-meta, que es el eje de E4—, y locale va fijo a es_ES.UTF-8, porque el seed instala firefox-l10n-es-es sin condición y quien eligiera otro idioma se llevaría una máquina a medias. El teclado sí se pregunta, que es hardware. Por eso la lista es explícita y no ['*'], que haría interactivas las dos. El motivo del resto, y corrige una inercia de este documento: lo desatendido era el criterio de validación de E2, no el producto —§10 lo dice—, y E3 lo había heredado como si fuera el producto; de ahí un usuario escrito dentro de la ISO, y de ahí la contraseña. La contraseña no era un problema que resolver: era el síntoma. Consecuencias: desaparece la contraseña, desaparece la deuda del GRUB y con ella el md5sum.txt, y lo único que queda es meter el seed dentro de la ISO. Y quitar la identidad no rompe nada, leído y no supuesto: ni encina-seed.sh ni verificar-instalacion.sh nombran al usuario ni usan /home, que es consecuencia directa de R1. El precio, dicho sin maquillar: la casilla de E2 era «nadie la toca»; la de E3 no puede serlo y pasa a ser «una persona contesta lo que Ubuntu pregunta, y nada más». Por eso el seed de E2 se conserva tal cual: es la única prueba que queda de que la receta funciona sin humano.
LA FORMA ESTÁ MEDIDA ENTERA, el mismo 2026-08-10 (§4.22), con CIDATA y el banco de E2, sin tocar xorriso. El instalador de escritorio sabe mezclar: telemetry de la máquina instalada lista exactamente las cinco pantallas pedidas —keyboard, network, storage, identity, timezone— más confirm, install, done, y no aparecen locale ni source. La máquina que sale es la de E2: verificar-instalacion.sh como root da 33 correctas, con el sistema en español, el usuario creado por quien instaló y sin servidor ssh. Los 2 fallos son del instrumento: el bloque 1 del verificador codifica el criterio de E2 —«nadie la tocó»—, que E3 no puede cumplir por diseño.

Lo que queda por medir en E3, y ya es una sola cosa: que xorriso sepa reconstruir esta ISO conservando la ESP y El Torito, y que el seed valga desde /cdrom —el quinto sitio—, que es por donde llegará cuando viaje dentro. Colgando de eso van dos comprobaciones baratas: que el interfaz del instalador salga en español con locale=es_ES.UTF-8 en el grub.cfg (leído en casper-bottom/14locales, no medido) y qué pasa si alguien conecta un CIDATA, que por precedencia le ganaría.

Lo que E2 tiene medido, y sigue valiendo entero (MEDICIONES.md §4.14 y §4.15):

La ISO oficial de Ubuntu Desktop 24.04.4 arm64 honra un autoinstall mínimo servido en un volumen etiquetado CIDATA, sin tocar la ISO.
Las late-commands se ejecutan, tanto sobre /target/ desde el entorno del instalador como con curtin in-target, ésta como root.
Y hay un precio: sin autoinstall en la línea de órdenes del núcleo, el instalador de escritorio se para a esperar un clic. Con él, instala solo. Medido con su control: la misma máquina sin esa palabra estuvo 14 minutos viva sin escribir un byte.
El repo local sin firmar funciona: dpkg-scanpackages + [trusted=yes], apt install encina-meta a secas, y los otros tres entran marcados automáticos.
El Snap se puede quitar desde el seed, y por una vía concreta (§4.16): curtin in-target -- apt-get -y purge snapd en una late-command. Deja el objetivo sin /var/lib/snapd, sin /snap, sin el lanzador y sin unidades, y el escritorio sigue vivo porque snapd es Recommends de ubuntu-desktop-minimal, no Depends. La vía obvia —snap remove— NO sirve y no falla: dice firefox eliminado y rc=0 mientras se lo quita al entorno vivo del instalador.
No hay ninguna clave del seed que quite el clic, y eso está leído en el código que viaja dentro de la ISO, no deducido (§4.16a). O sea que la decisión de §10 sigue siendo entre tres salidas y no hay una cuarta gratis.
La secuencia de §6.4 se traslada al seed tal cual, y con un aviso (§4.17): en una máquina sin Snap el paso 3 (full-upgrade) no hace nada para Firefox, y el paso 4 (apt install firefox-l10n-es-es) instala el navegador entero, no solo el idioma. El anclaje funciona igual con el nombre libre. Quitar el paso 4 deja la máquina sin ningún Firefox.

Y la decisión de forma está tomada: el parámetro autoinstall lo pone el hipervisor (2026-08-10, §10, con su motivo). No queda nada que decidir antes de escribir el seed.

El seed de verdad está escrito, versionado y medido entero (2026-08-10, §4.18). Vive en imagen/ —cinco ficheros, AGENTS.md §6bis.4— y produce una máquina completa en menos de 10 min 48 s sin que nadie abriera su ventana. Lo que faltaba por medir y era el riesgo de verdad, hay red desde dentro del chroot, y la pregunta que colgaba también está contestada: el vigilante de AutoFirma mete la CA en el perfil igual en una máquina sin Snap (§4.18l).

E2 ESTÁ TERMINADO, 6 de 6 (2026-08-10). La firma salió. Lo que sigue de esta lista es el registro de cómo se llegó, y la siguiente tarea es E3, abierto el mismo día y especificado en AGENTS.md §6ter.

La sombra .desktop está arreglada y la casilla «Sin Snap» marcada (2026-08-10, §4.19): encina-firefox-native 0.2.1 con NoDisplay=true, un solo icono de Firefox en los dos mundos y A2 intacto. Cambió una de las cuatro huellas del seed, así que el volumen se reconstruyó (b8269e52…) y §4.18 se remidió entero con una máquina nueva. E2 va 5 de 6.
LA FIRMA, HECHA (2026-08-10, §4.20d). [OJOS]: la hizo y la vio Jorge; el agente no ha visto la pantalla. Sobre un clon efímero de encina-E2-0.2.1, destruido después con control de que no queda copia del .p12. La máquina corrobora lo esencial: el navegador que firmó era /usr/lib/firefox/firefox-bin fuera de /snap/, AutoFirma se lanzó por afirma://websocket contra el perfil nativo, y la CA del socket estaba en el almacén NSS del perfil que Firefox usa de verdad, con la misma huella que la del paquete en disco.

E3 ESTÁ ABIERTO desde el 2026-08-10, y se especifica en AGENTS.md §6ter. Las dos deudas que heredaba se han caído el mismo día, y las dos por el mismo motivo. La primera era poner la palabra autoinstall sin hipervisor: ya no hace falta ponerla, porque con la ISO preguntando hay alguien delante y el clic de confirmación es la pantalla normal de «instalar ahora». La segunda era la contraseña: no había que resolverla, había que quitar su causa, que era un usuario escrito dentro de la ISO. encina sigue viva donde tiene sentido —el seed de laboratorio, servido con CIDATA, débil y pública a propósito— y no entra en ninguna ISO.

Los dos iconos de Firefox y la casilla que dependía de ellos: CERRADOS el 2026-08-10 (§4.19). Eran la misma cosa vista por dos sitios, y las dos se arreglan en encina-firefox-native 0.2.1, con NoDisplay=true en la sombra. Medido en los dos mundos, y es el único estado que sirve: deja un icono con Snap y sin Snap, y el identificador sigue resolviendo a /usr/bin/firefox %u, así que A2 no se reabre. Las alternativas están descartadas por medición, no por criterio: borrar la sombra devuelve /snap/bin/firefox %u en la máquina con Snap, y Hidden=true la deja en NINGUNA y mata el icono anclado del dock.

Y la casilla no estaba floja, estaba al revés, que es peor: pedía NINGUNA, y NINGUNA solo se alcanza reabriendo A2 o dejando el icono muerto. Se corrigió con su motivo escrito —ahora pregunta que no resuelva bajo /snap/— y se le añadió la condición que no tenía nadie: cuántos iconos ve el usuario. Ninguna de las doce casillas contaba iconos, y por eso el defecto vivió desde A2.

Cambiar el paquete cambió una de las cuatro huellas del seed, así que se reconstruyó el volumen y se remidió §4.18 entero con una instalación nueva (encina-E2-0.2.1): 34 comprobaciones correctas, ningún fallo.

Lo que sigue en esta sección es el registro de E1, que se conserva porque explica por qué la secuencia de instalación es la que es.

E1 — `encina-meta` (terminado en lo que decide)

Un paquete Architecture: all sin ficheros propios cuyo trabajo entero es declarar dependencias. Es pequeño a propósito y desbloquea todo lo demás: un instalador desatendido instala un nombre, no tres.

Contiene:

Depends: sobre encina-branding, encina-firefox-native y autofirma.
El residuo de l10n que D12 le dejó: hunspell-es, language-pack-es, language-pack-gnome-es en Depends:; libreoffice-l10n-es, hyphen-es, mythes-es, thunderbird-locale-es en Recommends:. El motivo, con las salidas, en MEDICIONES.md §6.1.
Ojo con R10: encina-firefox-native configura el repositorio de Mozilla, así que encina-meta no puede depender de nada que venga de ese repositorio.

R10 medida el 2026-08-08, antes de escribir una línea (MEDICIONES.md §4.10). Tres cosas, y la segunda cambia lo que este documento prometía:

E1 no se para. encina-meta puede no declarar firefox sin dejar la máquina sin navegador, porque el nombre firefox ya está instalado en toda Ubuntu de escritorio —deb de transición al Snap— y el anclaje de encina-firefox-native lo reasigna al deb de Mozilla. No se instala: se sustituye. Con control negativo: sin el anclaje, apt no propone nada.
«Un solo apt install» no era posible, y no por culpa de este paquete. El cambio lo hace apt full-upgrade —apt upgrade no—, después de un apt update que no puede ocurrir dentro de la misma transacción (R3). Y el idioma, firefox-l10n-es-es, solo existe en el repositorio de Mozilla, así que ningún Depends: de Encina puede traerlo. La secuencia de tres órdenes está escrita en AGENTS.md §6.4.
Declarar firefox no lo arreglaría: lo estropearía en silencio. No es irresoluble, como se suponía: en un escritorio de fábrica lo satisface el deb de transición ya instalado y la máquina sigue en el Snap con apt saliendo con 0; en una base sin Firefox, apt instala snapd y el Snap.

Lo que lo da por terminado: esa secuencia, ejecutada tal cual sobre una Ubuntu 24.04 arm64 limpia, deja un sistema que firma en valide.redsara.es, mirado en pantalla.

Estado el 2026-08-08: 10 de 12 casillas, y la que decide sigue abierta a propósito. La firma salió —«Fichero firmado correctamente», con certificado real de la FNMT, sobre una máquina virgen instalada por la secuencia, y la VM se destruyó después—, pero la secuencia no bastó, y la casilla exige que baste. Faltaba un cuarto paso: el postinst de autofirma corre en el paso 1, cuando Firefox nativo todavía no existe, así que no hay perfil donde instalar la CA de su socket, y sin ella la sede dice «No es posible conectar con Autofirma». Con sudo dpkg-reconfigure autofirma después de abrir Firefox una vez, funcionaba.

Lo que cerraba E1 no era otra tarde de VM: era un disparador en encina-autofirma que instalase la CA cuando apareciera un perfil de Mozilla.

Y eso está hecho, el 2026-08-09. autofirma 1.9.1+encina2 lleva dos unidades de systemd de usuario que hacen exactamente eso, medido sobre un clon virgen con la secuencia de tres órdenes y sin ejecutar dpkg-reconfigure ni una vez (M18 de encina-autofirma; enmienda en MEDICIONES.md §4.12a). La secuencia son otra vez tres órdenes y así está escrita en AGENTS.md §6.4.

Y LA CASILLA QUE DECIDE ESTÁ MARCADA, el mismo 2026-08-09. Se repitió el experimento sobre otro clon virgen, encina-firma-efimera: la secuencia de tres órdenes tal cual —29 correctas, 0 fallos, sin dpkg-reconfigure—, la CA del socket llegando sola al perfil al abrir Firefox, el certificado importado, y la firma mirada en pantalla. Salidas en MEDICIONES.md §4.13. La VM se destruyó después, como manda §9.1.

Queda una casilla de doce, y no depende de este paquete. apt autoremove no propone los tres porque entraron por ruta en la línea de órdenes, así que apt los marcó manuales; medido con A/B el 2026-08-08. Se cumple sola en cuanto los .deb lleguen como dependencias de un repositorio, que es lo que hace E2. E1 está terminado para lo que E1 prometía: una máquina que firma.

La pregunta que se le hizo a E2 antes de abrirlo, y lo que contestó

Es la lección de A3 y de B∥, y ha vuelto a acertar: ¿qué comando demuestra que esto es viable? Para E2 era un autoinstall.yaml mínimo sobre la ISO oficial de Ubuntu Desktop 24.04 arm64 que instalase desatendido y ejecutase una late-command. Contestada el 2026-08-09 en una tarde (MEDICIONES.md §4.14), y contestó tres cosas en vez de una:

Sí, el seed se honra, y la ISO no hay que tocarla.
Sí, las late-commands corren, las dos formas.
Y no, no es desatendido gratis: falta una palabra en la línea de órdenes del núcleo, y ponerla en una máquina de verdad no es cosa del seed.

De paso tumbó una premisa que este documento daba por buena —el «antecedente» de que la línea base se había instalado por autoinstall— que era falsa. Media tarde de medición ha corregido una creencia y ha movido la frontera de un incremento; es exactamente lo que la pregunta compra.

Lo aprendido que sigue valiendo

Una comprobación que pasa no vale nada si no sabes contra qué ha pasado. Cuando una dé [OK], comprueba que habría dado [FALLO] de haber estado mal. Las dieciocho trampas de SCRIPTS.md son dieciocho formas de que esto salga caro, y aplican igual dentro de un autoinstall.yaml. La novena salió justo aquí, al abrir E2: un control necesita su propia señal de que llegó a ejecutarse.
Todo lo verificable sin pantalla no basta. En A2, con las siete comprobaciones automáticas en verde, el icono seguía abriendo el Snap. Se vio mirando about:support, y estaba en español, así que parecía correcto.
Una deducción bien fundada puede acertar el mecanismo y errar la causa. Pasó tres veces en un solo día (MEDICIONES.md §4.9, M12).
git a través del hook de rtk devuelve commits que no son. Cualquier medición sobre git va con /usr/bin/git o rtk proxy.

Navigation Menu

«Empieza aquí» de `ENCINA-OS.md` §7, del 2026-08-08 al 2026-08-25: el archivo de por dónde se empezó

AL DÍA, 2026-08-25: LA FASE 1 ESTÁ COMPLETA — 1a en el hierro `amd64`, 1b en el banco `arm64` con 0.1.17 y el veredicto de Jorge

LA TAREA EN CURSO, 2026-08-23: EL FALLO DEL INSTALADOR `amd64` NO SE REPRODUCE, Y EL RELOJ QUE LO EXPLICA ES DE UBUNTU

LA RECETA DEL HIERRO — `amd64` en el portátil AMD A9 (7ª gen)

EL ORDEN DE TODO LO QUE QUEDA, decidido por Jorge el 2026-08-23: PUBLICAR ES LO ÚLTIMO

LA TAREA EN CURSO, 2026-08-22 (noche): HAY UN MEDIO `amd64` Y ARRANCA CON LA MARCA. EL INSTALADOR SE CAE, Y NO SE SABE DE QUIÉN ES

LA TAREA EN CURSO, 2026-08-22: LA INSTALACIÓN OCURRE — Y SALE SIN NINGÚN PAQUETE DE ENCINA. Falta UN `.deb` en el medio

AL DÍA, 2026-08-22 (tarde): LOS DOS ARREGLOS Y LA GUARDA, HECHOS. FALTA LA PANTALLA

AL DÍA, 2026-08-22 (mañana): LA RED DE SEGURIDAD FUNCIONA. Ejercitada por sabotaje, con su control delante

LO ÚNICO QUE QUEDA DEL BLOQUE, Y NO SE PUEDE PAGAR AQUÍ: PLYMOUTH

LA TAREA SIGUIENTE, 2026-08-22 (cierre): `amd64` (E6), Y NO PUBLICAR TODAVÍA

LO ANTERIOR, 2026-08-21: LA REPRODUCIBILIDAD, PAGADA — y por partida doble

LO ANTERIOR, 2026-08-20 (noche): EL FALLO INTERMITENTE ES DEL BANCO, MEDIDO: 33 % Y LOS TRES MEDIOS. La capa queda LIMPIA

LO ANTERIOR, 2026-08-20 (cierre): LA CAPA SE MONTA. La casilla 3 está HECHA salvo los `[OJOS]`

LO ANTERIOR, 2026-08-20 (mañana): HAY MEDIO DE PRODUCTO QUE ARRANCA, CON NOMBRE Y VERSIÓN PROPIOS — lo que queda es la capa, la reproducibilidad y los `[OJOS]`

LO ANTERIOR, 2026-08-19 (cierre): la causa, cerrada — un nombre en clave entrecomillado

LO ANTERIOR, 2026-08-19 (tarde): la causa acotada a `LTS "Noble Numbat"`, que resultó ser sólo las comillas

LO ANTERIOR, 2026-08-19 (tarde, a medias): el bisecado baja a un solo trozo

LO ANTERIOR, 2026-08-19 (mañana): EL BISECADO CIERRA — LA CAUSA ES `/.disk/info`, y lo que falta es saber POR QUÉ y decidir el precio

LO ANTERIOR, 2026-08-17 (tarde): LA CAPA NO SE MONTA — la vuelta única se dio, y tumbó la casilla 3

E1 — `encina-meta` (terminado en lo que decide)

La pregunta que se le hizo a E2 antes de abrirlo, y lo que contestó

Lo aprendido que sigue valiendo

FilesExpand file tree

empieza-aqui-2026-08-08-a-2026-08-25.md

Latest commit

History

empieza-aqui-2026-08-08-a-2026-08-25.md

File metadata and controls

«Empieza aquí» de ENCINA-OS.md §7, del 2026-08-08 al 2026-08-25: el archivo de por dónde se empezó

AL DÍA, 2026-08-25: LA FASE 1 ESTÁ COMPLETA — 1a en el hierro amd64, 1b en el banco arm64 con 0.1.17 y el veredicto de Jorge

LA TAREA EN CURSO, 2026-08-23: EL FALLO DEL INSTALADOR amd64 NO SE REPRODUCE, Y EL RELOJ QUE LO EXPLICA ES DE UBUNTU

LA RECETA DEL HIERRO — amd64 en el portátil AMD A9 (7ª gen)

EL ORDEN DE TODO LO QUE QUEDA, decidido por Jorge el 2026-08-23: PUBLICAR ES LO ÚLTIMO

LA TAREA EN CURSO, 2026-08-22 (noche): HAY UN MEDIO amd64 Y ARRANCA CON LA MARCA. EL INSTALADOR SE CAE, Y NO SE SABE DE QUIÉN ES

LA TAREA EN CURSO, 2026-08-22: LA INSTALACIÓN OCURRE — Y SALE SIN NINGÚN PAQUETE DE ENCINA. Falta UN .deb en el medio

AL DÍA, 2026-08-22 (tarde): LOS DOS ARREGLOS Y LA GUARDA, HECHOS. FALTA LA PANTALLA

AL DÍA, 2026-08-22 (mañana): LA RED DE SEGURIDAD FUNCIONA. Ejercitada por sabotaje, con su control delante

LO ÚNICO QUE QUEDA DEL BLOQUE, Y NO SE PUEDE PAGAR AQUÍ: PLYMOUTH

LA TAREA SIGUIENTE, 2026-08-22 (cierre): amd64 (E6), Y NO PUBLICAR TODAVÍA

LO ANTERIOR, 2026-08-21: LA REPRODUCIBILIDAD, PAGADA — y por partida doble

LO ANTERIOR, 2026-08-20 (noche): EL FALLO INTERMITENTE ES DEL BANCO, MEDIDO: 33 % Y LOS TRES MEDIOS. La capa queda LIMPIA

LO ANTERIOR, 2026-08-20 (cierre): LA CAPA SE MONTA. La casilla 3 está HECHA salvo los [OJOS]

LO ANTERIOR, 2026-08-20 (mañana): HAY MEDIO DE PRODUCTO QUE ARRANCA, CON NOMBRE Y VERSIÓN PROPIOS — lo que queda es la capa, la reproducibilidad y los [OJOS]

LO ANTERIOR, 2026-08-19 (cierre): la causa, cerrada — un nombre en clave entrecomillado

LO ANTERIOR, 2026-08-19 (tarde): la causa acotada a LTS "Noble Numbat", que resultó ser sólo las comillas

LO ANTERIOR, 2026-08-19 (tarde, a medias): el bisecado baja a un solo trozo

LO ANTERIOR, 2026-08-19 (mañana): EL BISECADO CIERRA — LA CAUSA ES /.disk/info, y lo que falta es saber POR QUÉ y decidir el precio

LO ANTERIOR, 2026-08-17 (tarde): LA CAPA NO SE MONTA — la vuelta única se dio, y tumbó la casilla 3

E1 — encina-meta (terminado en lo que decide)

La pregunta que se le hizo a E2 antes de abrirlo, y lo que contestó

Lo aprendido que sigue valiendo

«Empieza aquí» de `ENCINA-OS.md` §7, del 2026-08-08 al 2026-08-25: el archivo de por dónde se empezó

AL DÍA, 2026-08-25: LA FASE 1 ESTÁ COMPLETA — 1a en el hierro `amd64`, 1b en el banco `arm64` con 0.1.17 y el veredicto de Jorge

LA TAREA EN CURSO, 2026-08-23: EL FALLO DEL INSTALADOR `amd64` NO SE REPRODUCE, Y EL RELOJ QUE LO EXPLICA ES DE UBUNTU

LA RECETA DEL HIERRO — `amd64` en el portátil AMD A9 (7ª gen)

LA TAREA EN CURSO, 2026-08-22 (noche): HAY UN MEDIO `amd64` Y ARRANCA CON LA MARCA. EL INSTALADOR SE CAE, Y NO SE SABE DE QUIÉN ES

LA TAREA EN CURSO, 2026-08-22: LA INSTALACIÓN OCURRE — Y SALE SIN NINGÚN PAQUETE DE ENCINA. Falta UN `.deb` en el medio

LA TAREA SIGUIENTE, 2026-08-22 (cierre): `amd64` (E6), Y NO PUBLICAR TODAVÍA

LO ANTERIOR, 2026-08-20 (cierre): LA CAPA SE MONTA. La casilla 3 está HECHA salvo los `[OJOS]`

LO ANTERIOR, 2026-08-20 (mañana): HAY MEDIO DE PRODUCTO QUE ARRANCA, CON NOMBRE Y VERSIÓN PROPIOS — lo que queda es la capa, la reproducibilidad y los `[OJOS]`

LO ANTERIOR, 2026-08-19 (tarde): la causa acotada a `LTS "Noble Numbat"`, que resultó ser sólo las comillas

LO ANTERIOR, 2026-08-19 (mañana): EL BISECADO CIERRA — LA CAUSA ES `/.disk/info`, y lo que falta es saber POR QUÉ y decidir el precio

E1 — `encina-meta` (terminado en lo que decide)