कर्नेल अपडेट के बाद 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
अगर मॉड्यूल लोड होने से मना करता है, तो कर्नेल लॉग कारण बताता है, और संस्करण बेमेल केवल एक संभावना है। दोबारा बनाने से पहले वह पंक्ति पढ़ें, क्योंकि दूसरा वही बिल्ड उन्हीं दस मिनट को खर्च करता है और वही अस्वीकृति देता है। फिर अस्थायी इंटरफ़ेस हटा दें ताकि अगला परीक्षण साफ़ स्थिति से शुरू हो।