Sinasabi ng installer ng VPN na 32-bit: suriin ang ELF header sa halip

Sinasabi ng isang pahina ng download na 32-bit, dumarating ang file sa Raspberry Pi, at nabibigo ang installer sa isang mensaheng walang pinangalanang kapaki-pakinabang na bahagi ng problema. Dalawang ganap na magkaibang executable file ang parehong binibilang na 32-bit sa kahulugan ng ELF, at isa lamang sa kanila ang maaaring tumakbo sa board na iyon. Ang field ng klase ay isang katotohanan, ang field ng makina ay isa pa, at ang pangalan ng file ay hindi nagsasabi sa iyo ng alinman sa dalawa nang mapagkakatiwalaan. Basahin ang header bago magpalit ng library o sumubok ng ibang mirror.

Sinasabi ng klase ang laki ng salita, sinasabi ng makina ang set ng instruksyon

Ang ELF reference ng Linux ay nagtatakda ng field ng klase at field ng makina sa header ng file, at ang dalawa ay sumasagot sa magkaibang tanong. Sinasabi ng klase kung ginagamit ng file ang 32-bit o 64-bit na anyo; sinasabi ng makina kung para sa aling set ng instruksyon ito itinayo. Ang build na x86 na 32-bit at build na ARM na 32-bit ay nagkakasundo sa una at nagkakaiba sa pangalawa. Ganyan ang isang label na nangangako ng tamang laki ng salita ay naghahatid pa rin ng code na hindi kayang i-decode ng processor. Ang pangatlong halagang sulit basahin ay ang hinihiling na interpreter, na pinangalanan ng mga header ng programa kapag may idineklara ang binary.

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

Ipinapakita ng unang command ang header, ipinapakita ng pangalawa ang mga header ng programa kapag mayroon ang file, at ang pangatlo ay naglilista ng mga shared object na kakailanganin ng loader. Itala ang klase, makina at interpreter nang magkasama, dahil ang tatlong halagang ito ang buong tanong ng compatibility sa antas na ito. Wala sa tatlo ang lumalabas sa isang pindutan ng download, kaya dapat suriin ang file sa halip na ilarawan.

Aling interpreter ang hinihiling nito sa kernel

Ang isang executable na nagdedeklara ng interpreter ay humihiling sa kernel ng isang partikular na path ng loader. Kapag wala ang loader na iyon, nabibigo ang paglulunsad kahit naroon mismo ang file na pinangalanan mo. Ito ang punto kung saan nagpapasya ang mga tao na sira ang download, samantalang ang tunay na sagot ay isang loader na hindi ibinibigay ng distribution.

Itugma ang loader sa system na talagang pinapatakbo mo: ang release ng OS, ang architecture ng user space at ang package na nagbibigay ng loader. Ang 64-bit na kernel ay makakapagpatakbo ng 32-bit na user space lamang kapag naka-install ang space na iyon at ang loader nito, kaya ang kakayahan ng processor ay hindi ang tiyak na salik. Isang maikling pagsusuri ang nagpangalan ng interpreter sa isang linya, at mas mabilis ito kaysa sa support ticket. Ang shell script ay nabibigo sa ibang paraan, dahil ang interpreter nito ay pinangalanan sa unang linya at hindi sa ELF header, at walang gastos ang pagbasa ng linyang iyon.

file --brief ./vendor-vpn

Itugma ang download sa architecture ng package

Ang mga architecture ng package ng distribution ay nagko-code ng parehong pagkakaiba sa kanilang sariling bokabularyo, at iyon ang tinutukoy ng pahayag ng suporta ng vendor. Ihambing ang halagang iniuulat ng iyong package manager sa halagang idinodokumento ng vendor, sa halip na ihambing ang marketing label sa pangalan ng file. Ang mga pares na nagdudulot ng problema ay amd64 laban sa arm64, at armhf laban sa armel, dahil ang bawat pares ay mukhang mapagpapalit sa isang listahan ng download. Ang pangalan ng file na nagtatapos sa x64 o ia32 ay naglalarawan ng target ng build, hindi ang makinang nagtatago nito.

Ang bawat hilera ay isang kaso kung saan ang laki ng salita ay mukhang tama at mali pa rin ang pag-uugali ng code, o kung saan nagsisimula ito at pagkatapos ay nabibigo nang isang antas pababa. Basahin ang column ng interpreter bilang matigas na pangangailangan at hindi bilang pahiwatig, dahil nilulutas ng kernel ang path na iyon bago tumakbo ang anumang bahagi ng iyong code. Ang emulation ay isang desisyon sa deployment na may sariling mga bunga sa performance at suporta, at hindi ito kailanman ipinahihiwatig ng isang processor na nag-aanunsyo ng mas malawak na laki ng salita.

dpkg --print-architecture

Ang ENOEXEC at ENOENT ay magkaibang pagkabigo

Ang yugto ng paglulunsad ay nag-uulat ng isa sa dalawang error, at tumuturo ang mga ito sa magkaibang problema. Ang pagbasa ng halaga ng error ay nag-uuri ng pagkabigo bago ka magpatakbo ng anupaman.

Ang ENOEXEC ay nangangahulugang hindi nakilala ang format: maling architecture, maling klase o isang bagay na hindi executable file. Ang ENOENT sa isang ELF file ay karaniwang nangangahulugang nawawala ang interpreter, kahit umiiral ang file na hiniling mo. Ang parehong ENOENT ay maaari ring mangahulugang nawawala ang interpreter ng isang script, kaya mahalaga ang unang linya ng script. Anuman ang mangyari, pinangalanan ng mensahe ang antas, at ang pagtrato sa bawat «hindi natagpuan» bilang nawawalang configuration ay nagpapadala ng pagsisiyasat sa maling direksyon. Sipiin ang halaga ng error sa ticket, dahil mas nakakayanan nito ang muling pagkukuwento kaysa sa pangungusap sa paligid.

Ano ang hindi dapat gawin kapag hindi nagsisimula ang binary

Ang pagpilit sa isang hindi maipaliwanag na binary na dumaan sa isang shell wrapper ay hindi ito pinapatakbo. Huwag magpatakbo ng dependency checker nang walang ingat sa isang file na hindi mo pinagkakatiwalaan, dahil ang pagpapatakbo nito ay maaaring magsagawa ng code mula sa binary sa ilang pagkakataon. Huwag magdagdag ng symbolic link ng loader, huwag magpalit ng library ng host at huwag kumuha ng lumang archive mula sa mirror ng third party upang malampasan ang mensahe. Bawat isa sa mga ito ay nagpapalawak ng surface ng pagbabago nang hindi hinahawakan ang hindi pagkakatugma na pinangalanan na ng header.

Kapag lumapit ka sa vendor, magpadala ng mga halaga at hindi kuwento: ang release ng OS, ang architecture ng package, ang mga string ng klase at makina, ang hinihiling na interpreter at ang unang linya ng error. Ang set na iyon ay lumulutas ng mga tanong sa suporta nang mas mabilis kaysa sa screenshot ng isang installer na nabibigo. Ang mga lumang artifact at naaalalang output ng forum ay hindi kasalukuyang support matrix, at kapag na-load ang isang native binary, ang profile, authentication at routing ay nananatiling hiwalay na gawain.