તમારું VPN બાઈનરી આ CPU માટે બનેલું છે? ELF હેડર વાંચો
ELF વર્ગ અને મશીન અલગ ક્ષેત્રો છે, અને ઇન્ટરપ્રીટર ત્રીજું છે. Pi અથવા બીજા કોઈ બોર્ડ પર VPN ક્લાયન્ટ ઇન્સ્ટોલ કરતા પહેલાં ત્રણેય વાંચો.
બંને ફાઇલો 32-બિટ છે અને તેમાંથી માત્ર એક જ તમારા બોર્ડ પર ચાલે છે. Intel માટે ELF32 બિલ્ડ અને ARM માટે ELF32 બિલ્ડ વર્ગ ક્ષેત્ર પર સહમત છે અને જે કંઈ મહત્વનું છે તેમાં અસહમત છે. 32-બિટ વિકલ્પ આપતું ડાઉનલોડ પૃષ્ઠ તમે ખરેખર ડાઉનલોડ કરેલી ફાઇલનું હેડર વાંચ્યા સુધી તમને લગભગ કંઈ જ કહ્યું નથી. તેનું નામ બદલવાથી એક પણ સૂચના બદલાતી નથી.
વર્ગ અને મશીન જુદા જુદા પ્રશ્નોના જવાબ આપે છે
વર્ગ ક્ષેત્ર કહે છે કે ફાઇલ 32-બિટ કે 64-બિટ રચનાઓ વાપરે છે. મશીન ક્ષેત્ર એ સૂચના સમૂહનું નામ આપે છે જેના માટે ફાઇલ કમ્પાઇલ થઈ હતી. ફક્ત પહેલું વાંચવું એ જ રીતે x86 બિલ્ડ સંપૂર્ણ વિશ્વાસપાત્ર દેખાતા ફાઇલ નામ સાથે ARM બોર્ડ પર પહોંચે છે. બંને મૂલ્યો એક જ આદેશમાંથી આવે છે, તેથી એક છોડી દેવું એટલું સરળ છે.
એ જ ગૂંચવણ 64-બિટ લેબલોને પણ લાગુ પડે છે, જ્યાં aarch64 અને x86-64 શબ્દનું માપ વહેંચે છે અને એક પણ સૂચના વહેંચતા નથી. એક 64-બિટ ડાઉનલોડ સૂચિબદ્ધ કરતું વિક્રેતાનું પૃષ્ઠ તેનું પોતાનું બિલ્ડ વર્ણવે છે, તમારું મશીન નહીં. પૃષ્ઠ પરના સ્તંભ શીર્ષકને બદલે ફાઇલનું હેડર તપાસો.
readelf -h ./vendor-vpn readelf -l ./vendor-vpn | head -20 file ./vendor-vpn
પહેલો આદેશ હેડર છાપે છે, જેમાં વર્ગ અને મશીનનો સમાવેશ થાય છે. બીજો પ્રોગ્રામ હેડર દર્શાવે છે, જ્યાં ઇન્ટરપ્રીટર વિનંતી રહે છે. ત્રીજો તમને એક લીટી આપે છે જ્યારે કોષ્ટક તમારી જરૂર કરતાં વધુ હોય.
એક્ઝિક્યુટ પરવાનગી ઉમેરવી કે ડિસ્ટ્રિબ્યુશન ચેકને પેચ કરવી કંઈનું ભાષાંતર કરતું નથી. એમ્યુલેશન, જ્યાં પ્લેટફોર્મ તેને સમર્થન આપે છે, તે તેના પોતાના પ્રદર્શન અને નિર્ભરતા ખર્ચ સાથેનો ડિપ્લોયમેન્ટ નિર્ણય છે.
ઇન્સ્ટોલર ચલાવતા પહેલાં હેડર વાંચો
વિશ્વસનીય આર્ટિફેક્ટમાંથી કંઈપણ ચલાવતા પહેલાં તેની તપાસ કરો. અડધા રસ્તે નિષ્ફળ જતું ઇન્સ્ટોલર લાઇબ્રેરીઓ બદલાયેલી અને કંઈ કામ ન કરતું છોડી શકે છે, જે તમે શરૂ કરેલા આર્કાઇવ કરતાં વધુ ખરાબ પ્રારંભિક બિંદુ છે. હેડર તપાસ ફક્ત-વાંચન છે અને એ અર્થમાં ઉલટાવી શકાય તેવી છે કે સિસ્ટમ પર કંઈ બદલાતું નથી.
મશીન ક્ષેત્રની સરખામણી ચાલતી સિસ્ટમની પેકેજ આર્કિટેક્ચર સાથે કરો, બોર્ડના માર્કેટિંગ નામ સાથે નહીં. 32-બિટ યુઝરલેન્ડ ચલાવતા 64-બિટ CPU ને 32-બિટ બિલ્ડની જરૂર છે, અને એ વિગત જ નક્કી કરે છે કે કયું ડાઉનલોડ મૂળ છે. બોર્ડની ક્ષમતા મર્યાદા નથી; ઇન્સ્ટોલ કરેલું યુઝરલેન્ડ મર્યાદા છે.
dpkg --print-architecture uname -m getconf LONG_BIT
પહેલો આદેશ જે આર્કિટેક્ચર માટે સિસ્ટમ પેકેજ ઇન્સ્ટોલ કરે છે તેની જાણ કરે છે, અને તે જ મૂલ્ય મેળ ખાવું જોઈએ. બાકીના બે કર્નલ અને શબ્દના માપનું વર્ણન કરે છે, અને મલ્ટિઆર્ક ઇન્સ્ટોલમાં તેઓ યુઝરલેન્ડ સાથે અસહમત હોઈ શકે છે.
જ્યારે તે જવાબો અસહમત હોય, ત્યારે બીજું આર્કાઇવ ડાઉનલોડ કરતા પહેલાં નક્કી કરો કે વિક્રેતા કયાને સમર્થન આપે છે. અનુમાન ઇન્સ્ટોલનું ચક્ર બનાવે છે જેમાં દરેક જુદા બિંદુએ નિષ્ફળ જાય છે, અને દરેક નિષ્ફળતા નવી સમસ્યા જેવી લાગે છે.
ઇન્ટરપ્રીટર તપાસો, ફક્ત આર્કિટેક્ચર નહીં
ગતિશીલ એક્ઝિક્યુટેબલ પ્રોગ્રામ હેડરમાં જે લોડરની અપેક્ષા રાખે છે તે નોંધે છે. અલગ લોડર પાથ ધરાવતી સિસ્ટમ પર કર્નલ ફાઇલ શરૂ કરવાનો ઇનકાર કરે છે, પછી ભલે મશીન ક્ષેત્ર બરાબર મેળ ખાય. એ જ નિષ્ફળતા લોકોને ખૂટતી લાઇબ્રેરી શોધવા મોકલે છે.
ભૂલ સંદેશ કહે છે કે તમે કયા કિસ્સામાં છો, અને બંને કિસ્સાઓ ભેળવી દેવા સરળ છે. ફોર્મેટ કે આર્કિટેક્ચરનો અસ્વીકાર ખૂટતી ફાઇલ કે ઇન્ટરપ્રીટરથી અલગ છે, અને તેમાંથી ફક્ત એક જ બીજું પેકેજ ઇન્સ્ટોલ કરીને સુધરે છે.
readelf -l ./vendor-vpn | grep -A1 INTERP ls -l /lib64/ld-linux-x86-64.so.2
પહેલો આદેશ બાઈનરી જે ઇન્ટરપ્રીટર પાથ માંગે છે તે દર્શાવે છે. બીજો તપાસે છે કે એ પાથ અસ્તિત્વમાં છે કે નહીં, જે ખોટા બિલ્ડને ખૂટતા લોડરથી અલગ પાડે છે.
અવિશ્વસનીય બાઈનરી પર નિર્ભરતા-યાદી ચલાવશો નહીં, કારણ કે કેટલાક અમલીકરણો તેઓ જે ફાઇલની તપાસ કરે છે તેને ચલાવી શકે છે. તપાસ ફક્ત-વાંચન રાખો અને અસમર્થિત બિલ્ડ શરૂ કરવા લોડર સિમ્લિંક ઉમેરવાના લોભને રોકો.
તથ્યો હાથમાં રાખીને બિલ્ડ માંગો
વિક્રેતાને OS રિલીઝ, પેકેજ આર્કિટેક્ચર, વર્ગ અને મશીન મૂલ્યો અને પ્રથમ ભૂલ સંદેશ મોકલો. એ સંયોજન ઉપયોગી જવાબ મેળવે છે, જ્યારે સામાન્ય નિષ્ફળતાનો સ્ક્રીનશોટ સપોર્ટ ટેમ્પલેટ મેળવે છે.
બાઈનરીનો પ્રશ્ન રૂપરેખાંકનના પ્રશ્નથી અલગ રાખો. એક વાર સાચું બિલ્ડ શરૂ થાય, પ્રોફાઇલ, ઓળખપત્રો અને રૂટ હજી પણ તેમની પોતાની સમસ્યાઓ છે, અને પ્રોફાઇલ સંપાદનનો કોઈ જથ્થો ખોટા આર્કિટેક્ચરના બાઈનરીને ચલાવી શકશે નહીં.