डिस्ट्रो नाम, glibc वा कम्पाइलर: इन्स्टलरले के जाँच्छ

इन्स्टलरले “unsupported distribution” छाप्छ, तपाईं एउटा स्ट्रिङ सम्पादन गर्नुहुन्छ र एक मिनेटपछि लोडर त्रुटिसँग असफल नहुञ्जेल त्यो अगाडि बढ्छ। त्यही क्रम नै चिन्न लायक लक्षण हो: पहिलो असफलता पहिचान जाँच थियो र दोस्रो उपयुक्तताको सीमा हो। एउटै टर्मिनलमा संयोगवश देखिने यी दुई फरक समस्या हुन्। जाँच सम्पादन गर्नाले तपाईंलाई पहिलोबाट दोस्रोमा मात्र सार्न सक्छ।

लक्षण: इन्स्टलर तपाईंको व्युत्पन्नमा रोकिन्छ

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

समस्या तब सुरु हुन्छ जब वैकल्पिक उपाय नै योजना बन्छ। पहिचान फाइल बदल्दा जाँच पास हुन्छ, र त्यसपछि प्याकेज वास्तवमा स्थापित रनटाइमविरुद्ध लोड हुन्छ, वा हुँदैन। त्यहाँ असफल भयो भने थप पहिचान सम्पादनले काम गर्दैन।

त्यसैले उपयोगी कदम भनेको इन्स्टलरले कुन प्रश्न सोध्यो भन्ने पत्ता लगाउनु, र त्यसपछि उत्तरको महत्त्व हुन्थ्यो कि भन्ने पत्ता लगाउनु हो। यी दुई छुट्टै अनुसन्धान हुन् र प्याकेज चल्छ कि चल्दैन भन्ने दोस्रोले मात्र अनुमान गर्छ।

मानिसहरूले सिस्टम संस्करण भन्ने तीन संस्करण

डिस्ट्रिब्युसन रिलिजले प्याकेज गरिएको वातावरणको नाम दिन्छ। C लाइब्रेरी संस्करणले रनटाइम कार्यान्वयन र त्यसको रिलिजको नाम दिन्छ। कम्पाइलर संस्करणले उपकरण शृंखलाको नाम दिन्छ। कुराकानीमा मानिसहरू तीनैलाई “सिस्टम संस्करण” भन्छन्, तर इन्स्टलरमा ती एकअर्काको सट्टा प्रयोग गर्न मिल्दैन।

cat /etc/os-release
ldd --version | head -1
gcc --version | head -1
uname -m

अगाडि नै बनाइएको अनुप्रयोगले लिङ्क गरिएको बेला भएको रनटाइम अपेक्षा गर्छ। होस्टमा कम्पाइलर बदल्दा त्यो फेरि लिङ्क हुँदैन, र नयाँ उपकरण शृंखलाले बाइनरीले माग्ने लोडर चिन्हहरूमा केही बदल्दैन। आर्किटेक्चर फेरि छुट्टै महत्त्वपूर्ण हुन्छ, किनकि 64-बिट प्रणालीमा 32-बिट प्याकेज कुनै पनि संस्करण स्ट्रिङले व्याख्या नगर्ने कारणले असफल हुन्छ।

चारै आउटपुट प्रतिवेदनसँग राख्नुहोस्। ती जम्मा गर्न दस सेकेन्ड लाग्छ र मर्मतकर्ताले इमेलमा सोध्ने अधिकांश प्रश्नको उत्तर दिन्छन्।

त्रुटि पढ्नुहोस्, जाँच होइन

पहिलो लन्च त्रुटि नै प्रमाण हो। हराएको साझा वस्तु, वा लोडरले पूरा गर्न नसक्ने चिन्ह संस्करणबारे सन्देश रनटाइम निर्भरताको समस्या हो। डिस्ट्रिब्युसनको नाम दोहोर्याउने सन्देश फेरि पहिचान जाँच हो, अर्को ठाउँमा।

डाइनामिक लिङ्करको कागजात ले लाइब्रेरी खोज कसरी काम गर्छ र लोडर कहाँ खोज्छ भन्ने वर्णन गर्छ। डिस्ट्रिब्युसन लेबल बदल्दा त्यो खोज मार्गमा कुनै डाइरेक्टरी थपिँदैन, त्यसैले दोस्रो असफलता पहिलोसँग असम्बन्धित देखिन्छ।

डाउनलोड गरिएको कार्यान्वयन योग्य फाइलमा ldd लाई सामान्य पहिलो कदमका रूपमा प्रयोग नगर्नुहोस्। यसको आफ्नै म्यानुअलले केही परिस्थितिमा यसले कार्यक्रम चलाउन सक्ने चेतावनी दिन्छ, र अविश्वसनीय इन्स्टलर चलाउनु ठ्याक्कै त्यही अवस्था हो जसबारे त्यो चेतावनी हो।

स्ट्रिङ सम्पादन गर्दा किन मद्दत गर्दैन

अपरेटिङ सिस्टमको पहिचान बनावटी बनाउँदा मेसिनको हरेक कार्यक्रमले आफूलाई कसरी देख्छ भन्ने बदलिन्छ। प्याकेज म्यानेजर, समर्थन उपकरण र अन्य अनुप्रयोगले त्यही फाइल पढ्छन्, र एउटा इन्स्टलरलाई सन्तुष्ट गर्ने मानले महिनापछि अरू केहीलाई अलमल्याउन सक्छ।

होस्ट लाइब्रेरीहरूलाई अर्को डिस्ट्रिब्युसनका फाइलले प्रतिस्थापन गर्नु अझ नराम्रो हो। यसले असम्बन्धित सफ्टवेयर तोड्न सक्छ, प्याकेज म्यानेजरलाई अदृश्य हुन्छ, र कसैले नलेख्ने मर्मत योजना आवश्यक पर्छ। ती परिवर्तनलाई एउटा प्रतिबन्धात्मक इन्स्टलरले न्यायोचित ठहराउँदैन।

यदि जाँच साँच्चै पहिचानको दोष हो भने, मर्मतकर्ताले त्यसको पुष्टि गरी समर्थित सुधार वर्णन गर्न सक्छ। दोष होइन भने, समर्थित मार्ग तपाईंको प्लेटफर्मका लागि बिल्ड हो, र स्ट्रिङ सम्पादन भएको कारणले त्यो उत्तर बदलिँदैन।

मर्मतकर्ताले कारबाही गर्न सक्ने प्रतिवेदन लेख्नुहोस्

डिस्ट्रिब्युसन र रिलिज, आर्किटेक्चर, VPN रिलिज, अस्वीकार गरिएको ठ्याक्कै शर्त र त्यहाँसम्म पुग्नुभएको भए पहिलो रनटाइम त्रुटि रेकर्ड गर्नुहोस्। तपाईंले केही बदल्नुभयो कि भनेर उल्लेख गर्नुहोस्, किनकि बदलिएको प्रणालीबाट आएको प्रतिवेदन फरक प्रतिवेदन हो।

मूल इन्स्टलरलाई अपरिवर्तित राख्नुहोस् र यसलाई छल्नुको सट्टा जाँचको वर्णन गर्नुहोस्। यही भिन्नताले मर्मतकर्तालाई अत्यन्त साँघुरो पहिचान नियमलाई वास्तविक बाइनरी उपयुक्तता सीमाबाट छुट्याउन दिन्छ, र ती दुई धेरै फरक बग र दुई धेरै फरक सुधार हुन्।

तपाईंको प्लेटफर्म समर्थित छैन भन्ने उत्तर आयो भने, त्यो उपयोगी नतिजा हो। कहिल्यै समस्या नभएका पहिचान फाइलहरूमा अर्को साँझ नबिताई समर्थित बिल्ड खोज्न भन्छ।