VPN ઇન્સ્ટોલર 32-બિટ કહે છે: તેના બદલે ELF હેડર તપાસો

એક ડાઉનલોડ પેજ 32-બિટ કહે છે, ફાઇલ Raspberry Pi પર ઉતરે છે, અને ઇન્સ્ટોલર એવી સંદેશ સાથે નિષ્ફળ જાય છે જે સમસ્યાના કોઈ ઉપયોગી ભાગનું નામ લેતું નથી. બે સંપૂર્ણપણે અલગ એક્ઝિક્યુટેબલ ELF અર્થમાં બંને 32-બિટ ગણાય છે, અને તેમાંથી ફક્ત એક જ તે બોર્ડ પર ચાલી શકે છે. વર્ગ ક્ષેત્ર એક હકીકત છે, મશીન ક્ષેત્ર બીજી, અને ફાઇલનું નામ તમને બંનેમાંથી એક પણ વિશ્વસનીય રીતે કહેતું નથી. લાઇબ્રેરી બદલતા કે બીજો મિરર અજમાવતા પહેલા હેડર વાંચો.

વર્ગ શબ્દનું કદ કહે છે, મશીન સૂચના સમૂહ કહે છે

Linux ELF સંદર્ભ ફાઇલ હેડરમાં વર્ગ ક્ષેત્ર અને મશીન ક્ષેત્ર વ્યાખ્યાયિત કરે છે, અને બંને અલગ પ્રશ્નોના જવાબ આપે છે. વર્ગ કહે છે કે ફાઇલ 32-બિટ કે 64-બિટ રૂપ વાપરે છે; મશીન કહે છે કે તે કયા સૂચના સમૂહ માટે બનાવાઈ છે. 32-બિટ x86 બિલ્ડ અને 32-બિટ ARM બિલ્ડ પ્રથમમાં સહમત અને બીજામાં ભિન્ન છે. આ રીતે યોગ્ય શબ્દ કદનું વચન આપતું લેબલ પણ એવો કોડ આપે છે જે પ્રોસેસર ડિકોડ કરી શકતું નથી. વાંચવા લાયક ત્રીજું મૂલ્ય માંગેલો ઇન્ટરપ્રીટર છે, જેનું નામ પ્રોગ્રામ હેડરો ત્યારે લે છે જ્યારે બાઇનરી એક જાહેર કરે.

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 પર અંત થતું ફાઇલનું નામ બિલ્ડ લક્ષ્યનું વર્ણન કરે છે, તેને રાખતા મશીનનું નહીં.

દરેક પંક્તિ એવો કિસ્સો છે જ્યાં શબ્દનું કદ યોગ્ય લાગે છે અને કોડ તોપણ ખોટું વર્તે છે, અથવા જ્યાં તે શરૂ થઈને પછી એક સ્તર નીચે નિષ્ફળ જાય છે. ઇન્ટરપ્રીટર કૉલમને સંકેત નહીં પણ કઠોર જરૂરિયાત તરીકે વાંચો, કારણ કે કર્નલ તમારા કોઈ પણ કોડ ચાલે તે પહેલાં તે પથ ઉકેલે છે. ઇમ્યુલેશન એ પોતાના પ્રદર્શન અને સપોર્ટ પરિણામો સાથેનો ડિપ્લોયમેન્ટ નિર્ણય છે, અને પહોળા શબ્દ કદની જાહેરાત કરતું પ્રોસેસર ક્યારેય તેનો સૂચક બનતું નથી.

dpkg --print-architecture

ENOEXEC અને ENOENT જુદી જુદી નિષ્ફળતાઓ છે

લોન્ચ તબક્કો બે પૈકી એક ભૂલ જણાવે છે, અને તે જુદી જુદી સમસ્યાઓ તરફ ઇશારો કરે છે. ભૂલનું મૂલ્ય વાંચવું બીજું કંઈ ચલાવતા પહેલા નિષ્ફળતાનું વર્ગીકરણ કરે છે.

ENOEXEC એટલે ફોર્મેટ ઓળખાયું નહીં: ખોટી આર્કિટેક્ચર, ખોટો વર્ગ, અથવા એવું કંઈ જે બિલકુલ એક્ઝિક્યુટેબલ નથી. ELF ફાઇલ પર ENOENT સામાન્ય રીતે એટલે ઇન્ટરપ્રીટર ગેરહાજર છે, છતાં તમે માંગેલી ફાઇલ અસ્તિત્વમાં છે. એ જ ENOENT એ પણ અર્થ આપી શકે કે સ્ક્રિપ્ટનું ઇન્ટરપ્રીટર ગેરહાજર છે, તેથી સ્ક્રિપ્ટની પ્રથમ લાઇન મહત્ત્વની છે. કોઈ પણ રીતે સંદેશ સ્તરનું નામ લે છે, અને દરેક “મળ્યું નથી”ને ખૂટતી રૂપરેખા ગણવું તપાસને ખોટી દિશામાં મોકલે છે. ટિકિટમાં ભૂલનું મૂલ્ય ટાંકો, કારણ કે તે આસપાસના વાક્ય કરતાં ફરી કહેવામાં વધુ ટકે છે.

બાઇનરી શરૂ ન થાય ત્યારે શું ન કરવું

અસ્પષ્ટ બાઇનરીને શેલ આવરણમાંથી ફરજિયાત પસાર કરવાથી તે ચાલતી નથી. જે ફાઇલ પર ભરોસો નથી તેના પર નિર્ભરતા ચકાસણી બેદરકારીથી ન ચલાવો, કારણ કે તેને ચલાવવાથી કેટલાક સંજોગોમાં બાઇનરીમાંથી કોડ ચાલી શકે છે. લોડર સિમ્લિંક ઉમેરશો નહીં, હોસ્ટ લાઇબ્રેરી બદલશો નહીં અને સંદેશ ટાળવા તૃતીય પક્ષના મિરરમાંથી જૂનું આર્કાઇવ ન લાવો. તેમાંથી દરેક વસ્તુ હેડરે પહેલેથી નામ આપેલી અસંગતિને સ્પર્શ્યા વિના ફેરફારનો વ્યાપ વધારે છે.

જ્યારે વેન્ડરનો સંપર્ક કરો, ત્યારે વાર્તા નહીં પણ મૂલ્યો મોકલો: OS આવૃત્તિ, પેકેજ આર્કિટેક્ચર, વર્ગ અને મશીન સ્ટ્રિંગ, માંગેલો ઇન્ટરપ્રીટર અને પ્રથમ ભૂલ લાઇન. તે સમૂહ સપોર્ટ પ્રશ્નોને નિષ્ફળ ઇન્સ્ટોલરના સ્ક્રીનશૉટ કરતાં ઝડપથી ઉકેલે છે. જૂના આર્ટિફેક્ટ અને યાદ રહેલા ફોરમ આઉટપુટ વર્તમાન સપોર્ટ મેટ્રિક્સ નથી, અને નેટિવ બાઇનરી લોડ થયા પછી પ્રોફાઇલ, પ્રમાણીકરણ અને રૂટિંગ અલગ કામ રહે છે.