Solución de la comunidad

ZimaCube desaparece de la red: ¿bloqueo o fallo de la tarjeta de red?

Multiple early ZimaCube users reported intermittent network disappearance, and local console testing later showed at least one case was a complete OS freeze.

En resumen: primero decide si ZimaCube perdió la conexión de red o si se bloqueó todo el sistema operativo

«Desapareció del router» suena a un problema de la tarjeta de red, pero el hilo acabó aportando una pista más sólida: con un monitor y un teclado conectados, la pantalla era visible, pero la máquina no respondía a la entrada del teclado. Eso es un bloqueo del sistema, no simplemente la ausencia de una concesión DHCP. La resolución de problemas cambia por completo una vez hecha esa distinción.

Usa una consola local antes del próximo fallo

Deja conectados temporalmente un monitor y un teclado. Cuando se pierda el acceso remoto, prueba la consola antes de apagar y encender el equipo. Prueba las teclas de la consola de ZimaOS y comprueba si la pantalla se actualiza o acepta entradas.

Pantalla de la consola local de ZimaCube visible mientras el servidor es inaccesible desde la red
Durante el fallo de 2024, la pantalla local de ZimaOS permanecía visible, mientras que ya no se podía acceder a la máquina a través del router ni del navegador.
ZimaCube conectado a un monitor y un teclado para diagnosticar un bloqueo completo del sistema durante la noche
Se conectaron un monitor y un teclado para distinguir una interrupción exclusiva de la red de un bloqueo completo del sistema operativo; la entrada del teclado también dejó de responder.

Si la entrada local funciona, pero el router ya no muestra el dispositivo, céntrate en Ethernet, DHCP y el servicio de red. Si la entrada local tampoco funciona, captura la pantalla y trata el incidente como un bloqueo del sistema operativo, el kernel o el hardware.

Usa uptime para distinguir un reinicio de un bloqueo

uptime
last -x | head
journalctl -b -1 -p warning..alert
journalctl -b -1 -k

Después de la recuperación, uptime te indica si el servidor realmente se reinició. Los registros del arranque anterior pueden revelar fallos del kernel, tiempos de espera del almacenamiento, terminaciones por falta de memoria (OOM) o errores de controladores antes del ciclo de apagado forzado. Los registros del arranque anterior abarcan la selección del arranque en el diario.

No des por sentado que el horario nocturno del router sea la causa principal

Varios usuarios desactivaron las programaciones de Wi‑Fi o los reinicios del router y aun así reprodujeron la interrupción. Esto hace que «el router apaga el Wi‑Fi» sea una explicación insuficiente. El servidor estaba conectado por cable y las incidencias posteriores también ocurrieron durante el día. Mantén los eventos del router en la cronología, pero exige una correlación reproducible antes de culparlo.

Comprueba el estado actual de Ethernet después de la recuperación

ip addr
ip route
ethtool YOUR_INTERFACE
dmesg | grep -i -E 'enlace|Ethernet|tarjeta de red|restablecer|timeout'

La versión actual de ZimaOS muestra por separado el estado del enlace Ethernet físico, la velocidad negociada y la IP asignada. Si el próximo incidente afecta únicamente a la red, compara el estado del puerto del router con el estado de la interfaz local. Las interfaces de red de ZimaOS proporcionan los controles de red actuales.

Si la consola aún acepta comandos durante un incidente limitado a la red, ethtool puede mostrar el estado del enlace, la velocidad negociada y la información del controlador sin reiniciar. Las comprobaciones de red de ethtool ayudan a distinguir entre un sistema operativo activo con el enlace caído y un bloqueo completo del equipo.

No uses reinicios forzados repetidos como método de recuperación habitual

Mantener pulsado el botón de encendido varias veces al día puede provocar daños en el sistema de archivos y las bases de datos, especialmente durante transferencias grandes o actividad de RAID. Si la consola está congelada y no hay una forma de apagar el sistema correctamente, puede que no quede más remedio que realizar un ciclo de apagado forzado, pero, siempre que sea posible, recopila pruebas antes de hacerlo.

La copia de seguridad de ZimaOS es especialmente importante al diagnosticar bloqueos intermitentes del sistema.

Reduce las variables durante la prueba de estabilidad

Detén temporalmente las aplicaciones no esenciales, desactiva los dispositivos USB/PCIe innecesarios, mantén una única ruta Ethernet conocida y funcional, y evita realizar migraciones simultáneas de varios terabytes. Si el bloqueo desaparece, vuelve a introducir las cargas de trabajo una por una. Esto resulta mucho más informativo que cambiar a la vez la configuración del router, del cliente, del almacenamiento y de las aplicaciones.

La recuperación de ZimaOS establece el límite actual de recuperación del sistema si las pruebas de estabilidad revelan una partición del sistema o una instalación defectuosa.

Los informes históricos de la versión 1.2.x no deben aplicarse directamente a ZimaOS 1.7

El hilo corresponde a 2024 e IceWhale estaba solucionando activamente problemas de estabilidad en la línea 1.2.x. El ZimaOS actual ha incorporado muchos cambios en el kernel, la red, la memoria, el almacenamiento y los servicios de archivos. Usa el hilo para aprender el método de diagnóstico —consola frente a red, reinicio frente a bloqueo, registros frente a suposiciones—, no para afirmar que todas las desconexiones nocturnas modernas son el mismo error de 2024.

Cuándo sospechar del hardware

Si una versión estable actual sigue bloqueándose con un mínimo de aplicaciones y con almacenamiento y red que sabes que funcionan correctamente, ejecuta diagnósticos de memoria e inspecciona las temperaturas, la alimentación, los dispositivos PCIe y los errores de disco o controlador. Un bloqueo completo reproducible con distintos sistemas operativos y condiciones de red puede trasladar la investigación a un nivel inferior al propio ZimaOS.

La plataforma ZimaCube 2 es útil para distinguir un dispositivo ZimaCube original de las plataformas posteriores.

Preguntas frecuentes

¿Por qué desaparece ZimaCube de mi router?

Puede tratarse de un fallo exclusivo de red, un reinicio o un bloqueo completo del sistema. Prueba la consola local y los registros del arranque anterior antes de decidir cuál es el caso.

¿La suspensión del disco puede hacer que todo el ZimaCube desaparezca?

No debe suponerse que la suspensión del disco suspende todo el servidor. Si dejan de responder tanto el teclado como la red, diagnostica un bloqueo completo del sistema.

¿Debería programar un reinicio nocturno?

Un reinicio programado puede ocultar una inestabilidad, pero no identifica la causa. Usa los registros y pruebas controladas antes de convertir el reinicio en la solución permanente.

¿Qué debo recopilar antes de hacer un reinicio forzado?

Fotografía la consola, comprueba la respuesta del teclado, anota el estado del enlace del router y del DHCP, registra la hora y, después de reiniciar, recopila los registros del kernel y de advertencias del arranque anterior.

¿Las transferencias de archivos grandes pueden provocar el bloqueo?

Pueden revelar problemas de almacenamiento, memoria, controladores o temperatura, pero la transferencia en sí no es la causa raíz sin registros que lo respalden. Reprodúcelo con cargas de trabajo controladas.