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.


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.
