Cette source a finalement permis d’établir une cause première confirmée par IceWhale. Après la mise à niveau vers ZimaOS 1.5.3, la matrice RAID NVMe elle-même s’était assemblée et montée, mais zimaos-local-storage l’a immédiatement démonté, car la base de données RAID contenait fs_type = 'BTRFS' en majuscules au lieu de la valeur en minuscules attendue par le gestionnaire de stockage.
Dina, d’IceWhale, a fourni une mise à jour SQLite ciblée. L’auteur du message original l’a exécutée et a explicitement confirmé que le RAID se montait ensuite normalement. ZimaOS 1.5.4 a alors répertorié le problème de montage automatique du RAID BTRFS en majuscules parmi les correctifs officiels. Les utilisateurs actuels doivent donc considérer cette commande SQL comme une procédure historique de récupération pour ce bug précis, et non comme une commande générale de réparation RAID.
La matrice RAID était saine avant que le gestionnaire de stockage ne la démonte
Le journal montrait que le noyau détectait automatiquement le RAID, puis que systemd montait /media/RAID-Storage-2, puis zimaos-local-storage le démontant de force quelques secondes plus tard.
L’enregistrement de la base de données source indiquait également que le RAID était état OK. Cela rendait moins probable la présence d’un membre défaillant ou d’un système de fichiers Btrfs détruit.
fstab manuellement n’a fonctionné que comme solution temporaire
L’utilisateur a monté manuellement le RAID et ajouté une /etc/fstab entrée, mais la gestion du stockage de ZimaOS ne la traitait pas comme la configuration faisant autorité. Au redémarrage, le service local-storage continuait d’appliquer sa base de données et son état internes.
C’est pourquoi le stockage géré par l’appliance doit normalement être réparé via la couche de stockage de ZimaOS plutôt que conservé comme un montage manuel parallèle.
La communauté a correctement identifié zimaos-local-storage comme étant la couche concernée
Avant qu’IceWhale ne publie la cause première, gelbuilding a remarqué la séquence clé : le montage réussit, puis zimaos-local-storage le démonte. Il a correctement conseillé d’envoyer les journaux à IceWhale plutôt que de modifier à répétition les métadonnées du RAID.
Son hypothèse concernant une validation plus stricte n’était pas le diagnostic final ; le diagnostic officiel ultérieur était beaucoup plus précis.
IceWhale a trouvé l’erreur de casse de fs_type
Dina a écrit que la base de données fs_type la valeur était en majuscules, ce qui empêchait le montage. IceWhale a fourni :
sudo sqlite3 /var/lib/casaos/db/local-storage.db "UPDATE raids SET fs_type = 'btrfs' WHERE fs_type = 'BTRFS';"L’utilisateur a ensuite répondu : « Cela a effectivement résolu le problème. »
BTRFS en minuscules btrfs.ZimaOS 1.5.4 a officiellement corrigé le même bug de montage automatique
Les notes de version de la 1.5.4 indiquent explicitement un correctif pour l’échec du montage automatique lorsque les enregistrements de la base de données RAID sont stockés BTRFS en majuscules.
Voir la correction officielle du montage RAID de ZimaOS 1.5.4.
Un utilisateur ultérieur de la version 1.5.4 a tout de même signalé que le RAID n’était pas monté
Un autre participant a indiqué qu’un problème de montage persistait sur son système 1.5.4. Dina a demandé un nouveau diagnostic du disque et une description des symptômes plutôt que de supposer qu’il s’agissait encore du bug de type de système de fichiers en majuscules.
C’est la limite à respecter : des symptômes similaires peuvent avoir des causes différentes.
N’exécutez pas l’ancien SQL sur un RAID actuel sans éléments de preuve concordants
La version actuelle de ZimaOS est la 1.7.1. Avant de toucher à local-storage.db, vérifiez que :
- la baie est effectivement assemblée ;
- le journal montre que le service de stockage local l’a démontée ;
- la base de données contient réellement la valeur historique en majuscules ;
- vous disposez d’une sauvegarde et d’un rapport de diagnostic récents.
Si ces conditions ne correspondent pas, la modification de la base de données peut rendre un autre problème de stockage plus difficile à résoudre.
La correction officielle a été trouvée grâce aux journaux pertinents fournis par l’utilisateur
IceWhale a demandé /ZimaOS-HD/.log/casaos/local-storage.log après que la communauté a identifié la couche du gestionnaire de stockage. Ce journal a permis à l’équipe de passer d’une théorie générale à l’identification exacte du bug de casse.
En cas d’échec de montage actuel, conservez le même ensemble d’éléments de preuve : état de l’assemblage RAID, lignes du journal, état du stockage ZimaOS et diagnostics du stockage local avant de modifier les métadonnées.
Sauvegardez les métadonnées internes avant toute modification manuelle de la base de données
La requête SQL source était une correction en une ligne fournie par IceWhale pour un défaut connu de la version 1.5.3. Si une modification guidée de la base de données par le personnel s’avère de nouveau nécessaire, sauvegardez d’abord la base de données et l’état du système, puis appliquez uniquement la condition exacte à corriger.
Des mises à jour SQL générales des enregistrements RAID peuvent désynchroniser la vue du gestionnaire de stockage de la baie réelle et transformer un bug de montage récupérable en problème de récupération des métadonnées.
Une réinstallation n’est pas la première solution pour un RAID sain mais non monté
Comme la baie elle-même était assemblée et que les données étaient intactes, réinstaller ou recréer le RAID aurait été inutilement destructeur. Lorsqu’une baie saine est rejetée par les métadonnées de gestion, réparez la couche de gestion ou contactez le support du fabricant avant de modifier la géométrie de la baie.
FAQ sur le montage RAID
La baie RAID elle-même a-t-elle été détruite dans la source ?
Non. La baie était assemblée et montée avant que la gestion du stockage de ZimaOS ne la démonte.
Quelle était la cause première confirmée ?
La base de données RAID stockait fs_type en majuscules BTRFS au lieu de minuscules btrfs.
IceWhale a-t-il corrigé cela dans une version ?
Oui. ZimaOS 1.5.4 indique explicitement que le bug d’auto-montage de BTRFS en majuscules a été corrigé.
