VPN इन्स्टलरले 32-बिट भन्छ: बरु ELF हेडर जाँच्नुहोस्

एउटा डाउनलोड पृष्ठले 32-बिट भन्छ, फाइल Raspberry Pi मा अवतरण हुन्छ, र इन्स्टलर समस्याको कुनै उपयोगी भाग नाम नराख्ने सन्देशसँग असफल हुन्छ। दुई पूर्ण रूपमा भिन्न कार्यान्वयन योग्य फाइलहरू ELF अर्थमा दुवै 32-बिट गनिन्छन्, र तीमध्ये एउटा मात्र त्यो बोर्डमा चल्न सक्छ। क्लास फिल्ड एउटा तथ्य हो, मेसिन फिल्ड अर्को, र फाइलको नामले तपाईंलाई दुवैमध्ये कुनै पनि भरपर्दो रूपमा भन्दैन। पुस्तकालय बदल्नु वा अर्को ऐना प्रयास गर्नु अघि हेडर पढ्नुहोस्।

क्लासले शब्दको आकार भन्छ, मेसिनले निर्देशन समूह

Linux ELF सन्दर्भ ले फाइल हेडरमा क्लास फिल्ड र मेसिन फिल्ड परिभाषित गर्छ, र दुवैले फरक प्रश्नको उत्तर दिन्छन्। क्लासले फाइलले 32-बिट वा 64-बिट रूप प्रयोग गर्छ कि भन्छ; मेसिनले त्यो कुन निर्देशन समूहका लागि बनाइएको हो भन्छ। 32-बिट x86 build र 32-बिट ARM build पहिलोमा सहमत र दोस्रोमा फरक छन्। यसरी सही शब्द आकारको वाचा गर्ने लेबलले पनि प्रोसेसरले डिकोड गर्न नसक्ने कोड दिन्छ। पढ्न लायक तेस्रो मान मागिएको इन्टरप्रेटर हो, जसको नाम प्रोग्राम हेडरहरूले बाइनरीले एउटा घोषणा गर्दा राख्छन्।

readelf -h -- ./vendor-vpn
readelf -l -- ./vendor-vpn
readelf -d -- ./vendor-vpn | grep NEEDED

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

यसले कर्नेलबाट कुन इन्टरप्रेटर माग्छ

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

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

file --brief ./vendor-vpn

डाउनलोडलाई प्याकेज आर्किटेक्चरसँग मिलाउनुहोस्

वितरणका प्याकेज आर्किटेक्चरहरूले त्यही भिन्नतालाई आफ्नै शब्दावलीमा सङ्केत गर्छन्, र विक्रेताको सहयोग वक्तव्यले त्यही शब्दावलीलाई सन्दर्भ गर्छ। तपाईंको प्याकेज प्रबन्धकले जनाउने मानको तुलना विक्रेताले कागजातमा राखेको मानसँग गर्नुहोस्, फाइल नामसँग मार्केटिङ लेबलको तुलना गर्नुको सट्टा। समस्या पार्ने जोडीहरू amd64 विरुद्ध arm64, र armhf विरुद्ध armel हुन्, किनकि हरेक जोडी डाउनलोड सूचीमा अदलबदल गर्न सकिने देखिन्छ। x64 वा ia32 मा अन्त्य हुने फाइल नामले build लक्ष्य वर्णन गर्छ, त्यसलाई राख्ने मेसिन होइन।

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

dpkg --print-architecture

ENOEXEC र ENOENT फरक असफलता हुन्

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

ENOEXEC भनेको ढाँचा चिनिएन: गलत आर्किटेक्चर, गलत क्लास वा बिल्कुलै कार्यान्वयन योग्य नभएको कुरा। ELF फाइलमा ENOENT ले सामान्यतया इन्टरप्रेटर छैन भन्ने बुझाउँछ, तपाईंले मागेको फाइल भए पनि। त्यही ENOENT ले स्क्रिप्टको इन्टरप्रेटर पनि छैन भन्ने बुझाउन सक्छ, त्यसैले स्क्रिप्टको पहिलो लाइन महत्त्वपूर्ण हुन्छ। जसरी भए पनि सन्देशले तहको नाम लिन्छ, र हरेक “भेटिएन” लाई हराएको कन्फिगरेसन मान्नुले अनुसन्धानलाई गलत दिशामा पठाउँछ। टिकटमा त्रुटिको मान उद्धृत गर्नुहोस्, किनकि त्यो वरपरको वाक्यभन्दा पुनः भनाइमा राम्रो टिक्छ।

बाइनरी सुरु नभए के गर्नु हुँदैन

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

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