إذا فشل كلٌّ من فتحتي إقلاع ZimaOS وأبلغت وحدة التحكم عن أخطاء تركيب overlay أو فشل قراءة superblock أو أخطاء إدخال/إخراج في NVMe، فلا تبدأ بإعادة إنشاء مجموعة التخزين. حدّد أولًا ما إذا كان العطل في جهاز الإقلاع أم في أقراص البيانات المنفصلة.
في هذه الحالة من يونيو 2026، أظهرت التشخيصات للقراءة فقط أخطاء وسائط متكررة في NVMe الخاص بالإقلاع، بينما كانت مجموعة بيانات Btrfs الكبيرة موجودة على أقراص منفصلة. استبدل المستخدم محرك الإقلاع، وأعاد تثبيت ZimaOS، ثم أكّد لاحقًا أن مجموعة البيانات لا تزال موجودة.
افصل جهاز الإقلاع عن مجموعة البيانات أولًا
أظهر ناتج صدفة الإنقاذ في النقاش وجود NVMe بسعة تقارب 119 جيجابايت يحتوي على أقسام إقلاع/بيانات ZimaOS، إلى جانب مجموعة Btrfs منفصلة متعددة الأقراص. غيّر هذا التمييز خطة الاستعادة: فشل NVMe الخاص بالإقلاع لا يعني تلقائيًا فشل مجموعة التخزين.
ابدأ بأوامر للقراءة فقط:
lsblk -o NAME,SIZE,FSTYPE,LABEL,UUID,MOUNTPOINTS
blkid
cat /proc/cmdlineدوّن أسماء الأجهزة الدقيقة قبل تشغيل أي أمر يستهدف قرصًا أو قسمًا.
تحقق من سجلات النواة بحثًا عن أخطاء إدخال/إخراج حقيقية
تضمنت الحالة الأصلية رسائل متكررة من نوع critical medium error وBuffer I/O error، وفشل تركيب EXT4، وأخطاء NVMe تستهدف جهاز الإقلاع. وتُعد هذه الرسائل دليلًا أقوى على فشل التخزين من رسالة عامة عن توقف النواة أثناء الإقلاع.
dmesg -T | grep -Ei 'nvme|I/O error|Buffer I/O|EXT4|superblock|reset|timeout|critical|media'إذا أشارت الأخطاء باستمرار إلى NVMe الخاص بالإقلاع، بينما لا تُبلغ أقراص البيانات عن أعطال، فواصل تركيز التحقيق على مسار الإقلاع.
نتيجة SMART «PASSED» لا تلغي أخطاء الوسائط
في النقاش، ظل ملخص صحة NVMe يعرض PASSED، إلا أن العدادات التفصيلية أظهرت 76 خطأً في الوسائط/سلامة البيانات، وكانت النواة تسجل بالفعل حالات فشل في القراءة. كما توقف فحص نظام الملفات للقراءة فقط بسبب كتل يتعذر قراءتها.
استخدم بيانات الصحة التفصيلية مثل smartctl -x /dev/nvmeXn1 أو nvme smart-log /dev/nvmeXn1 بعد التأكد من اسم الجهاز الصحيح. لا تتعامل مع كلمة الصحة العامة المفردة باعتبارها التشخيص الكامل.
استخدم فحوصات نظام الملفات للقراءة فقط أولًا
استخدم المجتمع الأمر e2fsck -fn على قسم overlay المتأثر بنظام EXT4، بحيث يمكن فحص نظام الملفات دون كتابة إصلاحات. وحتى هذا الفحص للقراءة فقط واجه كتلًا يتعذر قراءتها، مما عزز تشخيص فشل العتاد.
لا تشغّل أبدًا الأمر fsck في وضع الكتابة على نظام ملفات مُركّب، ولا تخمّن أسماء الأقسام. إذا كان قرص SSD الخاص بالإقلاع يتعطل فعليًا، فقد تجعل محاولات الكتابة المتكررة الاستعادة أكثر صعوبة.
لماذا قد تفشل الفتحتان A وB معًا؟
يستخدم ZimaOS فتحتي نظام A/B للاستعادة، كما هو موضح في دليل استعادة نظام ZimaOS. لكن كلا خياري الإقلاع لا يزال يعتمدان على مكونات تخزين مشتركة وسليمة على جهاز الإقلاع. لذلك يمكن أن يمنع overlay أو NVMe متعطلان في الإقلاع كلتا الفتحتين من إكمال بدء التشغيل.
متى يكون الاستبدال هو الخيار الأكثر أمانًا؟
بعد أن أظهرت الحالة الأصلية أخطاء وسائط في النواة، وعدادات تفصيلية لأخطاء الوسائط في SMART، وكتلًا يتعذر قراءتها في نظام الملفات على NVMe الخاص بالإقلاع، نصح المجتمع بالتعامل مع SSD هذا على أنه غير موثوق بدلًا من محاولة إصلاحه في مكانه. استبدله المستخدم وأعاد تثبيت ZimaOS بنجاح.
أثناء إعادة التثبيت، حدّد أقراص البيانات بوضوح وتجنب تهيئة مجموعة موجودة أو إعادة إنشائها. يساعدك دليل استكشاف أخطاء تثبيت ZimaOS وإصلاحها في جانب تثبيت الإقلاع، بينما يؤكد دليل استعادة التخزين بعد إعادة التثبيت القاعدة الأساسية: لا تُعد إنشاء مجموعة تحتوي بياناتك بالفعل.
الخلاصة
في هذه الحالة، كان توقف النواة ناتجًا عن فشل NVMe الخاص بالإقلاع، وليس دليلًا على تدمير مجموعة البيانات المنفصلة. أجرِ التشخيص للقراءة فقط، وتأكد من الجهاز الذي يحتوي على أخطاء الإدخال/الإخراج، واترك أقراص البيانات دون تغيير. استبدل المستخدم قرص الإقلاع المتعطل، وأعاد تثبيت ZimaOS، وأكّد بقاء مجموعة البيانات الحالية.
