Commit Graph
4 Commits
Author SHA1 Message Date
sergioandClaude Opus 5 b854230863 🩻 cosmic: escribir a /dev/ttyS0 COLGABA el arranque en metal (open() espera DCD)
Diagnosticado por el usuario en el OptiPlex 3060 quitando los pipes de say().

Abrir un puerto serie sin portadora BLOQUEA en open() esperando DCD, salvo que el
termios tenga CLOCAL. El kernel pone CLOCAL cuando registra el puerto COMO CONSOLA,
y eso pasa en QEMU porque el cmdline lleva `console=ttyS0,115200`. En ese metal la
firmware NO aplica el CONFIG_CMDLINE horneado —el kernel arranca con `Command line:`
VACÍO— así que ttyS0 es un puerto común, sin cable: el PRIMER say() se colgaba ahí.

Explica los tres síntomas que no cerraban:
- /var/log/cosmic se creaba (el mkdir va antes) pero el .log nunca aparecía;
- `cosmic-start > /salida.txt` daba VACÍO ⇒ parecía que el script no se ejecutaba,
  cuando estaba bloqueado en su primera línea de salida;
- la corrida terminaba siempre en «log del compositor (primer tramo)»: no era el
  último paso, era el dump() bloqueándose en el mismo sitio.

El serial no se pierde: cuando ES la consola, /dev/console YA ES ttyS0. Cuando no lo
es, no había nadie del otro lado. En metal lo que sirve es el fichero de log.

Con say() destrabado, la detección de GL quedó CONFIRMADA en metal por primera vez:
  == cosmic :: GL por HARDWARE — kernel drm=i915 + iris_dri.so (sin overrides)

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-05 15:59:40 -04:00
sergioandClaude Opus 5 77f8b3e3ec 🪵 cosmic: el log de MI validación viajaba horneado en el USB, y la salida salía doble
Dos defectos que juntos hicieron ilegible el 3er viaje.

1. LOG CONTAMINADO. Los logs de sesión van a disco para sobrevivir al apagón en
   metal — bien— pero validar la imagen en QEMU ESCRIBE DENTRO DEL FICHERO DE
   IMAGEN, y después se quema. El usuario grepeó /var/log/cosmic en su máquina y
   leyó `drm=virtio-pci`: mi corrida en QEMU, no la suya. Un log viejo que parece
   nuevo es peor que no tener log.
   Fix: la imagen crea /var/log/cosmic VACÍO como último paso. Y la regla —validar
   sobre una COPIA, o regenerar antes de quemar— queda escrita donde se comete.

2. SALIDA DOBLE. `say` tee'aba a /dev/console siempre. Lanzado a mano desde el
   getty, stdout YA es la pantalla, y /dev/console es tty0 = la MISMA pantalla
   cuando el cmdline llega vacío (la firmware del OptiPlex no aplica el
   CONFIG_CMDLINE horneado). Cada línea salía dos veces, entreverada con lo que
   arje-zero escribe a consola. Eso es lo que se leía como «basura de init»: no era
   ruido ajeno, era el propio script. Ahora /dev/console sólo si `[ -t 1 ]` es falso.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-05 15:33:50 -04:00
sergioandClaude Opus 5 86645c379c 🖥 cosmic/metal: la imagen forzaba render por SOFTWARE — el viaje no podía ganar
Diagnóstico del 1er viaje al OptiPlex 3060 (Coffee Lake, UHD 630). El dmesg del
propio USB muestra que la GPU estaba PERFECTA:

  [drm] Found coffeelake (device ID 3e92) ... Initialized i915 1.6.0 on minor 0
  fbcon: i915drmfb (fb0) is primary device

Lo que fallaba era el script de arranque. `cosmic-start-qemu.sh` exportaba
LIBGL_ALWAYS_SOFTWARE=1 y MESA_LOADER_DRIVER_OVERRIDE=kms_swrast INCONDICIONAL —
correcto sobre virtio-gpu, letal sobre Intel real: la mesa del corpus va con
-Dgallium-drivers=iris -Dllvm=disabled y NO EXISTE ningún kms_swrast_dri.so ⇒ EGL
falla. Y en el mejor caso habría sido peor: si arrancaba, componía por software y
ScreenCast fallaba igual que en QEMU ⇒ el viaje NO PODÍA contestar su pregunta.

El origen es un comentario que yo escribí en metal-desktop-image.sh afirmando que
el script no tenía supuestos del emulador. Los tenía, y el nombre del fichero lo
decía. Ahora:

- `cosmic-start-qemu.sh` → `cosmic-start.sh` (se llama por lo que hace).
- El modo de GL se DETECTA con dos patas: driver DRM del kernel Y .so de mesa
  presente. Si no hay ninguna, lo DICE en vez de morir dentro de EGL.
- La imagen VERIFICA que el script instalado no fuerce kms_swrast (falla el build
  si vuelve a pasar).

Y correr cosmic-start sobre la imagen de metal POR PRIMERA VEZ (antes sólo se
validaba que llegara al prompt) destapó que le faltaba entera la preparación de
sesión que sólo tenía qemu-desktop-image.sh: sin grupo `video` no arranca seatd,
sin usuario `messagebus` no arranca el bus de SISTEMA — y sin bus de sistema NO HAY
PORTAL, o sea que portal-probe screencast no habría tenido con quién hablar aunque
el GL fuese perfecto. Copiada: arje-logind-compat + política, video, messagebus,
setuid del launch-helper, /var/run→/run, COSMIC_MODE, libc.musl-x86_64.so.1.

Además, para que el próximo fallo en metal no cueste otro viaje a ciegas:
- Los logs van a /var/log/cosmic (ext4) y no a /tmp (RAM, se evapora al apagar).
  `dump()` también, que iba SÓLO al serial — donde se perdió la explicación de los
  tres fallos de arriba.
- authorized_keys horneada: sshd escuchaba en :22 pero era INALCANZABLE
  (PasswordAuthentication no, sin clave) ⇒ ahora se depura por red.
- netup-wait: el r8169 levanta el enlace a los 20,2s y el ente sshd pedía DHCP a
  los 13,7s, sin reintento. En QEMU no se ve: virtio-net tiene carrier desde el
  instante cero.
- firmware i915 de otras generaciones (la base sólo traía tgl_*; el Coffee Lake
  pedía kbl_dmc_ver1_04.bin).

Validado arrancando como usb-storage: seatd OK, bus de sistema OK, login1 OK,
pipewire+wireplumber OK, compositor OK. La línea de GL dice la verdad en QEMU.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-05 15:03:47 -04:00
sergio 08440220b6 estado: cosecha granja 2026-08-05T19:00:17Z — avance del árbol KDE 2026-08-05 15:00:17 -04:00