الخلاصة: تحقّق من المسار الافتراضي قبل إعادة تثبيت الحاويات
في الحالة الفعلية للإصدار 1.6.2، بدت Jellyfin وVaultwarden وتطبيقات أخرى وكأنها لا تبدأ، ولم تكن الإعدادات تُفتح، وفشلت الخدمات التي تعتمد على DNS، ولم تظهر بعض الحاويات إلا بعد تأخير طويل. ولم يكن الدليل الحاسم هو تلف Docker، بل أن المسار الافتراضي ذي أقل قيمة metric كان يشير إلى 192.168.1.0 بدلًا من البوابة الفعلية 192.168.1.1. وبعد تصحيح البوابة من خلال واجهة المستخدم الرسومية، عادت إمكانية الاتصال الخارجية ومجموعة التطبيقات إلى العمل.
تحقّق أولًا مما إذا كانت الحاويات متوقفة فعلًا
docker ps -a
docker info | grep -iE 'Docker Root Dir|Storage Driver'
docker stats --no-streamإذا كانت الحاويات في حالات Created أو Restarting أو Exited، فتحقّق من سجلاتها. أما إذا كانت تعمل، لكن واجهات الويب الخاصة بها تعتمد على DNS أو Cloudflare أو واجهات برمجة تطبيقات بعيدة، فقد يكون الفشل ناتجًا عن إمكانية الوصول إلى الشبكة، لا عن بدء تشغيل الحاوية.
تحقّق بعد ذلك من المسارات الافتراضية للمضيف
ip route show default
ip route
كشفت الحالة الأصلية عن عدة مسارات افتراضية، وكان المسار غير الصالح يملك أقل قيمة metric، لذلك فضّله Linux. يشرح مقاييس المسارات في Linux قاعدة التوجيه هذه.
اختبر عنوان IP مباشرةً وDNS بشكل منفصل
ping -c 3 1.1.1.1
getent hosts cloudflare.com
curl -I https://example.comإذا فشل 1.1.1.1، فأصلح التوجيه قبل DNS. وإذا نجح الاتصال بعنوان IP مباشرةً لكن فشلت أسماء النطاقات، فتحقّق من DNS. ويمنع ذلك تشخيص بوابة معطلة خطأً على أنها مشكلة في Pi-hole أو Cloudflare أو DNS الخاص بـ Docker.
صحّح واجهة الشبكة في ZimaOS
افتح الإعدادات ← الشبكة، وحدد الواجهة التي تحمل المسار الافتراضي، وتحقق من عنوان IP الثابت والشبكة الفرعية والبوابة وDNS. يعرض ZimaOS حاليًا كل منفذ Ethernet فعلي بشكل منفصل. وتوضح إعدادات شبكة ZimaOS نموذج الإعداد الحالي.
تغطي شبكات تطبيقات ZimaOS طبقة التطبيقات.
لماذا قد تجعل البوابة السيئة نصف التطبيقات تبدو وكأنها تعطلت؟
قد تبدأ التطبيقات التي لا تعتمد إلا على موارد محلية فورًا. بينما تنتظر تطبيقات أخرى سجلات صور الحاويات أو DNS أو قواعد بيانات بعيدة أو خدمات الشهادات أو واجهات برمجة التطبيقات السحابية. لذلك ينشئ المضيف ذو الاتصال الشبكي الجزئي مجموعة أعراض مختلطة تبدو عشوائية. ويؤدي إصلاح كل حاوية على حدة إلى إهدار الوقت عندما تكون المشكلة المشتركة في مسار المضيف.
كان الإصدار 1.6.2 إصدارًا للأمان والتوافق
تركز ملاحظات الإصدار الرسمية لـ 1.6.2 على أمان الحسابات والملفات والرسائل، وتعزيز أمان SSH، وتغييرات النواة وبرامج التشغيل، وإصلاحات USB وإصلاحات RAID؛ ولا توثق تغييرًا مقصودًا في البوابة. لذلك من الأفضل التعامل مع الحالة الأصلية باعتبارها تراجعًا محتملًا في ترحيل إعدادات الشبكة، لا سلوكًا مصممًا. وتوفر تغييرات ZimaOS 1.6.2 خط الأساس الرسمي.
حدّث إلى الإصدار المستقر الحالي قبل ملاحقة أخطاء 1.6.2 القديمة
حسّن ZimaOS 1.7.1 لاحقًا كفاءة بدء تشغيل Docker، وشبكات Docker أثناء التثبيت، ومعالجة عناوين URL الديناميكية، وسلوك متجر التطبيقات. إذا كان النظام لا يزال على 1.6.2، فانسخ البيانات المهمة احتياطيًا وانتقل إلى السلسلة المستقرة الحالية قبل افتراض استمرار الخطأ القديم نفسه.
تُعد النسخة الاحتياطية في ZimaOS طبقة الأمان.
يعني التراجع تشغيل فتحة A/B البديلة، لا الرجوع اعتباطيًا إلى إصدار أقدم
توثق مواد الاسترداد العامة الحالية تشغيل فتحة النظام البديلة عند فشل الفتحة الحالية. لكنها لا تَعِد بإمكانية الرجوع المدعوم بنقرة واحدة إلى أي إصدار تاريخي. ويُعد استرداد نظام ZimaOS مسار الاسترداد الحالي المشابه للرجوع.
إذا أصلحت التوجيه لكن استمر فشل تحليل الأسماء، فقارن خادم DNS المُعدّ مع محلل مستقل. يمكن أن يساعد اختبار DNS من Cloudflare في إثبات ما إذا كان الفشل المتبقي خاصًا بالمحلل، لا بمشكلة بدء تشغيل Docker.
الأسئلة الشائعة
لماذا تعطلت بعض التطبيقات فقط بعد 1.6.2؟
قد تفشل التطبيقات التي تعتمد على DNS أو الشبكة الخارجية، بينما تستمر الحاويات المحلية بالكامل في العمل.
كيف أعرف أن البوابة الافتراضية خاطئة؟
استخدم ip route وتحقق من أن المسار الافتراضي ذي أقل قيمة metric يشير إلى عنوان جهاز التوجيه الفعلي.
هل ينبغي أن أعيد تثبيت Jellyfin أو Vaultwarden أولًا؟
ليس قبل التحقق من توجيه المضيف وDNS وحالة الحاويات.
هل يمكنني إعادة ZimaOS إلى أي إصدار أقدم؟
يركز الاسترداد العام الحالي على تشغيل فتحة A/B البديلة بدلًا من الرجوع اعتباطيًا إلى إصدار تاريخي.
هل ينبغي أن أبقى على 1.6.2؟
إن أمكن، أنشئ نسخة احتياطية وانتقل إلى الإصدار المستقر الحالي، ثم أعد اختبار أي مشكلة متبقية.
