تغيّرت موضوعات هذه السلسلة بمرور الوقت. فقد بدأت كدليل لتثبيت CasaOS BTOP في عام 2024، ثم أصبحت أكثر قيمة بكثير في مارس 2025 عندما أضاف ZimaOS 1.3.3 لوحة أداء btop مدمجة، واكتشف العديد من مستخدمي ZimaBoard وZimaBlade أن الثنائي الجديد يتعطل مع تعليمة غير قانونية (تم تفريغ محتويات النواة).
جاء التشخيص النهائي من IceWhale، لا من تكهنات المجتمع: قال Zima-Giorgio إن الفريق لم يأخذ وحدة معالجة ZimaBoard المركزية في الحسبان عند تجميع btop، وإن المشكلة ستُصلح في ZimaOS 1.4.0. وهذا يجعلها مشكلة تاريخية في توافق وحدة المعالجة المركزية مع حد واضح بين الإصدارات.
قدّم ZimaOS 1.3.3 لوحة btop المدمجة
قدّمت ملاحظات إصدار IceWhale 1.3.3 أداة btop بوصفها لوحة جديدة لمراقبة الأداء في لوحة معلومات ZimaOS. وكان الهدف إتاحة مراقبة وحدة المعالجة المركزية والذاكرة والعمليات ونشاط النظام من دون مطالبة المستخدمين بتثبيت حزمة مراقبة منفصلة.
استخدم حدّ إصدار ZimaOS 1.3.3 عند قراءة سلسلة النقاش الأصلية.
فتح اختصار لوحة المعلومات شاشة إعادة الاتصال
في الأنظمة المتأثرة، أدى النقر على الاختصار إلى فتح منفذ مؤقت ذي رقم مرتفع وعرض مطالبة إعادة الاتصال فقط.
أدى تشغيل btop مباشرةً إلى ظهور خطأ تعليمة غير قانونية
كان سطر التشخيص الأساسي هو:
btop
تعليمة غير قانونية (تم تفريغ محتويات النواة)تعني هذه الرسالة أن وحدة المعالجة المركزية حاولت تنفيذ تعليمة بُنيت الثنائيات لاستخدامها، لكن العتاد لم يكن يدعمها. وهذا يختلف تمامًا عن مشكلة في ذاكرة التخزين المؤقت للمتصفح أو مهلة اتصال WebSocket.
استبعدت المتصفحات المتعددة وجود خلل خاص بمتصفح معين
اختبر المستخدمون Firefox وChrome/Chromium وSafari وBrave وOpera وEdge والنوافذ العادية وأوضاع التصفح الخاص/المتخفي. وظل السلوك كما هو.
كان ذلك الاختبار السلبي مفيدًا لأن سؤال IceWhale الأول في استكشاف الأخطاء وإصلاحها كان عمّا إذا كانت المشكلة قد تكون خاصة بالمتصفح.
أظهرت أدوات المطور فشل WebSocket بعد تعطل الواجهة الخلفية
يشترك المستخدمون المتأثرون في جيل Intel Celeron N3450
قارن مستخدم لجهاز ZimaBoard 832 ومستخدم لجهاز ZimaBlade بين العتاد، ولاحظا أنهما يشتركان في وحدات معالجة مركزية من فئة Intel Celeron N3450. وسألا عما إذا كان ملف btop الثنائي قد جرى تجميعه لمجموعة تعليمات أحدث خاصة بوحدة المعالجة المركزية في ZimaCube.
أكدت IceWhale هذه الفرضية لاحقًا.
أكدت IceWhale أن هدف الترجمة البرمجية كان خاطئًا
في 27 مارس، كتب Zima-Giorgio أن المشكلة حُدّدت وسيُعالجها الإصدار 1.4.0 من ZimaOS، لأن إصدار btop الأصلي لم يأخذ وحدة المعالجة المركزية في ZimaBoard بعين الاعتبار.
هذا هو الاستنتاج الأقوى من المصدر، وينبغي أن يحل محل الإصلاحات التخمينّية مثل إعادة تثبيت المتصفحات أو تثبيت ملف btop ثنائي آخر يدويًا على مضيف ZimaOS غير القابل للتغيير.
كان تغيّر المنفذ المرتفع مقصودًا
أوضح CorrectRoadH من IceWhale أن فتح btop على منفذ مرتفع مختلف في كل مرة كان ميزة أمان تهدف إلى جعل إعادة استخدام جلسة المراقبة المؤقتة مباشرةً أكثر صعوبة.
لذلك لم يكن تغيّر المنفذ بحد ذاته دليلًا على العطل.
لا تشخّص btop الحالي استنادًا إلى خطأ الإصدار 1.3.3 وحده
يتجاوز ZimaOS الحالي الإصدارين 1.3.3 و1.4.0 بفارق كبير. إذا تعطل btop اليوم، فسجّل إصدار ZimaOS الحالي، وطراز وحدة المعالجة المركزية، ورسالة الخطأ الدقيقة في الطرفية، وما إذا كان الاختصار في لوحة المعلومات أو واجهة سطر الأوامر فقط هو المتأثر.
An تعليمة غير قانونية في جهاز حديث، قد يظل ذلك يشير إلى توافق وحدة المعالجة المركزية، لكن ينبغي التحقيق فيه باعتباره تراجعًا جديدًا بدلًا من افتراض أنه الحزمة القديمة لعام 2025.
لماذا ظهر خطأ WebSocket بعد خطأ وحدة المعالجة المركزية
تُشغّل لوحة المعلومات جلسة تفاعلية شبيهة بالطرفية لـ btop. وإذا انتهت عملية btop فورًا بسبب تعليمة غير قانونية للمعالج، تفقد الواجهة الأمامية الواجهة الخلفية التي تتوقع التواصل معها. لذلك، قد تكون رسائل إغلاق WebSocket ورفض الاتصال آثارًا ثانوية لتعطل العملية.
هذا درس عام مفيد في استكشاف الأخطاء وإصلاحها: لا يكون خطأ وحدة تحكم المتصفح الأول دائمًا هو السبب الجذري. قارن بينه وبين ما يحدث عند تنفيذ الأمر الأساسي مباشرةً.
أضاف تعطل اختصار مدير الشبكة دليلًا آخر
قال أحد المستخدمين المتأثرين إن اختصاري مدير الموارد ومدير الشبكة كليهما تسببا في سلوك إعادة الاتصال نفسه، بينما عملت الوحدة الطرفية العادية على الويب بشكل طبيعي. وقد أشار ذلك إلى أن الفشل كان مرتبطًا ببيئة الأداة التي يشغّلها الاختصار، وليس بانقطاع كامل في ttyd.
كان لا يزال يتعين على IceWhale الحصول على btop وأبلغ عن التعطل وشارك معلومات العتاد N3450 لتحديد مشكلة هدف التجميع الفعلية.
لن تؤدي إعادة تثبيت الإصدار 1.3.3 نفسه إلى تغيير تعليمات المعالج
بعد أن أكدت IceWhale أن الملف الثنائي نفسه جرى تجميعه دون مراعاة معالج ZimaBoard، لم يكن بإمكان إعادة تثبيت المتصفحات أو مسح ذاكرة التخزين المؤقت أو إعادة تثبيت إصدار النظام نفسه تصحيح مجموعة تعليمات الملف التنفيذي.
تطلب الإصلاح الدائم ملفًا ثنائيًا مُعاد تجميعه يُسلَّم في إصدار ZimaOS التالي.
يشمل توافق العتاد الملفات الثنائية في مساحة المستخدم، وليس برامج تشغيل النواة فقط
غالبًا ما تركز مناقشات التوافق على برامج تشغيل بطاقات الشبكة أو وحدات معالجة الرسومات أو وحدات التخزين. لكن هذه الحادثة توضح أن نظام تشغيل x86 عامًا قد يتعطل أيضًا على المعالجات الأقدم إذا جرى تجميع تطبيق مضمّن باستخدام تعليمات لا تنفذها الأجهزة.
بالنسبة إلى أجهزة x86 التابعة لجهات خارجية، هناك تعليمة غير قانونية ولذلك، تُعد الرسالة دليلًا قيّمًا وينبغي تضمينها حرفيًا في تقرير الدعم.
الأسئلة الشائعة حول توافق btop
هل كانت مشكلة المصدر ناتجة عن Firefox أم Chrome؟
لا. أعاد المستخدمون إنتاج المشكلة عبر العديد من المتصفحات والأوضاع الخاصة.
ما السبب الجذري الذي قالت IceWhale إنه وراء المشكلة؟
تم تجميع ملف btop الثنائي دون مراعاة مجموعة تعليمات معالج ZimaBoard.
ما الإصدار الذي كان من المفترض أن يصلح المشكلة؟
قال Zima-Giorgio إن إصدار btop المصحح سيصل مع ZimaOS 1.4.0.
