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

मोड्युलले लोड हुन इन्कार गर्छ भने, कर्नेल लगले कारण बताउँछ, र संस्करण अमिलता केवल एउटा सम्भावना हो। पुनः निर्माण गर्नु अघि त्यो लाइन पढ्नुहोस्, किनकि दोस्रो त्यस्तै निर्माणले त्यही दस मिनेट खर्च गरी त्यही अस्वीकृति दिन्छ। त्यसपछि अस्थायी इन्टरफेस हटाउनुहोस् ताकि अर्को परीक्षण सफा अवस्थाबाट सुरु होस्।