Commencez par distinguer un blocage complet de l’hôte d’une panne réseau
La machine signalée a perdu l’accès réseau, la réponse au ping, les conteneurs, la réponse de la console locale et la sortie vidéo. Cette étendue dépasse celle d’une panne SMB, Docker ou de carte réseau et correspond à un blocage complet de l’hôte nécessitant un cycle d’alimentation.
Si un serveur devient inaccessible à distance, vérifiez la console locale et l’affichage avant d’acheter une carte réseau de remplacement. Une console réactive oriente l’enquête vers le réseau ; une console figée et un affichage perdu l’orientent vers le noyau, le micrologiciel, l’alimentation, le stockage ou le matériel.
Notez l’heure exacte de l’événement et indiquez si la machine a redémarré d’elle-même ou si elle est restée sous tension mais ne répondait plus. Ces observations déterminent quelle période du démarrage précédent et quelles données de surveillance externe peuvent être comparées.
Recueillir les éléments du démarrage précédent avant de modifier les variables
La première collecte utile dans le sujet était journalctl -b -1, y compris les messages du noyau et les messages hautement prioritaires du démarrage qui s’est terminé par le gel. L’équipe de ZimaOS a ensuite demandé les 500 dernières entrées du démarrage précédent ainsi que le journal persistant pour un examen privé.
Vérifiez que les journaux ne contiennent pas d’informations personnelles avant de les publier. Dans ce cas, la journalisation persistante était activée, mais le journal s’est interrompu brutalement au moment de la panne observée, sans panique, arrêt dû à un manque de mémoire, réinitialisation du GPU, erreur de stockage, événement thermique, blocage du watchdog ou arrêt normal.
Un enregistrement final vide ne prouve pas que rien n’a échoué. Il montre que l’hôte s’est arrêté avant que le mécanisme local de journalisation disponible n’enregistre une cause. Répéter la même commande de journalisation après chaque blocage silencieux identique apporte peu, à moins de modifier la méthode de capture.
Les tests du GPU et de Frigate n’ont pas permis d’identifier de solution
Le système utilisait les graphiques Intel i915 et Frigate VAAPI ; l’auteur a donc d’abord désactivé l’accélération GPU. L’hôte s’est tout de même figé. L’arrêt complet de Frigate a prolongé l’intervalle à un moment donné, mais les tests ultérieurs n’ont pas établi que Frigate était à l’origine du problème.
L’auteur a également essayé de désactiver i915, ce qui a rendu d’autres charges de travail inutilisables, et le système a finalement de nouveau planté. Ce résultat exclut « désactiver i915 » comme solution efficace dans ce cas.
La comparaison avec OpenMediaVault était pertinente : le même matériel et la même configuration Frigate y étaient stables. Cela éveille les soupçons d’une interaction spécifique à ZimaOS entre le noyau et un pilote, mais ne permet pas à elle seule d’identifier le composant défaillant.
Les suggestions concernant l’IOMMU, VFIO et le LPM SATA ont été écartées comme correctifs
ZimaOS incluait initialement intel_iommu=on et vfio_iommu_type1.allow_unsafe_interrupts=1. Un membre de l’équipe a demandé à l’auteur de supprimer les deux paramètres. La ligne de commande active a confirmé leur absence, mais la machine s’est de nouveau bloquée.
L’auteur a ensuite testé libata.force=nolpm car les disques de données utilisaient un adaptateur M.2 vers SATA. Un autre gel est survenu le lendemain matin. Le fil de discussion ne permet donc pas de considérer l’une ou l’autre modification des paramètres de démarrage comme un correctif.
Ces tests montrent également pourquoi les mises à jour peuvent invalider une expérience : une mise à jour avait écrasé le fichier de ligne de commande personnalisé. Vérifiez toujours la ligne de commande de démarrage active avant d’interpréter la durée de fonctionnement, et ne modifiez qu’une variable à la fois pendant la fenêtre de plantage établie.
Les journaux persistants, pstore et le transfert distant ont atteint leurs limites
Le noyau incluait pstore ainsi que la détection des blocages matériels et logiciels, et le watchdog NMI était actif. Cependant, /sys/fs/pstore soit resté vide après les plantages, tandis qu’aucun noyau de secours n’avait été réservé pour kdump.
La netconsole au démarrage a analysé sa configuration, mais a démarré avant que eth0 existait et s’est désactivé. Un processus depuis l’espace utilisateur journalctlLe redirecteur -to-UDP a atteint une deuxième machine Linux, mais il s’est également arrêté sans cause finale lorsque l’hôte s’est figé.
Ce résultat est utile : le transfert depuis l’espace utilisateur ne peut pas envoyer de messages après l’arrêt de l’ordonnanceur ou de la pile réseau, et il ne peut pas créer un avertissement du noyau qui n’a jamais été émis. À ce stade, un noyau de débogage fourni par le fabricant ou une instrumentation ciblée serait plus utile qu’une nouvelle capture identique depuis l’espace utilisateur.
ZimaOS 1.7.1 Les composants soupçonnés ont changé, mais n’ont pas encore été validés
Un deuxième utilisateur de ZimaBoard 2 a signalé des plantages répétés de Python et d’autres processus peu avant un blocage. L’équipe ZimaOS a indiqué avoir supprimé la dépendance à Crudini de zimaos-welcome, a réduit la fréquence des demandes de ressources de ce service et a prévu ces modifications pour une version de test.
L’équipe a ensuite précisé que le problème de Crudini n’était qu’un déclencheur et que la cause réelle du plantage du système faisait toujours l’objet d’une enquête. Dans ZimaOS 1.7.1, elle a également rétrogradé la version du moteur Docker afin d’améliorer le démarrage des conteneurs et de réduire la probabilité de blocage des messages du courtier DBus.
Le dernier message demande si un autre utilisateur est stable sous 1.7.1 ; il ne fournit pas le résultat de disponibilité requis. Ne présentez pas 1.7.1 comme un correctif confirmé des blocages tant que la condition initiale de défaillance ne reste pas stable au-delà de sa fenêtre précédente.
Escalader avec les tests déjà écartés
Un dossier de support solide comprend le modèle du matériel, les versions de ZimaOS et du noyau, le contrôleur de stockage, les charges de travail, les heures des plantages, les paramètres de démarrage actifs, les journaux du démarrage précédent et la liste des tests contrôlés avec leurs résultats.
Indiquez explicitement que l’accélération GPU, l’isolation de Frigate, la suppression des paramètres IOMMU/VFIO, la désactivation d’i915, les modifications de SATA LPM, les journaux persistants, pstore et la journalisation distante de l’espace utilisateur n’ont pas permis de confirmer une réparation dans ce cas source.
Si un autre système d’exploitation reste stable avec la même charge alors que ZimaOS continue de se bloquer, conservez cette comparaison et demandez une version ciblée ou une enquête du fournisseur. Lorsque la fiabilité est essentielle au fonctionnement, revenir à l’environnement stable constitue une limite d’arrêt valable plutôt que d’empiler indéfiniment des paramètres non vérifiés.
FAQ
Frigate ou Intel VAAPI ont-ils causé les plantages de ZimaOS ?
Le fil de discussion ne l’a pas démontré. Les plantages ont continué après la désactivation de l’accélération GPU et après d’autres tests d’isolation d’i915.
La suppression des paramètres IOMMU et VFIO a-t-elle corrigé les blocages ?
Non. La ligne de commande active a confirmé que les deux avaient été supprimés, et l’hôte s’est à nouveau bloqué.
ZimaOS 1.7.1 corrige-t-il les blocages complets du système ?
La version a modifié Crudini, zimaos-welcome, le moteur Docker et le comportement lié à DBus, mais le sujet s’arrête avant qu’un résultat de stabilité ne confirme le rétablissement.
