Un ZimaCube qui devient impossible à joindre par ping et inaccessible via SSH peut être confronté à des problèmes de nature très différente : épuisement des sockets réseau, interaction avec un client ou un VPN, instabilité thermique, problème du noyau ou panne matérielle. Le fil de discussion de 2024 n’a pas permis de déterminer lequel était en cause.
La réinitialisation du CMOS n’était pas la solution confirmée
Le personnel de Zima a explicitement indiqué ne pas être certain qu’une réinitialisation du CMOS serait utile. Il a également précisé que la configuration RAID5 existante ne serait pas effacée par la réinitialisation du BIOS, car les informations RAID étaient stockées en dehors du CMOS. Malgré cela, le processus actuel de récupération RAID constitue la référence la plus sûre avant toute opération de dépannage du stockage susceptible d’entraîner une recréation ou un reformatage.
L’observation la plus probante concernait la corrélation entre Zima Client et le VPN
L’auteur du message d’origine a ensuite signalé qu’il n’avait plus rencontré de blocage après avoir arrêté Zima Client sur macOS, et a indiqué que les défaillances semblaient plus probables lorsque des VPN professionnels étaient actifs. Il s’agit d’une corrélation, et non d’une preuve de causalité, mais c’est un résultat utile pour l’isolation.
La présentation actuelle de Zima Client explique comment Zima Client établit des chemins de connectivité vers ZimaOS. Si un blocage semble lié au routage VPN ou au client, reproduisez le problème avec Zima Client déconnecté, puis avec le VPN déconnecté, au lieu de modifier les deux variables simultanément.
Examinez l’état du réseau avant que l’hôte ne devienne inaccessible
Une réponse de la communauté suggérait de rechercher un épuisement des sockets. La documentation sur les statistiques des sockets Linux explique comment Linux peut afficher les statistiques des sockets et les états TCP. Capturer le nombre de sockets avant que le système ne disparaisse est plus utile que d’effectuer une vérification après un redémarrage forcé.
Vérifiez les températures comme piste distincte
Une autre réponse évoquait une surchauffe. Le cadre thermique de Linux documente les zones thermiques et les interfaces de température de Linux. Les données thermiques doivent être recueillies plutôt que déduites d’un blocage complet.
Le guide de dépannage de l’installation de ZimaOS constitue une checklist plus générale du matériel et du micrologiciel si les blocages persistent en dehors du scénario impliquant le client ou le VPN.
En résumé
Le fil de discussion n’a pas identifié de bug confirmé de plantage de ZimaOS. Le meilleur indice était que les blocages de l’utilisateur avaient cessé après l’arrêt de Zima Client sur macOS, l’activité du VPN étant soupçonnée de déclencher le problème. Considérez l’interaction client/VPN, les sockets, les températures et le matériel comme des hypothèses distinctes, et ne réinitialisez pas le stockage ni ne recréez le RAID comme première étape de dépannage.
