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 vs arm64, armhf vs armel എന്നിവയാണ്, കാരണം ഓരോ ജോഡിയും ഡൗൺലോഡ് പട്ടികയിൽ പരസ്പരം മാറ്റാവുന്നതായി തോന്നുന്നു. x64 അല്ലെങ്കിൽ ia32 ൽ അവസാനിക്കുന്ന ഫയൽനാമം ഒരു build ലക്ഷ്യത്തെ വിവരിക്കുന്നു, അത് സൂക്ഷിക്കുന്ന മെഷീനെയല്ല.

ഓരോ വരിയും വാക്കിന്റെ വലുപ്പം ശരിയായി തോന്നുന്നതും എന്നിട്ടും കോഡ് തെറ്റായി പെരുമാറുന്നതുമായ സംഭവമാണ്, അല്ലെങ്കിൽ അത് ആരംഭിച്ച് പിന്നീട് ഒരു പാളി താഴെ പരാജയപ്പെടുന്ന സംഭവം. ഇന്റർപ്രിറ്റർ കോളം സൂചനയല്ല, കർശന ആവശ്യകതയായി വായിക്കുക, കാരണം നിങ്ങളുടെ കോഡിന്റെ ഏതെങ്കിലും ഭാഗം പ്രവർത്തിക്കുന്നതിന് മുൻപ് കേർണൽ ആ പാത പരിഹരിക്കുന്നു. എമുലേഷൻ സ്വന്തം പ്രകടന-സപ്പോർട്ട് പരിണാമങ്ങളുള്ള വിന്യാസ തീരുമാനമാണ്, കൂടുതൽ വീതിയുള്ള വാക്കിന്റെ വലുപ്പം പരസ്യപ്പെടുത്തുന്ന പ്രോസസർ അത് ഒരിക്കലും സൂചിപ്പിക്കുന്നില്ല.

dpkg --print-architecture

ENOEXEC-ഉം ENOENT-ഉം വ്യത്യസ്ത പരാജയങ്ങളാണ്

പ്രാരംഭ ഘട്ടം രണ്ട് പിശകുകളിൽ ഒന്ന് റിപ്പോർട്ട് ചെയ്യുന്നു, അവ വ്യത്യസ്ത പ്രശ്നങ്ങളിലേക്ക് വിരൽ ചൂണ്ടുന്നു. പിശകിന്റെ മൂല്യം വായിക്കുന്നത് മറ്റെന്തെങ്കിലും പ്രവർത്തിപ്പിക്കുന്നതിന് മുൻപ് പരാജയത്തെ വർഗ്ഗീകരിക്കുന്നു.

ENOEXEC അർത്ഥമാക്കുന്നത് ഫോർമാറ്റ് തിരിച്ചറിഞ്ഞില്ല എന്നാണ്: തെറ്റായ ആർക്കിടെക്ചർ, തെറ്റായ ക്ലാസ്, അല്ലെങ്കിൽ എക്സിക്യൂട്ടബിൾ അല്ലാത്ത എന്തോ ഒന്ന്. ELF ഫയലിൽ ENOENT സാധാരണയായി ഇന്റർപ്രിറ്റർ ഇല്ല എന്നാണ് അർത്ഥം, നിങ്ങൾ ആവശ്യപ്പെട്ട ഫയൽ ഉണ്ടായിരുന്നിട്ടും. അതേ ENOENT ഒരു സ്ക്രിപ്റ്റിന്റെ ഇന്റർപ്രിറ്റർ ഇല്ല എന്നും അർത്ഥമാക്കാം, അതിനാൽ സ്ക്രിപ്റ്റിന്റെ ആദ്യ വരി പ്രധാനമാണ്. ഏതായാലും സന്ദേശം പാളിയെ പേരിടുന്നു, ഓരോ “കണ്ടെത്തിയില്ല” എന്നതിനെയും കാണാത്ത കോൺഫിഗറേഷനായി കണക്കാക്കുന്നത് അന്വേഷണത്തെ തെറ്റായ ദിശയിലേക്ക് അയക്കുന്നു. ടിക്കറ്റിൽ പിശകിന്റെ മൂല്യം ഉദ്ധരിക്കുക, ചുറ്റുമുള്ള വാക്യത്തെക്കാൾ വീണ്ടും പറയുന്നതിനെ അത് നന്നായി അതിജീവിക്കുന്നു.

ബൈനറി ആരംഭിക്കാത്തപ്പോൾ എന്ത് ചെയ്യരുത്

വിശദീകരിക്കപ്പെടാത്ത ബൈനറിയെ ഷെൽ ആവരണത്തിലൂടെ നിർബന്ധിച്ച് കടത്തുന്നത് അതിനെ പ്രവർത്തിപ്പിക്കുന്നില്ല. നിങ്ങൾ വിശ്വസിക്കാത്ത ഫയലിൽ ഡിപ്പൻഡൻസി പരിശോധിനി അശ്രദ്ധമായി പ്രവർത്തിപ്പിക്കരുത്, കാരണം അത് പ്രവർത്തിപ്പിക്കുന്നത് ചില സാഹചര്യങ്ങളിൽ ബൈനറിയിൽ നിന്ന് കോഡ് പ്രവർത്തിപ്പിച്ചേക്കാം. ലോഡർ സിംബോളിക് ലിങ്കുകൾ ചേർക്കരുത്, ഹോസ്റ്റ് ലൈബ്രറികൾ മാറ്റരുത്, സന്ദേശം ഒഴിവാക്കാൻ മൂന്നാം കക്ഷി മിററിൽ നിന്ന് പഴയ ആർക്കൈവ് എടുക്കരുത്. ഇവയോരോന്നും ഹെഡർ ഇതിനകം പേരിട്ട പൊരുത്തക്കേട് സ്പർശിക്കാതെ മാറ്റത്തിന്റെ വ്യാപ്തി വികസിപ്പിക്കുന്നു.

വിൽപ്പനക്കാരനെ സമീപിക്കുമ്പോൾ കഥയല്ല, മൂല്യങ്ങൾ അയക്കുക: OS പതിപ്പ്, പാക്കേജ് ആർക്കിടെക്ചർ, ക്ലാസ്, മെഷീൻ സ്ട്രിംഗുകൾ, ആവശ്യപ്പെട്ട ഇന്റർപ്രിറ്റർ, ആദ്യ പിശക് വരി. ആ കൂട്ടം സപ്പോർട്ട് ചോദ്യങ്ങൾ പരാജയപ്പെടുന്ന ഇൻസ്റ്റാളറിന്റെ സ്ക്രീൻഷോട്ടിനെക്കാൾ വേഗത്തിൽ പരിഹരിക്കുന്നു. പഴയ ആർട്ടിഫാക്റ്റുകളും ഓർമ്മയിലുള്ള ഫോറം ഔട്ട്പുട്ടുകളും നിലവിലെ സപ്പോർട്ട് മാട്രിക്സല്ല, നേറ്റീവ് ബൈനറി ലോഡ് ചെയ്തശേഷം പ്രൊഫൈൽ, ആധികാരികത, റൂട്ടിംഗ് എന്നിവ വേറിട്ട ജോലിയായി തുടരുന്നു.