الخلاصة: استخدم خانة ZimaOS البديلة أولًا، ثم شخّص الاعتمادية المحددة التي تسببت في وضع الطوارئ
كان لدى ZimaOS 1.3.2 مشكلة توافق معروفة مع بعض الأجهزة التابعة لجهات خارجية في أوائل عام 2025. في حالة Proxmox هذه، كان لا يزال بإمكان الخانة A تشغيل الإصدار الأقدم، بينما دخلت الخانة المحدّثة في وضع الطوارئ. وهذا تحديدًا ما صُمم نظام A/B للحماية منه.
الخطوة 1: إقلاع الخانة السابقة من GRUB
اتصل بوحدة التحكم، وافتح GRUB باستخدام مفاتيح الأسهم، ثم اختر خانة النظام البديلة. لا يزال ZimaOS الحالي يستخدم قسمَي نظام لإتاحة التراجع السريع. يشرح استرداد نظام ZimaOS العملية الحالية.
يوفّر نموذج خانات RAUC مفهوم الخانات الأساسي.
الخطوة 2: اقرأ أول فشل حقيقي، وليس آخر سطر متعلق بوضع الطوارئ
وضع الطوارئ هو النتيجة. ابحث فوقه عن أول جهاز انتهت مهلته، أو نقطة تحميل فاشلة، أو اعتمادية مفقودة. في هذه الحالة، أشارت الشاشة إلى جهاز تخزين قبل ظهور أعطال الاعتماديات اللاحقة.
journalctl -xb
systemctl --failed
lsblk -f
cat /etc/fstabالخطوة 3: تحقّق من إدخالات fstab المخصصة قبل إعادة التثبيت
كشف فرع لاحق من الحالة نفسها عن سبب ثانٍ مهم: يمكن أن تمنع تغييرات /etc/fstab اليدوية إقلاع ZimaOS عندما يكون الجهاز المشار إليه مفقودًا أو يتعارض ترتيب التحميل مع عملية إقلاع الجهاز. وأبلغت IceWhale عن عطل مماثل شمل كلًا من /etc/fstab ونسخة persistent overlay.
إذا أضفت إدخالات RAID أو تحميل مخصصة يدويًا، فقارنها بتهيئة التخزين الحالية وأزل الإدخالات التي تفهمها فقط. ولعمليات RAID وتحميل الأقراص العادية، يُفضّل استخدام واجهة التخزين في ZimaOS.
لماذا لا يُعد عطل برنامج التشغيل القديم في 1.3.2 مشكلة عامة حالية
أقرّ فريق الهندسة بوجود مشكلات توافق مع الجهات الخارجية في ذلك الإصدار المحدد. وقد تجاوز ZimaOS الإصدار 1.3.2 بعدة إصدارات، لذلك ينبغي التعامل مع عبارة «تسبب 1.3.2 في تعطل آلة Proxmox الافتراضية لدي» باعتبارها دليلًا تاريخيًا، لا تشخيصًا لنظام عام 2026.
يُعد استرداد تثبيت ZimaOS خط الأساس الحديث لأجهزة x86 التابعة لجهات خارجية.
عندما يدخل التثبيت الجديد أيضًا في وضع الطوارئ
هذه إشارة قوية إلى أن المشكلة مرتبطة بالأجهزة الافتراضية، أو أقراص البيانات المتصلة، أو حالة التحميل الدائمة، أو تهيئة المضيف غير المدعومة، وليس بقسم النظام القديم وحده. ابدأ بأدنى قدر من الأجهزة الافتراضية اللازمة، ثم أضف أقراص البيانات واحدًا تلو الآخر.
احمِ البيانات قبل تعديل بيانات RAID الوصفية أو بيانات التحميل
لا تمسح تواقيع mdadm ولا تُعد إنشاء المصفوفات أثناء استكشاف أخطاء خانة الإقلاع وإصلاحها. يفصل استرداد RAID بين استرداد الإقلاع واسترداد المصفوفة، بينما يغطي النسخ الاحتياطي في ZimaOS طبقة الأمان.
اعرف ما يستطيع GRUB إصلاحه وما لا يستطيع
يمكن لـ GRUB اختيار خانة نظام ZimaOS السابقة، لكنه لا يصلح تحميل بيانات معطّلًا أو إدخال نظام ملفات غير صالح. تشرح عناصر تحكم GNU GRUB طبقة محمّل الإقلاع. إذا أقلعت الخانة السابقة، فاستخدم بيئة العمل تلك لفحص تهيئة التخزين ونسخ البيانات احتياطيًا قبل تغيير الخانة الفاشلة.
الأسئلة الشائعة
لماذا يقلع ZimaOS من الخانة القديمة وليس الجديدة؟
تحتوي الخانة القديمة على صورة النظام السابقة التي كانت تعمل. وقد تعاني الخانة الجديدة من مشكلة في برنامج تشغيل أو تحميل أو تهيئة.
هل يعني وضع الطوارئ أن بياناتي فُقدت؟
لا. يعني ذلك فشل الاعتماديات اللازمة للإقلاع العادي. افحص حالة التخزين والتحميل قبل افتراض فقدان نظام الملفات.
هل يمكن لإدخال fstab سيئ أن يمنع إقلاع ZimaOS؟
نعم. يمكن لتحميل يتعذر إتمامه أن يمنع الإقلاع أو يرسل النظام إلى وضع الطوارئ.
هل ينبغي أن أعيد التثبيت فورًا؟
لا. جرّب خانة A/B البديلة أولًا، وسجّل أول اعتمادية فاشلة. أعد التثبيت فقط عندما لا يكون الاسترداد عمليًا.
هل ZimaOS مدعوم في Proxmox؟
قد تنجح عمليات النشر الافتراضية، لكن الأجهزة الافتراضية التابعة لجهات خارجية قد تكشف اختلافات في التوافق. اختبر الإصدار الحالي واحتفظ بمسار للتراجع.
