Síntoma en metal ajeno: la pantalla se congela justo tras `sdc: sdc1 sdc2 sdc3 sdc4`
/ `Attached SCSI removable disk`. No estaba colgado.
Prueba de que el root nunca se montó: con `ignore_loglevel` un montaje ext4 imprime
`EXT4-fs (...): mounted filesystem` en pantalla sí o sí, y no aparecía.
Dos causas encadenadas:
1. CARRERA. El rdinit arranca en cuanto se desempaqueta el initramfs, pero el bus USB
enumera asíncrono y tarda segundos (reset de hub, settling de 1s por dispositivo,
scan SCSI). Los 5 reintentos de 1s no alcanzaban. En QEMU el disco es virtio y está
desde el instante cero ⇒ la carrera NUNCA se veía en validación. Es el `rootwait`
que no podemos usar porque no hay root= en el cmdline. Ahora espera 60s.
2. CEGUERA. El cmdline horneado es `console=tty0 console=ttyS0,115200` y /dev/console
= la ÚLTIMA `console=` ⇒ el serial. El `exec sh` de rescate nacía invisible. Es el
MISMO bug que costó el 1er viaje físico de KDE, una capa más temprano: allá se
arregló para después del switch_root (getty en tty1) y el initramfs quedó ciego.
Ahora el log del pivote va a /dev/tty0, el marcador INIT-OK también, y el rescate
abre shell en tty1 listando los bloques visibles.
+ `timeout 15` a `hammer boot menu`: corre ANTES del exec de arje-zero ⇒ colgarse ahí
deja un arranque sin PID1 ni pantalla, indistinguible de un kernel muerto. El
`|| true` protegía del fallo, no del bloqueo.
Validado arrancando la imagen COMO USB (qemu-xhci + usb-storage, -serial null, con
pantalla): marcadores del pivote visibles, motd y prompt `/ #`.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Hermano de kde/metal-desktop-image-dual.sh, pero con la decisión INVERTIDA y ése es
el motivo de existir. La de KDE va por mesa-llvmpipe a propósito (tenía que aguantar
también una NVIDIA Pascal, cuya mesa HW sólo existe como binario Alpine ⇒ rompería
soberanía).
Acá el objetivo es cerrar ScreenCast, y el diagnóstico de hoy midió que lo que falla
es el COMPOSITOR en una llamada EGL —8 ms antes del `Paused`— porque en QEMU mesa es
kms_swrast: software, SIN exportación dmabuf. El `mesa` del corpus se construye con
-Dgallium-drivers=iris y YA está en el rootfs de COSMIC; en QEMU nunca se usaba, en
un TigerLake es el driver correcto y trae dmabuf de verdad. O sea que este viaje no
es "lo mismo pero en metal": es la única forma de saber si ScreenCast está bien.
⚠ Por eso NO se inyecta llvmpipe: mezclarlos no es aditivo — llvmpipe trae su propio
libgbm/libEGL/libgallium y sobrescribirlos DESACTIVA iris. Si la máquina no tuviera
Intel, la imagen correcta sería la de KDE, no ésta con un parche.
Y lo que NO hace falta inyectar, medido: la de KDE mete libLLVM.so.18 + libgcc_s +
libstdc++ porque el JIT de llvmpipe los NEEDea. Acá NO — iris_dri.so pide sólo
libglapi/libdrm/libz/libzstd/libc (mesa va con -Dllvm=disabled) y cosmic-comp ocho
NEEDED sin C++. CERO binarios ajenos de Alpine. Verificado con clausura ELF completa
del rootfs: 472 objetos escaneados, 42 raíces de runtime, 0 con NEEDED sin proveedor
(los 3 huecos son llvm-*/perl, herramientas de build que el escritorio no arranca).
Se instala EL MISMO cosmic-start validado en QEMU, no una variante: nada de lo que
hace es específico del emulador, y que corra el mismo fichero es lo que hace que
"validado en QEMU" signifique algo para el metal.
VALIDADO EN OVMF CON PANTALLA, que es la regla de oro que costó un USB en el 1er
viaje de KDE (-serial null para simular metal sin puerto serie): arje-zero PID 1, las
4 particiones montadas, el motd VISIBLE y el prompt `/ #` en la pantalla — o sea que
el getty de tty1 hace su trabajo. El shell responde: iris_dri.so presente,
/dev/dri/card0, y cosmic-start/portal-probe/wireplumber en PATH.
Falta quemar el USB, que es destructivo y necesita que el usuario confirme el device.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
sergioandClaude Opus 5