حلّ المجتمع

نظام ZimaOS لا يتعرّف على جميع محركات الأقراص الصلبة في وحدة DAS متصلة عبر USB: استكشاف أخطاء اكتشاف التخزين وإصلاحها

A ZimaOS 1.5.3 investigation into missing disks in TerraMaster USB DAS enclosures. Kernel tools could see the drives even when the Storage UI could not, and destructive wipe attempts did not reliably solve the issue.

عند توصيل جهاز DAS خارجي بـ ZimaOS، توجد طبقتان مختلفتان على الأقل ينبغي التحقق منهما: ما إذا كان Linux يستطيع رؤية كل جهاز كتلي، وما إذا كانت واجهة تخزين ZimaOS تسجّل محركات الأقراص هذه لإدارتها. أوضحت سلسلة النقاش هذه من ديسمبر 2025 سبب أهمية هذا التمييز.

كان صاحب المنشور الأصلي يشغّل ZimaOS 1.5.3 مع جهاز TerraMaster D4-320، ولم يكن يرى سوى ثلاثة من أصل أربعة محركات أقراص في الواجهة. ثم أبلغ مستخدمون آخرون عن عرض مرتبط لكنه مختلف: ظهرت الأقراص الأربعة في lsblk و fdisk -l، رغم أن أيًا منها لم يظهر بشكل صحيح في تطبيق التخزين في ZimaOS.

لوحة معلومات ZimaOS تكتشف أجهزة DAS الخارجية بينما يبحث المستخدم عن محركات الأقراص الصلبة المفقودة
أظهر التقرير الأصلي لجهاز D4-320 مجموعة غير مكتملة من محركات الأقراص الخارجية في واجهة ZimaOS.
عرض تخزين ZimaOS الذي يسرد جزءًا فقط من محركات الأقراص الصلبة المتصلة عبر جهاز DAS خارجي بواجهة USB
كانت المشكلة ظاهرة في طبقة التخزين/واجهة المستخدم، رغم أن التقارير اللاحقة أظهرت أن أدوات أجهزة الكتل في Linux يمكنها تعداد الأقراص.

افصل أولًا بين اكتشاف النواة وتسجيل التخزين في ZimaOS

ألقى اقتراح مبكر باللوم على جسر DAS لعدم عرضه كل قرص بشكل مستقل. ثم سُحبت هذه التفسيرات بعد أن نشر مستخدم آخر lsblk مخرجات تُظهر الأقراص الأربعة، بسعة 5.5 تيرابايت لكل منها، كأجهزة منفصلة.

غيّر ذلك اتجاه استكشاف الأخطاء وإصلاحها. فإذا ظهر كل قرص على حدة في lsblk أو fdisk -l، إلا أن جسر USB يعرض أجهزة الكتل هذه على الأقل لنظام التشغيل. وقد تكون المشكلة المتبقية في مستوى أعلى ضمن حزمة إدارة التخزين.

لا تفترض أن إعادة التهيئة أو المسح حلّ مثبت

اقترحت ردود المجتمع أن تخطيطات GPT/أنظمة الملفات التي أُنشئت يدويًا قد تكون سبب تجاهل واجهة تخزين ZimaOS للأقراص. وحاول المستخدمون بعد ذلك مسح تواقيع أنظمة الملفات وجداول الأقسام.

لم تُصلح تلك المحاولات المشكلة بشكل موثوق. أفاد مشاركان بأن محركات الأقراص ظلّت لا تظهر في التخزين بعد تنفيذ إجراءات المسح المتلفة وإعادة التشغيل. كما أبلغ مالك لجهاز D5-300C عن سلوك مشابه.

ولأن أوامر المسح هذه صدرت عن مشاركين في المجتمع ولم تحل الحالات الأصلية، فلا ينبغي تقديمها بوصفها إجراءً رسميًا للإصلاح. إذ يمكن لأوامر مسح الأقراص أن تتسبب في تدمير البيانات نهائيًا إذا طُبّقت على الجهاز الخطأ.

حاول فريق ZimaOS إعادة إنتاج حالة D4-320

قال عضو فريق IceWhale، 777-Spider، إن الفريق كان يشتري أجهزة DAS ذات الصلة لإعادة إنتاج المشكلة. وبعد بضعة أيام، أفادت دينا بأن الفريق اختبر جهاز TerraMaster D4-320 مع أربعة محركات أقراص بتنسيقي NTFS/exFAT، جرى تهيئتها على نظام Windows، وأن المحركات الأربعة ظهرت على ZimaOS في اختبارهم.

تُعدّ هذه النتيجة مهمة لأنها تعني أن سلسلة النقاش لم تُثبت وجود عدم توافق شامل بين ZimaOS وTerraMaster D4-320. وبدلًا من ذلك، طلب الفريق من المستخدمين المتأثرين مزيدًا من المعلومات حول تنسيقات أنظمة الملفات وكيفية تهيئة محركات الأقراص.

جمع السجل التشخيصي الرسمي من سلسلة النقاش

كما قدّمت دينا أيضًا أمرًا تشخيصيًا رسميًا لجمع معلومات أجهزة الكتل، وواجهة برمجة تخزين البيانات المحلية، و devmon.service المعلومات في ملف سجل. جاء هذا الأمر من موضوع ديسمبر 2025، وقد يحتاج إلى تعديل في إصدارات ZimaOS المستقبلية.

sudo -i
LOG=/DATA/disk-info.log; : > $LOG; { echo "=== lsblk ==="; lsblk; echo; echo "=== lsblk -f ==="; lsblk -f; echo; echo "=== curl http://127.0.0.1/v2/local_storage/disk ==="; curl http://127.0.0.1/v2/local_storage/disk; echo; echo "=== curl http://127.0.0.1/v2/local_storage/storages ==="; curl http://127.0.0.1/v2/local_storage/storages; echo; echo "=== journalctl -xe -u devmon.service ==="; journalctl -xe -u devmon.service; echo; } >> $LOG 2>&1 && echo "The output has been saved to $LOG"

ذكر المنشور أنه يمكن العثور على الملف الناتج في /ZimaOS-HD/disk-info.log في «الملفات» ومشاركتها مع فريق الدعم. هذا لجمع المعلومات التشخيصية، وليس أمرًا يصلح القرص أو يهيئه.

الأقراص المفقودة وRAID 5 مشكلتان منفصلتان

أراد صاحب المنشور الأصلي أيضًا إنشاء مجموعة RAID 5. وخلال الموضوع، منعت مشكلة محرك الأقراص المفقود تقييم سير العمل هذا بصورة سليمة. لاحقًا، وبعد محاولات المسح التي أجراها المجتمع، ظل المستخدم غير قادر على إنشاء RAID، كما فقد إمكانية رؤية محركات الأقراص في «الملفات» و«التخزين».

ذكر رد IceWhale في 15 ديسمبر 2025 أن إدارة أجهزة USB، بما في ذلك التهيئة وإنشاء مصفوفات RAID، كانت مخططة لدعم مستقبلي. تعامل مع هذا التصريح باعتباره ملاحظة تاريخية في خارطة الطريق، لا دليلًا على ما يدعمه كل إصدار حالي من ZimaOS اليوم.

ترتيب أكثر أمانًا لاستكشاف الأخطاء وإصلاحها

  1. أكد عدد الأقراص المثبّتة فعليًا في وحدة DAS.
  2. تحقق مما إذا كان كل قرص يظهر بشكل مستقل على مستوى أجهزة الكتل في Linux.
  3. قارن ذلك بما تعرضه واجهة تخزين ZimaOS.
  4. سجّل نوع نظام الملفات وكيفية تهيئة كل قرص سابقًا.
  5. لا تمحُ جداول الأقسام لمجرد أن منشورًا من المجتمع اقترح ذلك.
  6. إذا كانت النواة ترى الأقراص، لكن تخزين ZimaOS لا يعرضها، فاجمع المعلومات التشخيصية وقدّم إلى الدعم طراز الحاوية الدقيق، ومعلومات نظام الملفات، وإصدار ZimaOS.

الأسئلة الشائعة حول وحدات DAS الخارجية في ZimaOS

هل يعرض TerraMaster D4-320 ثلاثة محركات أقراص فقط في ZimaOS؟

لم يدعم الموضوع هذا الاستنتاج. فقد عرض مستخدمون آخرون أربعة أقراص مستقلة في lsblk، ثم أفاد فريق IceWhale لاحقًا بأنه رأى محركات الأقراص الأربعة كلها في اختباره الخاص لجهاز D4-320.

إذا كان lsblk يرى كل محركات الأقراص، فلماذا قد لا يعرضها تخزين ZimaOS كلها؟

يُعدّ الكشف على مستوى النواة وتسجيل وحدات التخزين في ZimaOS طبقتين مختلفتين. عرض الموضوع حالات أحصت فيها النواة محركات الأقراص، بينما لم تعرضها واجهة المستخدم.

هل ينبغي أن أشغّل sgdisk أو wipefs لكي تظهر محركات الأقراص؟

ليس استنادًا إلى هذا الموضوع. جاءت تلك الاقتراحات المدمّرة من ردود المجتمع ولم تحل المشكلة بشكل موثوق. انسخ بياناتك احتياطيًا، واتبع إرشادات الدعم الحالية قبل محو أي بيانات وصفية على الأقراص.

هل حُلّت المشكلة بالكامل في الموضوع؟

لا. تمكّن الفريق من إعادة إنتاج إعداد يعمل لجهاز D4-320 بأقراص NTFS/exFAT، وطلب معلومات تشخيصية من المستخدمين المتأثرين، لكن الموضوع لم يذكر سببًا جذريًا أو إصلاحًا واحدًا شاملًا.