Primero distinga un bloqueo completo del host de un fallo de red
La máquina informada perdió el acceso a la red, el ping, los contenedores, la respuesta de la consola local y la salida de vídeo. Ese alcance es más amplio que una interrupción de SMB, Docker o la NIC, y es coherente con un bloqueo completo del host que requiere un ciclo de apagado y encendido.
Si un servidor desaparece de forma remota, compruebe la consola local y la pantalla antes de comprar una NIC de reemplazo. Una consola que responde orienta la investigación hacia la red; una consola congelada y una pantalla sin señal la orientan hacia el kernel, el firmware, la alimentación, el almacenamiento o el hardware.
Registre la hora exacta del evento y si la máquina se reinició por sí sola o permaneció encendida pero sin responder. Esas observaciones determinan qué intervalo del arranque anterior y qué datos de monitorización externa se pueden comparar.
Recopilar pruebas del arranque anterior antes de cambiar variables
La primera recopilación útil del tema fue journalctl -b -1, incluidos los mensajes del kernel y de alta prioridad del arranque que terminó con el bloqueo. Posteriormente, el equipo de ZimaOS solicitó las últimas 500 entradas del arranque anterior y el registro persistente para revisarlos de forma privada.
Revise los registros para detectar información personal antes de publicarlos. En este caso, el registro persistente estaba habilitado, pero se detuvo abruptamente en el momento del fallo observado, sin un pánico, una terminación por falta de memoria (OOM), un reinicio de la GPU, un error de almacenamiento, un evento térmico, un bloqueo del watchdog ni un apagado normal.
Un registro final vacío no demuestra que no haya ocurrido ningún fallo. Muestra que el host se detuvo antes de que el método de registro local disponible registrara una causa. Repetir el mismo comando de registro después de cada bloqueo silencioso idéntico aporta poco, a menos que cambie el método de captura.
Las pruebas de la GPU y de Frigate no identificaron una solución
El sistema usaba gráficos Intel i915 y Frigate VAAPI, por lo que el autor desactivó primero la aceleración de GPU. El host siguió bloqueándose. Detener completamente Frigate produjo en un momento un intervalo más largo, pero las pruebas posteriores no establecieron que Frigate fuera la causa.
El autor también intentó desactivar i915, lo que hizo que otras cargas de trabajo fueran inutilizables, y el sistema finalmente volvió a bloquearse. Ese resultado descarta «desactivar i915» como una reparación exitosa en este caso.
La comparación con OpenMediaVault fue significativa: el mismo hardware y la misma configuración de Frigate habían sido estables allí. Esto despierta sospechas sobre una interacción específica del kernel o del controlador de ZimaOS, pero por sí solo no identifica qué componente falló.
Las sugerencias sobre IOMMU, VFIO y SATA LPM se descartaron como soluciones
ZimaOS inicialmente incluía intel_iommu=on e vfio_iommu_type1.allow_unsafe_interrupts=1. Un miembro del equipo pidió al autor que eliminara ambos. La línea de comandos activa confirmó su ausencia, pero la máquina volvió a bloquearse.
El autor probó entonces libata.force=nolpm porque los discos de datos usaban un adaptador de M.2 a SATA. A la mañana siguiente se produjo otro bloqueo. Por tanto, el hilo no respalda ninguno de los dos cambios de parámetros de arranque como solución.
Estas pruebas también muestran por qué las actualizaciones pueden invalidar un experimento: una actualización había sobrescrito el archivo personalizado de la línea de comandos. Verifica siempre la línea de comandos de arranque activa antes de interpretar el tiempo de actividad y cambia una sola variable durante la ventana de bloqueo establecida.
El journal persistente, pstore y el reenvío remoto llegaron a sus límites
El kernel incluía pstore y detección de bloqueos duros y blandos, y el watchdog NMI estaba activo. Sin embargo, /sys/fs/pstore permaneció vacío después de los bloqueos, mientras que no se reservó ningún kernel de fallo para kdump.
La consola de red de arranque analizó su configuración, pero se inició antes de que eth0 existía y se desactivaba por sí solo. Un proceso del espacio de usuario journalctlEl reenviador -to-UDP llegó a una segunda máquina Linux, pero también se detuvo sin una causa final cuando el host se congeló.
Ese resultado es útil: el reenvío en el espacio de usuario no puede enviar mensajes después de que el planificador o la pila de red se detienen, y no puede generar una advertencia del kernel que nunca se emitió. En este punto, un kernel de depuración del proveedor o una instrumentación específica son más valiosos que otra captura idéntica del espacio de usuario.
ZimaOS 1.7.1 cambió los componentes sospechosos, pero aún no se había validado
Un segundo usuario de ZimaBoard 2 informó de bloqueos repetidos de Python y otros procesos cerca de un bloqueo total. El equipo de ZimaOS indicó que eliminó la dependencia de Crudini de zimaos-welcome, redujo la frecuencia de solicitudes de recursos de ese servicio y planificó los cambios para una versión de prueba.
Más tarde, el equipo aclaró que el problema de Crudini solo era un desencadenante y que la causa real del fallo del sistema aún estaba bajo investigación. En ZimaOS 1.7.1, también revirtió la versión del motor de Docker para mejorar el inicio de los contenedores y reducir la probabilidad de bloqueo de los mensajes del intermediario DBus.
La publicación final pregunta si otro usuario tiene estabilidad en 1.7.1, pero no proporciona el resultado de tiempo de actividad requerido. No describas 1.7.1 como una solución confirmada para los bloqueos hasta que la condición de fallo original permanezca estable más allá de su intervalo anterior.
Escalar con las pruebas ya descartadas
Un paquete de soporte sólido incluye el modelo del hardware, las versiones de ZimaOS y del kernel, el controlador de almacenamiento, las cargas de trabajo, las horas de los fallos, los parámetros de arranque activos, los registros del arranque anterior y una lista de las pruebas controladas con sus resultados.
Indica explícitamente que la aceleración de GPU, el aislamiento de Frigate, la eliminación de los parámetros de IOMMU/VFIO, la desactivación de i915, los cambios de SATA LPM, los registros persistentes, pstore y el registro remoto del espacio de usuario no produjeron una reparación confirmada en este caso de origen.
Si otro sistema operativo permanece estable con la misma carga de trabajo mientras ZimaOS continúa bloqueándose, conserva esa comparación y solicita una compilación específica o una investigación del proveedor. Cuando la fiabilidad es operativamente crítica, volver al entorno estable es un límite de detención válido, en lugar de seguir acumulando parámetros no verificados indefinidamente.
Preguntas frecuentes
¿Frigate o Intel VAAPI causaron los fallos de ZimaOS?
El hilo no lo demostró. Los fallos continuaron después de desactivar la aceleración de GPU y de realizar más pruebas de aislamiento de i915.
¿Eliminar los parámetros de IOMMU y VFIO solucionó los bloqueos?
No. La línea de comandos activa confirmó que ambos se habían eliminado, y el equipo volvió a bloquearse.
¿ZimaOS 1.7.1 soluciona los bloqueos completos del sistema?
La versión modificó Crudini, zimaos-welcome, el motor de Docker y el comportamiento relacionado con DBus, pero el tema termina antes de que un resultado de estabilidad confirme la recuperación.
