ميّز أولًا بين تجمّد المضيف بالكامل وفشل الشبكة
فقد الجهاز المبلّغ عنه الوصول إلى الشبكة، والاستجابة لاختبار ping، والحاويات، واستجابة وحدة التحكم المحلية، وإخراج الفيديو. وهذا نطاق أوسع من عطل في SMB أو Docker أو بطاقة الشبكة، ويتوافق مع تجمّد كامل للمضيف يتطلب فصل الطاقة وإعادة توصيلها.
إذا اختفى الخادم عن بُعد، فتحقق من وحدة التحكم المحلية والشاشة قبل شراء بطاقة شبكة بديلة. تشير وحدة التحكم المستجيبة إلى توجيه التحقيق نحو الشبكة؛ بينما ينقله تجمّد وحدة التحكم وفقدان الشاشة نحو النواة أو البرامج الثابتة أو الطاقة أو التخزين أو العتاد.
سجّل وقت الحدث بدقة، وما إذا كان الجهاز قد أعاد التشغيل تلقائيًا أو ظل موصولًا بالطاقة لكنه غير مستجيب. تحدد هذه الملاحظات نافذة عملية الإقلاع السابقة وبيانات المراقبة الخارجية التي يمكن مقارنتها.
اجمع أدلة عملية الإقلاع السابقة قبل تغيير المتغيرات
كانت أول مجموعة مفيدة جُمعت في الموضوع هي journalctl -b -1، بما في ذلك رسائل النواة والرسائل عالية الأولوية من عملية الإقلاع التي انتهت بالتجمّد. طلب فريق ZimaOS لاحقًا آخر 500 إدخال من عملية الإقلاع السابقة والسجل المستمر لمراجعتهما بشكل خاص.
راجع السجلات بحثًا عن المعلومات الشخصية قبل نشرها علنًا. في هذه الحالة، كان التسجيل المستمر مفعّلًا، لكن السجل توقف فجأة عند وقت العطل المرصود، من دون ذعر للنواة، أو إنهاء بسبب نفاد الذاكرة، أو إعادة ضبط لوحدة معالجة الرسومات، أو خطأ في التخزين، أو حدث حراري، أو تعطل لآلية المراقبة، أو إيقاف تشغيل طبيعي.
لا يثبت غياب سجل نهائي أن شيئًا لم يتعطل. بل يُظهر أن المضيف توقف قبل أن يسجل مسار التسجيل المحلي المتاح سببًا. ولا تضيف إعادة تنفيذ أمر السجل نفسه بعد كل تجمّد صامت مماثل فائدة تُذكر ما لم تتغير طريقة الالتقاط.
لم تحدد اختبارات وحدة معالجة الرسومات وFrigate حلًا
استخدم النظام رسومات Intel i915 وFrigate VAAPI، لذلك عطّل المؤلف تسريع وحدة معالجة الرسومات أولًا. ظلّ المضيف متجمّدًا. أدى إيقاف Frigate بالكامل إلى فترة أطول في إحدى المرات، لكن الاختبارات اللاحقة لم تثبت أن Frigate هو السبب.
جرّب المؤلف أيضًا تعطيل i915، لكن ذلك جعل أعباء العمل الأخرى غير قابلة للاستخدام، ثم تعطّل النظام مجددًا في النهاية. وتستبعد هذه النتيجة اعتبار «تعطيل i915» إصلاحًا ناجحًا لهذه الحالة.
The comparison with OpenMediaVault was meaningful: the same hardware and Frigate configuration had been stable there. It raises suspicion about a ZimaOS-specific kernel or driver interaction, but it does not by itself identify which component failed.
كانت المقارنة مع OpenMediaVault ذات دلالة: فقد استقر العتاد نفسه وإعداد Frigate نفسه هناك. وهذا يثير الشك في وجود تفاعل خاص بنواة ZimaOS أو برنامج تشغيل فيها، لكنه لا يحدد بمفرده أي مكوّن تعطل.
استُبعدت اقتراحات IOMMU وVFIO وSATA LPM بوصفها حلولًا تضمن ZimaOS في البداية وintel_iommu=on vfio_iommu_type1.allow_unsafe_interrupts=1. طلب أحد أعضاء الفريق من الكاتب إزالة كليهما. أكد سطر الأوامر النشط غيابهما، ومع ذلك تجمد الجهاز مجددًا.
اختبر الكاتب بعد ذلك libata.force=nolpm لأن أقراص البيانات كانت تستخدم محولًا من M.2 إلى SATA. وتلا ذلك تجمد آخر في صباح اليوم التالي. لذلك لا يدعم الموضوع اعتبار أي من تغييري معاملات الإقلاع حلًا للمشكلة.
توضح هذه الاختبارات أيضًا سبب إمكانية أن تُبطل التحديثات تجربةً ما: فقد استبدل أحد التحديثات ملف سطر الأوامر المخصص. تحقّق دائمًا من سطر أوامر الإقلاع النشط قبل تفسير مدة التشغيل، وغيّر متغيرًا واحدًا عبر نافذة التعطل المعروفة.
بلغت السجلات المستمرة وpstore والتمرير عن بُعد حدودها
تضمنت النواة pstore واكتشاف حالات قفل صلبة وناعمة، وكان مراقب NMI نشطًا. ومع ذلك، /sys/fs/pstore وظل فارغًا بعد التعطلات، في حين لم تُحجز نواة أعطال لـ kdump.
حلّل netconsole أثناء الإقلاع إعداداته، لكنه بدأ قبل eth0 كان موجودًا وعطّل نفسه. أما مساحة المستخدم journalctl-وصل مُمرِّر UDP إلى جهاز Linux ثانٍ، لكنه توقف هو أيضًا من دون تحديد السبب النهائي عند تجمد المضيف.
هذه النتيجة مفيدة: لا يستطيع تمرير مساحة المستخدم إرسال رسائل بعد توقف المجدول أو مكدس الشبكة، ولا يمكنه اختلاق تحذير من النواة لم يصدر أصلًا. في هذه المرحلة، ستكون نواة تصحيح أخطاء من المورّد أو أدوات رصد موجهة أكثر قيمة من التقاط آخر مطابق في مساحة المستخدم.
غيّر ZimaOS 1.7.1 المكوّنات المشتبه بها، لكن لم يُتحقق من ذلك بعد
أبلغ مستخدم ثانٍ على ZimaBoard 2 عن تعطل متكرر لعمليات Python وعمليات أخرى قبيل توقف النظام. وقال فريق ZimaOS إنه أزال اعتماد Crudini من zimaos-welcome، وخفّض تكرار طلبات الموارد من تلك الخدمة، وخطّط لإدراج التغييرات في إصدار اختباري.
أوضح الفريق لاحقًا أن مشكلة Crudini لم تكن سوى مُحفّز، وأن السبب الفعلي لتعطّل النظام لا يزال قيد التحقيق. وفي ZimaOS 1.7.1، جرى أيضًا التراجع عن إصدار Docker Engine لتحسين بدء تشغيل الحاويات وتقليل احتمال حظر رسائل وسيط DBus.
يسأل المنشور الأخير عمّا إذا كان مستخدم آخر مستقرًا على 1.7.1؛ لكنه لا يقدم نتيجة مدة التشغيل المطلوبة. لا تصف 1.7.1 بأنه إصلاح مؤكد للتجمّد حتى تظل حالة الفشل الأصلية مستقرة بعد تجاوز نافذة حدوثها السابقة.
التصعيد مع الاختبارات المستبعدة بالفعل
تتضمن حزمة الدعم القوية طراز العتاد، وإصدارات ZimaOS وkernel، ووحدة التحكم بالتخزين، وأعباء العمل، وأوقات الأعطال، ومعلمات الإقلاع النشطة، وسجلات الإقلاع السابق، وقائمة بالاختبارات المضبوطة ونتائجها.
اذكر صراحةً أن تسريع GPU، وعزل Frigate، وإزالة معلمات IOMMU/VFIO، وتعطيل i915، وتغييرات SATA LPM، والسجلات المستمرة، وpstore، وتسجيل مساحة المستخدم عن بُعد، لم تُنتج إصلاحًا مؤكدًا في حالة المصدر هذه.
إذا ظل نظام تشغيل آخر مستقرًا تحت عبء العمل نفسه بينما يستمر ZimaOS في التجمّد، فاحتفظ بهذه المقارنة واطلب إصدارًا موجّهًا أو تحقيقًا من المورّد. عندما تكون الموثوقية ضرورية تشغيليًا، فإن العودة إلى البيئة المستقرة تمثل حدًا صالحًا لإيقاف الاستكشاف بدلًا من تكديس معلمات غير مُتحقق منها بلا نهاية.
الأسئلة الشائعة
هل تسبب Frigate أو Intel VAAPI في أعطال ZimaOS؟
لم يثبت الموضوع ذلك. استمرت الأعطال بعد تعطيل تسريع GPU وبعد إجراء اختبارات عزل إضافية لـ i915.
هل أدت إزالة معلمات IOMMU وVFIO إلى إصلاح حالات التجمّد؟
لا. أكّد سطر الأوامر النشط إزالة كليهما، ثم تجمّد المضيف مجددًا.
هل يعمل ZimaOS 1.7.1 على إصلاح تجمّد النظام بالكامل؟
غيّر الإصدار Crudini، zimaos-welcome، ومحرك Docker، والسلوك المرتبط بـ DBus، لكن الموضوع ينتهي قبل أن تؤكد نتيجة الاستقرار التعافي.
