Si ZimaOS détecte vos disques, mais que l’écran de création du RAID les affecte aux mauvaises baies, laisse des emplacements sélectionnables vides ou n’affiche qu’une partie des disques, commencez par distinguer un problème actuel lié à l’état du RAID de l’ancien problème d’association des disques sur du matériel autre qu’un ZimaCube, documenté dans ce fil. La page 2 reflète en grande partie le comportement de ZimaOS 1.2.x et des premières versions 1.3.x sur du matériel DIY.
Le dépannage RAID actuel de ZimaOS commence par le nombre de disques, leur état, le formatage individuel, un point de montage vide et un redémarrage. Ce n’est qu’après ces vérifications que vous devriez envisager les anciennes solutions de contournement liées à l’association des baies, et uniquement si vous pouvez reproduire le même défaut d’association dans votre version actuelle.
À quoi ressemblait l’ancien bug d’association des disques
Plusieurs utilisateurs de matériel autre qu’un ZimaCube ont signalé que les disques physiquement connectés apparaissaient dans des positions virtuelles inattendues. La page de stockage pouvait afficher des disques dans les baies 4, 5 et 6, tandis que la boîte de dialogue RAID attendait des disques dans des positions antérieures, ce qui désactivait le bouton Suivant ou masquait un disque de la sélection.
La reconnaissance et l’éligibilité RAID constituaient deux couches différentes
Cette distinction reste utile aujourd’hui. Voir un disque dans lsblk Cela prouve que le noyau voit un périphérique bloc. Le voir dans Fichiers ou le Gestionnaire de stockage prouve qu’une autre couche le reconnaît. Le fait qu’il soit sélectionnable pour un RAID ajoute encore une couche d’éligibilité et d’interface utilisateur.
Si une couche échoue, notez l’étape à laquelle le disque disparaît au lieu de l’effacer immédiatement. Vérifiez l’état du système de fichiers, les métadonnées RAID existantes, l’état du montage et si l’interface actuelle considère le disque comme disponible pour un nouveau groupe.
Exécutez les vérifications RAID actuelles avant de modifier la configuration du système
Le guide officiel actuel de dépannage des RAID recommande de vérifier la présence d’au moins deux disques, de contrôler leur état, de confirmer que chaque disque peut être formaté correctement, de s’assurer que le point de montage RAID prévu est vide et de redémarrer avant de retenter la création.
La liste de vérification actuelle pour le dépannage d’un RAID dans ZimaOS devrait être votre première démarche, même avec du matériel DIY, car elle évite les suppositions susceptibles d’entraîner une perte de données.
SataStartNumber était une solution de contournement communautaire propre à une version
Dans l’ancienne discussion, un membre de l’équipe IceWhale a reconnu que la logique de l’interface des premières versions de ZimaOS était fortement liée à la disposition des emplacements du ZimaCube. Il a été conseillé aux utilisateurs d’examiner l’emplacement des disques sur les contrôleurs avec lsblk -o hctl et, pour certains systèmes DIY, ajustez SataStartNumber dans /etc/casaos/local-storage.conf.
Certains utilisateurs ont confirmé que cela corrigeait le mappage des baies virtuelles ; d’autres ont ensuite signalé que des versions plus récentes de ZimaOS avaient corrigé leur configuration sans conserver la même solution de contournement. Il s’agit donc d’une technique historique de compatibilité, et non d’une exigence universelle actuelle.
N’appliquez pas une ancienne SataStartNumber valeur provenant d’une autre carte mère. La topologie des contrôleurs varie selon le système, et ZimaOS actuel n’utilise peut-être plus les mêmes hypothèses.
Les captures d’écran montrent pourquoi les limites entre versions sont importantes
ZimaOS 1.7.1 inclut également un correctif pour l’affichage inexact de l’état du RAID dans certains scénarios. Cela ne prouve pas que tous les cas de mappage des baies DIY sont résolus, mais constitue une raison supplémentaire de reproduire le problème sur une version actuelle avant de suivre une modification de configuration datant de 2024.
Ne transformez pas la solution de contournement shell pour cinq disques en recette générale
Un participant ultérieur disposait de cinq périphériques NVMe de 8 To. L’interface n’en proposait que quatre pour la création du RAID, bien que le cinquième soit visible ailleurs, et l’utilisateur a finalement étendu manuellement le RAID5 avec mdadm.
L’arrêt, le réassemblage ou l’extension d’une matrice avec des commandes de bas niveau peut entraîner une perte de données si la liste des périphériques ou les hypothèses concernant les métadonnées sont incorrectes. Pour un système actuel qui reconnaît les disques, mais ne permet pas de les utiliser dans l’interface RAID, sauvegardez les données importantes et transmettez le problème avec la version, lsblk la sortie, la topologie des contrôleurs, les captures d’écran et l’état actuel de la matrice, plutôt que de copier l’ancienne séquence shell.
