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 आवृत्ती, पॅकेज आर्किटेक्चर, क्लास आणि मशीन स्ट्रिंग, मागितलेला इंटरप्रिटर आणि पहिली त्रुटी ओळ। तो संच सपोर्ट प्रश्न अयशस्वी इंस्टॉलरच्या स्क्रीनशॉटपेक्षा वेगाने सोडवतो। जुने कलाकृती आणि आठवणीतील फोरम आउटपुट सध्याचे सपोर्ट मॅट्रिक्स नाहीत, आणि नेटिव्ह बाइनरी लोड झाल्यानंतर प्रोफाइल, प्रमाणीकरण आणि राउटिंग वेगळे काम राहते।