कर्नेल अपडेटनंतर 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

मॉड्यूल लोड होण्यास नकार देत असेल, तर कर्नेल लॉग कारण सांगतो, आणि आवृत्तीची विसंगती ही केवळ एक शक्यता आहे। पुन्हा तयार करण्यापूर्वी ती ओळ वाचा, कारण दुसरे तसेच बिल्ड तेच दहा मिनिटे खर्चून तोच नकार देते। नंतर तात्पुरता इंटरफेस काढून टाका, जेणेकरून पुढील चाचणी स्वच्छ स्थितीतून सुरू होईल।