قررت اليوم المضي قدمًا وترقية أحد خوادمي من Ubuntu 14.04 إلى 16.04. لا يوصى بإجراء ذلك على خادم إنتاج ، حيث توجد العديد من المشكلات التي يمكن أن تسوء. تشير أفضل الممارسات دائمًا إلى أن تشغيل خادم آخر إما كخادم بديل أو مؤقت هو الطريقة الأكثر أمانًا للذهاب. بعد قولي هذا ، من لا يستمتع بتجربة أشياء لا ينبغي القيام بها.
سارت الترقية بشكل جيد ، مع استثناء واحد صارخ ، لم تتمكن libvirt-bin من الترقية بشكل صحيح. فيما يلي خطوات إصلاح الموقف بالإضافة إلى الخطوات التي لن تفعل ذلك.
كانت التجربة الأولية لإصلاح المشكلة مع sudo dpkg –configure -a ، لا حظ هناك. حاولت أيضًا استخدام محلل aptitude التلقائي ، ثم التطهير وإعادة التثبيت. أيضا لا حظ.
للوصول إلى جذر المشكلة ، ركضت بدلاً من محاولة التخمين بحماقة
sudo journalctl -xe
كما هو موضح أعلاه ، تسبب خطأ في apparmor في عدم حصول libvirt-bin على إذن للتشغيل ، حيث لم يعد مهيئًا (مضحك كان من الممكن أن أقسم أنني أخبرته بذلك).
فيما يلي كيفية إصلاح المشكلة وجذر المشكلة. نحتاج أولاً إلى مسح ذاكرة التخزين المؤقت لمحلل apparmor ، نظرًا لأنه يحتوي على البيانات المخزنة مما يجعل libvirt-bin غير قادر على البدء.
sudo apparmor_parser –purge-cache
بعد ذلك نزيل القاعدة التي تمنع libvirt-bin من البدء.
ثم نمضي قدما ونستبدلها.
أخيرًا ، علينا إخبار libvirt بإعادة التشغيل ، وسيكون كل شيء جيدًا.
أعد تشغيل sudo systemctl libvirt-bin
للتحقق من حالة libvirt-bin ، أدخل الأمر التالي
حالة خدمة sudo libvirt-bin
سيؤدي هذا إلى إجراء فحص إحصائي صغير لطيف لـ libvirt-bin ، مما يوضح أن العملية الموضحة أعلاه قد أدت إلى الحيلة. الآن يمكننا تشغيل أجهزتنا الافتراضية مرة أخرى!
الأخطاء الأخرى التي أتحرى عنها حاليًا ، وما بعد الترقية ، وكذلك الحلول التي يمكن تنفيذها:
فشل بدء تشغيل LSB: exim Mail Transport Agent. كان هذا خطأ ما بعد الإصلاح ، وقد تم حله قبل تشغيل الجهاز بالكامل.
snd_hda_intel 0000: 00: 1f.3: فشل إضافة المكون الرئيسي i915_bpo (-19). هذا خطأ في بطاقة الصوت ، ويمكن تصحيحه عن طريق ترقية Alsa (لا أخطط لاستخدام الصوت خارج الخادم ، لذلك لا يؤثر هذا على الأداء).
أخيرا dev-disk-by x2duuid-E7A1 x2dCC4A.device: Dev dev-disk-by x2duuid-E7A1 x2dCC4A.device ظهر مرتين مع sysfs مختلف. على ما يبدو ، كان النسخ الاحتياطي لقسم EFI الخاص بي شاملاً بما يكفي لتسجيله على أنه نفس UUID بالضبط. يحتوي محرك NVMe (الأساسي) على UUID للقسم ، ولكن RAID (النسخ الاحتياطي) ليس كذلك. لتصحيح ذلك سأترك محرك الأقراص الأساسي وحده وأغير UUID لمحرك النسخ الاحتياطي باستخدام uuidgen ثم tune2fs / dev / sdx -U جديد -id-number-from-uuidgen.
2 دقيقة للقراءة
