Si un SSD NVMe est détecté par Linux mais affiché dans la mauvaise baie du ZimaCube — ou mal affiché dans l’interface de stockage — le problème peut venir des métadonnées de correspondance des baies de ZimaOS plutôt que du SSD lui-même. Vérifiez d’abord la détection PCIe, puis utilisez la réinitialisation de local-storage.conf uniquement sur le matériel pour lequel IceWhale a documenté ou recommandé cette solution de contournement.
Le fil source présente une limite importante selon le modèle : supprimer la NVME=... ligne et redémarrage zimaos-local-storage.service a corrigé le cas initial du ZimaCube, mais IceWhale a ensuite indiqué que cette méthode s’appliquait au ZimaCube et ne fonctionnait pas de la même manière sur un Intel NUC générique.
Étape 1 : Confirmez que le NVMe existe au niveau PCIe
Exécutez :
lspci | grep -i -E 'non-volatile|nvme'
lsblk -o NAME,SIZE,MODEL,SERIALSi le SSD n’apparaît dans aucune des deux vues matérielles, le problème ne se limite pas au graphique des baies de ZimaOS.
Le guide de dépannage du stockage est utile lorsque le NVMe est absent au niveau matériel, et pas seulement mal représenté dans l’interface web.
Étape 2 : Vérifiez la correspondance des baies du ZimaCube
Sur le ZimaCube concerné, IceWhale a demandé :
sudo -i
cat /etc/casaos/local-storage.confLa configuration contenait explicitement une NVME=... correspondance qui ne correspondait plus à l’emplacement du SSD.
Étape 3 : Utilisez la réinitialisation uniquement sur le modèle concerné
IceWhale a demandé à l’utilisateur du ZimaCube de supprimer la NVME=... ligne, puis exécutez :
systemctl restart zimaos-local-storage.serviceL’utilisateur d’origine a confirmé que cela avait corrigé l’interface.
Pourquoi déplacer le SSD peut recréer le problème
Un utilisateur a ensuite déplacé le SSD d’une baie à une autre, et la mauvaise correspondance est réapparue. Cela s’explique si la correspondance des baies mise en cache ou personnalisée ne correspond plus au nouvel emplacement physique.
N’appliquez pas cela aveuglément à du matériel générique
Un utilisateur sur un Intel NUC a essayé la même modification, et la ligne NVMe est réapparue sans corriger l’interface. IceWhale a explicitement indiqué que cette méthode s’appliquait au ZimaCube et que la prise en charge plus large des compartiments personnalisés pour d’autres modèles était encore en cours de développement.
Vérifiez d’abord l’interface de stockage actuelle
Le guide actuel de configuration du stockage de ZimaOS documente la détection des disques et la configuration du stockage. Si le SSD est visible comme stockage normal, mais que le graphique de la baie est incorrect, considérez qu’il s’agit d’un problème de présentation ou de mappage.
Utilisez les privilèges root avec prudence
La discussion d’origine précisait également que la modification de /etc/casaos/local-storage.conf nécessite les privilèges root. Ne forcez pas l’écriture du fichier depuis une session utilisateur normale.
Séparez la détection physique de la présentation des baies
La page Stockage de ZimaCube tente d’associer les contrôleurs NVMe détectés aux libellés des logements physiques. Cette couche de présentation supplémentaire explique pourquoi un disque peut être parfaitement visible sous Linux, tout en apparaissant sous la mauvaise lettre ou avec un graphique de baie inhabituel.
Avant de modifier la configuration, notez le modèle du SSD, l’adresse PCI et le logement physique. Vous disposerez ainsi d’un état avant/après et réduirez le risque de « corriger » le mauvais périphérique.
Sauvegardez local-storage.conf avant toute modification
Si le support IceWhale vous demande de modifier le fichier, faites-en d’abord une copie :
sudo -i
cp /etc/casaos/local-storage.conf /etc/casaos/local-storage.conf.bakEffectuez ensuite uniquement la modification demandée. Évitez de réécrire les paramètres de stockage sans rapport, car le fichier contient davantage que le mappage NVMe.
Redémarrez d’abord le service de stockage, pas l’ensemble du serveur
La correction vérifiée pour ZimaCube a redémarré zimaos-local-storage.service après avoir supprimé le mappage obsolète. Il s’agit d’un test plus ciblé que le redémarrage de l’ensemble du NAS, ce qui permet de déterminer plus facilement si le service de stockage local a correctement recréé le mappage des baies.
Si le mappage réapparaît
Lorsque le même mappage obsolète réapparaît après chaque redémarrage, cessez de modifier le fichier à répétition. Capturez la configuration générée, lspci, lsblk, du logement physique et de la version actuelle de ZimaOS au support. Une régénération persistante signifie qu’un autre composant écrit le mappage.
Le {ilink("https://shop.zimaspace.com/pages/zimaos-installation-troubleshooting-guide","guide de dépannage du stockage","Collectez les informations sur la détection du matériel et les métadonnées de stockage avant d’effectuer plusieurs modifications au niveau du système")} fournit un cadre d’escalade plus sûr.
FAQ
La suppression de la ligne NVME efface-t-elle le SSD ?
La solution de contournement d’origine modifiait la configuration du mappage des baies, et non le contenu du disque. Toutefois, sauvegardez vos données importantes avant toute modification du stockage au niveau du système.
Pourquoi le SSD est-il visible dans lspci, mais pas correctement dans l’interface ?
Cela indique plutôt un problème de métadonnées de stockage de ZimaOS ou de mappage des baies qu’un problème de détection PCIe de base.
Puis-je utiliser cette correction sur un Intel NUC ?
Pas en règle générale. IceWhale a précisé que cette solution de contournement s’appliquait spécifiquement à ZimaCube.
Que faire si le SSD n’apparaît pas dans lspci ?
Examinez d’abord le matériel, le logement du SSD, les paramètres BIOS/PCIe et la connexion physique.
