إذا كان ZimaOS يرى أقراصك، لكن شاشة إنشاء RAID تعيّنها إلى الخانات الخطأ، أو تترك الخانات القابلة للتحديد فارغة، أو تعرض بعض الأقراص فقط، فافصل أولًا بين مشكلة حالية في سلامة RAID ومشكلة تعيين الأقراص القديمة على الأجهزة غير ZimaCube الموثقة في هذا الموضوع. تعكس الصفحة 2 إلى حد كبير سلوك ZimaOS 1.2.x والإصدارات المبكرة من 1.3.x على الأجهزة المُجمَّعة ذاتيًا.
يبدأ استكشاف أخطاء RAID الحالية في ZimaOS بعدد الأقراص، وسلامة الأقراص، وتهيئة كل قرص على حدة، وخلو نقطة التحميل، وإعادة التشغيل. وبعد هذه الفحوصات فقط، ينبغي التفكير في حلول تعيين الخانات القديمة، وفقط إذا أمكنك إعادة إنتاج عيب التعيين نفسه في إصدارك الحالي.
كيف ظهر خطأ تعيين الأقراص القديم
أفاد عدة مستخدمين على أجهزة غير ZimaCube بأن الأقراص المتصلة فعليًا ظهرت في مواضع افتراضية غير متوقعة. فقد تعرض صفحة التخزين الأقراص في الخانات 4 و5 و6، بينما كانت نافذة RAID تتوقع الأقراص في مواضع سابقة، مما يجعل زر «التالي» غير متاح أو يخفي أحد الأقراص من التحديد.
كان التعرف على الأقراص وأهلية RAID طبقتين مختلفتين
ولا يزال هذا التمييز مفيدًا اليوم. فرؤية القرص في lsblk يثبت ذلك أن النواة ترى جهاز كتل. ورؤية القرص في «الملفات» أو «مدير التخزين» تثبت أن طبقة أخرى تتعرف عليه. أما إمكانية تحديده لـ RAID فتضيف طبقة أخرى من الأهلية وواجهة المستخدم.
إذا تعطلت إحدى الطبقات، فسجّل الموضع الذي يختفي فيه القرص بدلًا من مسحه فورًا. تحقق من حالة نظام الملفات، وبيانات RAID الوصفية الموجودة، وحالة التحميل، وما إذا كانت الواجهة الحالية تعتبر القرص متاحًا لإنشاء مصفوفة جديدة.
شغّل فحوصات RAID الحالية قبل تعديل إعدادات النظام
يوصي دليل استكشاف أخطاء RAID الرسمي الحالي بالتحقق من وجود محركي أقراص على الأقل، وفحص سلامة الأقراص، والتأكد من إمكانية تهيئة كل قرص بنجاح، وضمان خلو نقطة تحميل RAID المقصودة، ثم إعادة التشغيل قبل إعادة محاولة الإنشاء.
ينبغي أن يكون قائمة التحقق الحالية لاستكشاف أخطاء RAID في ZimaOS وإصلاحها خطوتك الأولى حتى مع الأجهزة المُجمَّعة ذاتيًا، لأنها تتجنب الافتراضات التدميرية.
كان SataStartNumber حلًا التفافيًا مجتمعيًا خاصًا بإصدار معين
في سلسلة النقاش القديمة، أقرّ رد من فريق IceWhale بأن منطق واجهة ZimaOS المبكرة كان مرتبطًا بشدة بتخطيط فتحات ZimaCube. وطُلب من المستخدمين فحص موضع وحدة تحكم الأقراص باستخدام lsblk -o hctl وبالنسبة إلى بعض أنظمة DIY، عدّل SataStartNumber في /etc/casaos/local-storage.conf.
أكد بعض المستخدمين أن هذا صحّح تعيين الفتحات الافتراضية، بينما أفاد آخرون لاحقًا بأن إصدارات ZimaOS الأحدث أصلحت إعداداتهم دون الإبقاء على الحل الالتفافي نفسه. لذلك يُعدّ التعديل أسلوب توافق تاريخيًا، وليس متطلبًا عامًا حاليًا.
لا تطبّق إعدادًا قديمًا SataStartNumber قيمة من لوحة أم أخرى. تختلف طوبولوجيا وحدة التحكم باختلاف النظام، وقد لا يستخدم ZimaOS الحالي الافتراضات نفسها.
تُظهر لقطات الشاشة سبب أهمية حدود الإصدارات
يتضمن ZimaOS 1.7.1 أيضًا إصلاحًا لعرض حالة RAID غير الدقيقة في سيناريوهات معينة. وهذا لا يثبت حل كل حالات تعيين فتحات DIY، لكنه سبب إضافي لإعادة إنتاج المشكلة على إصدار حالي قبل اتباع تعديل إعدادات من عام 2024.
لا تحوّل الحل الالتفافي عبر shell للأقراص الخمسة إلى وصفة عامة
كان لدى مشارك لاحق خمسة أجهزة NVMe بسعة 8 تيرابايت. عرضت الواجهة أربعة فقط لإنشاء RAID، رغم ظهور الجهاز الخامس في موضع آخر، ثم وسّع المستخدم RAID5 يدويًا باستخدام mdadm.
يمكن أن يؤدي إيقاف المصفوفة أو إعادة تجميعها أو توسيعها باستخدام أوامر منخفضة المستوى إلى فقدان البيانات إذا كانت قائمة الأجهزة أو افتراضات البيانات الوصفية غير صحيحة. بالنسبة إلى نظام حالي يتعرّف على الأقراص لكنه لا يستطيع استخدامها في واجهة RAID، انسخ البيانات المهمة احتياطيًا وصعّد المشكلة مع تزويد الإصدار، lsblk المخرجات، وطوبولوجيا وحدة التحكم، ولقطات الشاشة، وحالة المصفوفة الحالية، بدلًا من نسخ تسلسل أوامر shell القديم.
