حلّ المجتمع

لم يتم تركيب RAID بعد ZimaOS 1.5.3: ‏BTRFS بأحرف كبيرة في قاعدة بيانات التخزين وإصلاح الإصدار 1.5.4

A December 2025 thread where a healthy NVMe RAID mounted during boot and was immediately unmounted by zimaos-local-storage after upgrading to 1.5.3. IceWhale diagnosed an uppercase BTRFS value in the RAID database, provided a one-line sqlite correction, and the original poster confirmed it fixed the issue. ZimaOS 1.5.4 later officially fixed this bug.

أثبت هذا المصدر في النهاية سببًا جذريًا مؤكدًا من IceWhale. فبعد الترقية إلى ZimaOS 1.5.3، جُمّعت مصفوفة RAID الخاصة بـ NVMe نفسها وثُبّتت، لكن| zimaos-local-storage فكّ تركيبه فورًا لأن قاعدة بيانات RAID كانت تحتوي على fs_type = 'BTRFS' بالأحرف الكبيرة بدلًا من القيمة بالأحرف الصغيرة التي تتوقعها إدارة التخزين.

قدّمت Dina من IceWhale تحديثًا موجّهًا لقاعدة بيانات SQLite. ونفّذه صاحب المنشور الأصلي وأكد صراحةً أن RAID أصبح يُثبّت بشكل طبيعي بعد ذلك. ثم أدرجت ZimaOS 1.5.4 مشكلة التثبيت التلقائي لـ RAID ذي BTRFS بالأحرف الكبيرة باعتبارها عنصرًا أُصلح رسميًا. لذلك ينبغي للمستخدمين الحاليين التعامل مع أمر SQL بوصفه إرشادات استرداد تاريخية لذلك الخلل المحدد، لا أمرًا عامًا لإصلاح RAID.

كانت مصفوفة RAID سليمة قبل أن تلغي إدارة التخزين تركيبها

أظهر السجل أن النواة اكتشفت RAID تلقائيًا، وأن systemd ثبّت /media/RAID-Storage-2، ثم zimaos-local-storage إلغاء تركيبه بالقوة بعد ثوانٍ.

كما أظهر سجل قاعدة البيانات المصدر أن RAID في حالة الحالة جيدة. وكان ذلك يقلل احتمال وجود عضو متعطل أو نظام ملفات Btrfs تالف.

عمل fstab اليدوي كحل مؤقت فقط

ثبّت المستخدم RAID يدويًا وأضاف إدخالًا في /etc/fstab السجل، لكن إدارة التخزين في ZimaOS لم تتعامل معه باعتباره الإعداد المعتمد. وعند إعادة التشغيل، واصلت خدمة local-storage فرض قاعدة بياناتها/حالته الداخلية.

لهذا ينبغي عادةً إصلاح التخزين الذي تديره المنصة عبر طبقة تخزين ZimaOS بدلًا من إبقائه كتثبيت يدوي موازٍ.

حدّد المجتمع بشكل صحيح أن zimaos-local-storage هي الطبقة المسؤولة

قبل أن تنشر IceWhale السبب الجذري، لاحظ gelbuilding التسلسل الأساسي: ينجح التثبيت، ثم zimaos-local-storage يفك تركيبه. وقد نصح بشكل صحيح بإرسال السجلات إلى IceWhale بدلًا من تعديل بيانات RAID الوصفية بشكل متكرر.

لم يكن تخمينه بشأن صرامة التحقق هو التشخيص النهائي؛ إذ كان التشخيص الرسمي اللاحق أكثر تحديدًا بكثير.

اكتشفت IceWhale خطأ استخدام الأحرف الكبيرة في fs_type

كتبت Dina أن قاعدة البيانات fs_type كانت القيمة مكتوبة بأحرف كبيرة، مما تسبب في فشل التثبيت. وقدمت IceWhale:

sudo sqlite3 /var/lib/casaos/db/local-storage.db "UPDATE raids SET fs_type = 'btrfs' WHERE fs_type = 'BTRFS';"

ثم ردّ المستخدم لاحقًا: «لقد أصلح هذا المشكلة فعلًا.»

استعلام طرفية ZimaOS لقاعدة البيانات المحلية local-storage.db قبل تصحيح fs_type لـ RAID من BTRFS بالأحرف الكبيرة إلى btrfs بالأحرف الصغيرة وبعده
تُظهر لقطة الشاشة المصدر تصحيح قيمة قاعدة البيانات من الأحرف الكبيرة BTRFS بأحرف صغيرة btrfs.

أصلحت ZimaOS 1.5.4 رسميًا الخلل نفسه في التثبيت التلقائي

تسرد ملاحظات إصدار 1.5.4 صراحةً إصلاحًا لفشل التثبيت التلقائي عند تخزين سجلات قاعدة بيانات RAID BTRFS بأحرف كبيرة.

راجع الإصلاح الرسمي لتركيب RAID في ZimaOS 1.5.4.

أفاد مستخدم لاحق للإصدار 1.5.4 بأن RAID لا تزال غير مركّبة

ذكر مشارك آخر أن مشكلة تركيب ما زالت تحدث على نظامه الذي يعمل بالإصدار 1.5.4. فطلبت دينا تشخيصًا حديثًا للقرص ووصفًا للأعراض بدلًا من افتراض أن المشكلة لا تزال خلل uppercase-fs_type.

هذا هو الحد الفاصل الصحيح: قد تكون للأعراض المتشابهة أسباب مختلفة.

لا تشغّل SQL القديم على RAID حالية دون أدلة مطابقة

إصدار ZimaOS الحالي هو 1.7.1. قبل المساس بـ local-storage.db، تحقّق من أن:

  • يتم تجميع المصفوفة فعليًا؛
  • يُظهر السجل خدمة التخزين المحلي وهي تلغي تركيبها؛
  • تحتوي قاعدة البيانات فعلًا على القيمة التاريخية بالأحرف الكبيرة؛
  • لديك نسخة احتياطية وتقرير تشخيص حاليان.

إذا لم تتطابق هذه الشروط، فقد يؤدي تعديل قاعدة البيانات إلى جعل مشكلة تخزين مختلفة أصعب في الاسترداد.

تم العثور على الإصلاح الرسمي لأن المستخدم قدّم السجلات الصحيحة

طلبت IceWhale /ZimaOS-HD/.log/casaos/local-storage.log بعد أن حدّد المجتمع طبقة مدير التخزين. سمح ذلك السجل للفريق بالانتقال من نظرية عامة إلى خلل الأحرف الكبيرة الدقيق.

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

انسخ بيانات التعريف الداخلية احتياطيًا قبل أي تعديل يدوي لقاعدة البيانات

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

يمكن لتحديثات SQL الشاملة على سجلات RAID أن تفصل رؤية مدير التخزين عن المصفوفة الفعلية، وتحول خلل تركيب قابلًا للاسترداد إلى مشكلة استرداد بيانات التعريف.

إعادة التثبيت ليست الاستجابة الأولى لـ RAID سليمة لكنها غير مركّبة

لأن المصفوفة نفسها جُمّعت وكانت البيانات سليمة، فإن إعادة تثبيت RAID أو إعادة إنشائها كانت ستتسبب في ضرر غير ضروري. عندما ترفض الإدارة مصفوفة سليمة بسبب بيانات التعريف، أصلح طبقة الإدارة أو استخدم دعم المورّد قبل المساس ببنية المصفوفة.

الأسئلة الشائعة حول تركيب RAID

هل دُمّرت RAID نفسها في المصدر؟

لا. تم تجميع المصفوفة وتركيبها قبل أن تقوم إدارة التخزين في ZimaOS بإلغاء تركيبها.

ما السبب الجذري المؤكد؟

كانت قاعدة بيانات RAID تخزّن fs_type بأحرف كبيرة BTRFS بدلاً من الأحرف الصغيرة btrfs.

هل أصلحت IceWhale هذه المشكلة في أحد الإصدارات؟

نعم. يذكر ZimaOS 1.5.4 صراحةً أن خلل التركيب التلقائي لـ BTRFS بالأحرف الكبيرة قد أُصلح.