La liste de contrôle RAID d’origine de la communauté demande aux utilisateurs de confirmer qu’au moins deux disques sont disponibles, de vérifier l’état de santé des disques, de s’assurer que chaque disque peut être formaté, de garder le point de montage prévu vide, de redémarrer, puis de réessayer de créer la grappe.
Les réponses montrent pourquoi cette liste de contrôle n’était qu’un point de départ. Entre ZimaOS 1.2.1 et 1.3.0, les utilisateurs ont également rencontré une interface RAID qui disparaissait, des erreurs de système de fichiers en lecture seule et une correspondance incorrecte des emplacements de disques sur du matériel autre que ZimaCube. Il s’agit de cas historiques, et non d’une affirmation concernant l’interface actuelle de ZimaOS.
Commencez par les cinq vérifications d’origine
Confirmer qu’au moins deux disques sont disponibles
Le guide commence par l’exigence d’un nombre minimal de disques. Les disques déjà activés comme stockage séparé n’étaient pas toujours présentés comme membres disponibles par l’ancien configurateur RAID.
Vérifier l’état de santé des disques et le formatage individuel
Les vérifications suivantes permettent de distinguer un problème élémentaire de disque d’un problème de création de grappe. Le guide recommande de consulter l’état de santé et de confirmer que chaque disque peut être formaté individuellement sans erreur.
Gardez le point de montage vide et réessayez après le redémarrage
Le guide indique que le point de montage prévu pour le RAID ne doit pas déjà contenir de fichiers. Les données existantes doivent être sauvegardées avant de vider le point de montage. Après les vérifications, la séquence d’origine se termine par un redémarrage du système, puis une nouvelle tentative de création de la grappe.
L’ancienne interface utilisateur attendait des disques non attribués ou désactivés
Plusieurs utilisateurs ont formaté et activé les disques individuellement, puis ont constaté que l’accès au RAID avait disparu ou qu’aucun disque ne pouvait être sélectionné. Une réponse de l’équipe a expliqué que les disques devaient être désactivés en tant que stockages individuels afin de réapparaître comme disques disponibles dans le flux de travail RAID. Le formatage était ensuite effectué lors de la création de l’ensemble.
Cela n’a pas résolu tous les cas. ZimaOS 1.2.2 incluait un correctif lié à la désactivation des disques individuels, et des réponses ultérieures ont signalé d’autres bugs de sélection de disques jusqu’à la version 1.2.4. Un utilisateur a ensuite confirmé que son problème initial avait été résolu dans la version 1.3.0, même s’il trouvait toujours l’interface RAID difficile à trouver.
Un système de fichiers en lecture seule a produit un échec différent
Le journal du stockage d’un utilisateur indiquait que ZimaOS ne pouvait pas créer /media/Files car le système de fichiers était en lecture seule. Un membre de l’équipe a distingué ce problème d’un bouton manquant et a demandé à l’utilisateur de vérifier l’état du montage avec :
mount -l | grep "/ "
mount -l | grep /media
lsblkLa vérification demandée consistait à déterminer si le point de montage concerné apparaissait comme ro plutôt que rw. La discussion mentionne l’échec du montage, les erreurs du système de fichiers, les problèmes d’autorisations ou d’autres problèmes de configuration comme causes possibles, mais elle n’indique pas de réparation définitive pour ce cas particulier en lecture seule.
Le matériel autre que ZimaCube a révélé des bugs de mappage des emplacements de disques
Un autre groupe de réponses provenait d’utilisateurs exécutant ZimaOS sur des systèmes tiers dotés de plusieurs contrôleurs SATA ou de périphériques NVMe. Leurs disques étaient visibles et pouvaient être formatés, mais le schéma RAID affichait des baies vides, des numéros de baie inattendus ou moins de disques sélectionnables que le système d’exploitation n’en détectait.
L’équipe a ensuite publié une procédure d’affichage des disques pour les appareils autres que ZimaCube. Un utilisateur de ZimaOS 1.2.5 a signalé que le suivi de cette procédure avait corrigé l’affichage des disques et permis de créer une baie RAID. Un autre utilisateur a confirmé que la même procédure avait résolu le problème immédiatement.
Les modifications de baie en ligne de commande ne constituaient pas une solution générale
Un autre participant a ensuite créé une baie RAID 5 à quatre disques via l’interface et ajouté un cinquième périphérique NVMe avec mdadmL’utilisateur a décrit le résultat comme n’étant pas idéal. Comme ces commandes modifient une baie active et étaient propres à cette machine, ce résumé communautaire ne les présente pas comme une procédure de réparation réutilisable.
Dans sa dernière réponse en mai 2025, l’équipe a classé un autre signalement de baie manquante comme un problème matériel tiers et a demandé à l’utilisateur d’ouvrir un sujet dédié afin que les ingénieurs puissent examiner les captures d’écran et les enregistrements. Cela confirme la limite principale : la visibilité d’un disque dans le système d’exploitation ne garantit pas qu’un mappage d’emplacements propre au matériel sera correctement représenté par une ancienne interface RAID.
FAQ
Pourquoi l’option RAID a-t-elle disparu après le formatage des disques ?
Dans plusieurs cas historiques liés à la version 1.2.x, les disques activés comme stockage individuel n’étaient plus considérés comme disponibles par le processus RAID. Leur désactivation faisait réapparaître l’option RAID, bien que des bogues distincts de l’interface et du mappage des emplacements affectent encore certains systèmes.
La mise à niveau de ZimaOS a-t-elle résolu tous les cas de disques manquants ?
Non. Certains utilisateurs ont signalé des corrections après des versions ultérieures ou une installation propre, tandis que d’autres avaient encore besoin de la procédure d’affichage des disques pour les appareils autres que ZimaCube. Le résultat dépendait de la cause : ancienne interface utilisateur, système de fichiers en lecture seule ou mappage matériel tiers.
