ما الذي كان يفعله Scrutiny على ZimaOS 1.5؟
في نوفمبر 2025، ثبّت أحد المستخدمين Scrutiny على ZimaOS 1.5، ورأى في البداية محركات الأقراص الصلبة المتصلة عبر USB 3.0 في لوحة المعلومات. وبعد توصيل محركات إضافية، لم يضفها Scrutiny. وحتى إزالة محرك كان قد اكتشفه سابقًا لم تُحدّث القائمة المعروضة.
أعاد المستخدم تشغيل ZimaOS وأعاد تثبيت Scrutiny، لكن حالة لوحة المعلومات الأصلية ظلت ظاهرة. وأدى ذلك إلى طرح سؤالين مختلفين: أين تُخزَّن الحالة الدائمة لـ Scrutiny، وكيف ينبغي عرض محركات USB المتصلة خلف جسر أو وحدة تحكم في Scrutiny.
لماذا قد تؤدي إعادة تثبيت Scrutiny إلى الاحتفاظ بالحالة القديمة؟
أوضح أحد أعضاء المجتمع أن بيانات التطبيق تبقى في منطقة بيانات التطبيقات على محرك الأقراص الذي ثُبّت عليه التطبيق. ويتوافق ذلك مع السلوك الأوسع المعروف في ZimaOS مع التطبيقات الأخرى: فإزالة الحاوية لا تعني دائمًا حذف جميع بيانات التطبيق الدائمة.
ويهم هذا التمييز لأن Scrutiny يخزّن أكثر من مجرد عرض حي في المتصفح. فقد تعيد عملية إعادة التثبيت استخدام إعدادات أو حالة قاعدة بيانات محفوظة إذا ظل مجلد بيانات التطبيقات المربوط موجودًا.
لماذا قد يحتاج محرك USB إلى نوع جهاز محدد صراحةً؟
خلص صاحب المنشور الأصلي لاحقًا إلى أن محرك الأقراص المتأثر كان يحتاج إلى نوع جهاز محدد صراحةً، مثل sat. وقد تخفي جسور USB إلى SATA أو تترجم أوامر SMART بطريقة تختلف عن القرص المتصل مباشرةً عبر SATA، لذلك قد تحتاج أداة المراقبة إلى معلومات إضافية عن الجهاز قبل أن تتمكن من الاستعلام عن بيانات SMART بشكل صحيح.
لم يتضمن النقاش تعليمات رسمية من IceWhale توضّح بالضبط كيفية تمرير إعداد الجهاز الخاص بـ Scrutiny عبر واجهة ZimaOS 1.5. ولهذا السبب، لا تعرض هذه الصفحة مقطع YAML الخاص بالمستخدم باعتباره إجراءً رسميًا في ZimaOS.
ما الذي ينبغي التحقق منه قبل إعادة ضبط Scrutiny؟
- تأكد من أن ZimaOS نفسه يرى محرك الأقراص قبل استكشاف مشكلة Scrutiny وإصلاحها.
- تحقق مما إذا كانت المشكلة تؤثر فقط في محركات الأقراص المتصلة عبر USB أم تشمل أيضًا أجهزة SATA/NVMe المتصلة مباشرةً.
- حدّد جسر USB إلى SATA أو الحاوية المستخدمة، لأن الجسور المختلفة تعرض بيانات SMART بطرق مختلفة.
- سجّل إصداري Scrutiny وZimaOS قبل إعادة التثبيت أو حذف البيانات الدائمة.
- لا تحذف بيانات تطبيق Scrutiny الدائمة إلا إذا كنت مستعدًا لفقدان إعداداته وسجله المخزنين.
هل يستطيع ZimaOS حاليًا إتاحة إعدادات تطبيق YAML عشوائية؟
أشار المستخدم في عام 2025 تحديدًا إلى أن إعدادات التطبيقات في ZimaOS لم تكن تتيح خيار نوع الجهاز الذي يحتاج إليه. ويواصل ZimaOS توسيع عناصر التحكم في إعدادات التطبيقات، لكن خارطة طريق المنتج الحالية تدرج دعم إعدادات YAML الأصلية كإمكانية في الإصدار 1.7x، وليس كميزة ينبغي افتراض توفرها في كل إصدار أقدم.
إلى أن يتيح حزمة التطبيق المثبّتة أو واجهة ZimaOS الحالية خيار إعداد مناسبًا، تعامل مع التغييرات اليدوية على الحاوية أو YAML باعتبارها تخصيصًا متقدمًا قد يتأثر بتحديثات التطبيق.
يمكنك مراجعة الجدول الزمني لإصدارات ZimaOS الحالي قبل الاعتماد على حل بديل كُتب لإصدار ZimaOS 1.5.
ماذا لو اختلف Scrutiny وZimaOS بشأن صحة محرك الأقراص؟
يُعد اكتشاف محرك الأقراص وتفسير حالته الصحية مشكلتين منفصلتين. وتُظهر نقاشات مجتمعية لاحقة أن المستخدمين قد يرون أيضًا اختلافات بين حالة الصحة في ZimaOS ونتائج SMART في Scrutiny. إذا كان محرك الأقراص ظاهرًا فعليًا لكن Scrutiny أبلغ عن فشل SMART، فاحتفظ بأدلة SMART وتعامل مع القرص بحذر بدلًا من افتراض أن حالة لوحة المعلومات وحدها حاسمة.
الأسئلة الشائعة
أين يحتفظ Scrutiny بحالة لوحة المعلومات؟
يشير النقاش المجتمعي إلى بيانات التطبيق الدائمة في منطقة بيانات التطبيقات على محرك الأقراص الذي ثُبّت عليه التطبيق. وقد لا تؤدي إزالة حاوية التطبيق وحدها إلى إزالة تلك الحالة المخزنة.
لماذا يرى Scrutiny محرك USB واحدًا ولا يرى آخر؟
قد تعرض جسور تخزين USB إمكانات SMART بطرق مختلفة. وقد اعتقد صاحب المنشور الأصلي أن نوع جهاز SAT محددًا صراحةً كان مطلوبًا للمحرك المتأثر.
هل قدّمت IceWhale إجراءً رسميًا باستخدام YAML في ZimaOS 1.5 ضمن هذا النقاش؟
لا. لم يتضمن النقاش طريقة رسمية خطوة بخطوة لإضافة إعداد نوع جهاز Scrutiny عبر ZimaOS 1.5.
هل ينبغي حذف مجلد بيانات تطبيق Scrutiny لفرض إعادة ضبط؟
فقط إذا كنت تريد عمدًا إزالة الحالة الدائمة للتطبيق ونسخت احتياطيًا كل ما تحتاج إليه. يختلف حذف بيانات التطبيق الدائمة عن مجرد إعادة تشغيل التطبيق.
