وحدة WireGuard لا تُحمَّل بعد تحديث النواة؟ تحقّق من هذا

كان النفق يعمل أمس، ثم أُعيد تشغيل الجهاز بعد تحديث، والآن لا ترتفع الواجهة. في نظام تُبنى فيه وحدة WireGuard كوحدة خارجية، السبب المعتاد أن الوحدة الموجودة على القرص تنتمي إلى إصدار نواة مختلف عن الإصدار العامل الآن. لا تُثبت الرؤوس ذات الاسم المشابه على الجهاز نفسه شيئًا عن ذلك التطابق. سلسلة الإصدار هي الشيء الوحيد الذي يحسم ذلك.

النواة العاملة أم النواة المثبّتة

يُثبّت التحديث حزمة نواة جديدة ويترك القديمة على القرص حتى يعيد الجهاز التشغيل. بعد إعادة التشغيل يتغيّر الإصدار العامل، وتصبح أي وحدة بُنيت مقابل الإصدار السابق غير قابلة للاستخدام رغم أن ملفاتها لا تزال موجودة. تفسّر تلك الفجوة التقرير المألوف عن جهاز كان سليمًا قبل إعادة التشغيل ومعطوبًا بعدها، دون أي تغيير في الإعدادات بينهما. وتفسّر أيضًا لماذا يبدو إعادة تثبيت الرؤوس أحيانًا وكأنه يصلح المشكلة وأحيانًا لا.

قد تتوافق حزمة الرؤوس التي تثبّتها مع أحدث حزمة نواة بدلًا من النواة التي أقلعت فعليًا، ولا شيء في اسم الحزمة يميّز تلك الحالات؛ سلسلة الإصدار وحدها تفعل ذلك. تحقّق مما يعمل قبل أن تتحقّق مما هو مثبّت.

ثلاثة فحوص قبل إعادة البناء

الفحص الأول هو أي نواة تعمل. والثاني هو ما إذا كانت وحدة لذلك الإصدار موجودة ويمكن العثور عليها. والثالث هو ما إذا كانت النواة قد حمّلتها بالفعل. أما السؤال الرابع، أي هل يمكن إنشاء الواجهة، فيختبر الصلاحيات لا الوحدة، لذا موضعه بعد إعادة البناء لا في هذه القائمة.

تجيب الأوامر أدناه عن الفحوص الثلاثة الأولى دون تغيير أي شيء. اقرأ كل نتيجة قبل المتابعة، لأن كل جواب يستبعد إصلاحًا مختلفًا.

uname -r
ls -l /lib/modules/$(uname -r)/build
modinfo wireguard
lsmod | grep wireguard

إذا أفاد السطر الثاني بأن المسار غير موجود، فبيئة البناء الخاصة بالنواة العاملة مفقودة ولن يطابقها أي شيء تبنيه. إذا فشل modinfo مع وجود المسار، فقد لا تكون الوحدة مثبّتة على الإطلاق، وهذا طبيعي في النوى التي تشحن التنفيذ داخل الشجرة. إذا نجح modinfo ولم يُظهر lsmod شيئًا، فالوحدة موجودة لكنها غير محمّلة، وهذه مشكلة وقت تحميل لا مشكلة بناء. كل نتيجة ترسلك إلى مكان مختلف، ولهذا فإن القراءة أهم من الأوامر.

ابنِ مقابل الإصدار العامل

تُبنى الوحدة الخارجية مقابل شجرة نواة مُهيّأة، ويصف دليل النواة للوحدات الخارجية استخدام دليل البناء الذي يخص النواة العاملة بدلًا من أي دليل يحمل أعلى رقم إصدار. دليل البناء ذلك رابط رمزي تديره حزمة النواة، لذا يشير إلى الشجرة الخاصة بالإصدار المُقلع حاليًا. المقصود هو هذا التوجيه غير المباشر: فهو يزيل خيارًا كنت ستحصل عليه خطأً. وتسميته صراحة تجعل الهدف غير ملتبس.

ثمة تفصيل يهم عندما تكون الشجرة مُهيّأة فقط لا مبنية بالكامل. هدف التحضير لا ينتج ملف إصدارات الرموز الذي تحتاجه بعض عمليات البناء الخارجية، لذا فشجرة مليئة بالرؤوس ليست تلقائيًا بيئة بناء كاملة. إذا فشل بناء بسبب رموز مفقودة، فذلك الملف هو أول ما يجب فحصه.

sudo make -C /lib/modules/$(uname -r)/build M=$(pwd) modules
sudo make -C /lib/modules/$(uname -r)/build M=$(pwd) modules_install
sudo depmod -a

حين تتأخر الرؤوس المحزومة

في التوزيعات وأجهزة اللوح الواحد التي تحزم نواها الخاصة، قد تتأخر الرؤوس عن الإصدار بأيام أو أسابيع. قد تكون حزمة الرؤوس صحيحة الاسم وأقدم مضمونًا، فتُنتج بناءً يُترجم ثم يفشل عند التحميل بدلًا من أثناء الترجمة. خلط المصادر يزيد الأمر سوءًا: نواة توزيعة مع رؤوس من مستودع طرف ثالث، أو نواة مورد مع رؤوس عامة، قد تُترجم بلا أخطاء ومع ذلك ترفضها النواة العاملة لأن الإعداد مختلف. أرقام الإصدارات وحدها لا تحسم ذلك.

إذا كان الجهاز يتبع قناة نواة تجريبية، فقرّر بوعي ما إذا كنت ستبقى فيها بمخرجات بناء مطابقة أم ستعود إلى مجموعة الحزم المدعومة. تكرار التحديث والأمل في أن تتوافق الأجزاء ليس خطة، لأن التطابق الخاطئ نفسه يتكرر في كل مرة.

تحقّق من الواجهة بعد إعادة البناء

بعد تثبيت ناجح، إنشاء الواجهة هو الاختبار المهم، يتبعه قراءة ما حمّلته النواة فعليًا وما يقوله السجل إن رفضت. الوحدة التي تُحمّل والواجهة التي لا يمكن إنشاؤها فشلان مختلفان ولهما سببان مختلفان. الأوامر الثلاثة أدناه تفصل بينهما.

sudo ip link add wg9 type wireguard
lsmod | grep wireguard
sudo dmesg | tail -5

إذا رفضت الوحدة التحميل، يذكر سجل النواة السبب، وعدم تطابق الإصدار ليس إلا احتمالًا واحدًا من الاحتمالات. اقرأ ذلك السطر قبل إعادة البناء، لأن بناءً ثانيًا مطابقًا يستهلك نفس عشر دقائق وينتج نفس الرفض. أزل الواجهة المؤقتة بعد ذلك كي يبدأ الاختبار التالي من حالة نظيفة.