Nabuo ba ang iyong VPN binary para sa CPU na ito? Basahin ang ELF header

Parehong 32-bit ang dalawang file at isa lamang sa kanila ang tumatakbo sa iyong board. Ang ELF32 build para sa Intel at ELF32 build para sa ARM ay nagkakasundo sa class field at hindi nagkakasundo sa lahat ng mahalaga. Ang page ng download na nag-aalok ng 32-bit na opsyon ay halos wala pang sinabi sa iyo hanggang mabasa mo ang header ng file na aktwal mong na-download. Ang pagpapalit ng pangalan nito ay hindi nagbabago ng kahit isang instruction.

Magkaibang tanong ang sinasagot ng class at machine

Sinasabi ng class field kung 32-bit o 64-bit na istruktura ang ginagamit ng file. Pinapangalanan ng machine field ang instruction set kung saan na-compile ang file. Ang pagbasa lamang ng una ay kung paano napupunta ang isang x86 build sa isang ARM board na may filename na mukhang lubos na kapani-paniwala. Galing sa iisang command ang dalawang value, kaya napakadaling laktawan ang isa.

Ganoon din ang kalituhan sa mga 64-bit na label, kung saan ang aarch64 at x86-64 ay nagbabahagi ng word size at wala ni isang instruction. Ang page ng vendor na naglilista ng isang 64-bit na download ay naglalarawan ng sarili nitong build, hindi ang iyong machine. Suriin ang header ng file sa halip na ang column heading sa page.

readelf -h ./vendor-vpn
readelf -l ./vendor-vpn | head -20
file ./vendor-vpn

Ang unang command ay nagpi-print ng header, kasama ang class at machine. Ang pangalawa ay nagpapakita ng program headers, kung saan naroon ang interpreter request. Ang pangatlo ay nagbibigay sa iyo ng isang linya kapag ang table ay higit pa sa kailangan mo.

Ang pagdaragdag ng execute permission o pag-patch ng distribution check ay walang naisasalin. Ang emulation, kung saan sinusuportahan ito ng platform, ay isang desisyon sa deployment na may sariling gastos sa performance at dependencies.

Basahin ang header bago patakbuhin ang installer

Suriin ang isang pinagkakatiwalaang artifact bago mag-execute ng kahit ano mula rito. Ang installer na nabigo sa kalagitnaan ay maaaring mag-iwan ng mga library na napalitan at walang gumagana, na mas masamang panimulang punto kaysa sa archive na sinimulan mo. Ang pagsusuri ng header ay read-only at nababalik sa diwa na walang nagbabago sa system.

Ihambing ang machine field sa package architecture ng tumatakbong system, hindi sa marketing name ng board. Ang 64-bit CPU na nagpapatakbo ng 32-bit userland ay nangangailangan ng 32-bit build, at ang detalyeng iyon ang nagpapasya kung aling download ang native. Ang kakayahan ng board ay hindi ang limitasyon; ang naka-install na userland ang limitasyon.

dpkg --print-architecture
uname -m
getconf LONG_BIT

Ang unang command ay nag-uulat ng architecture kung saan nag-i-install ng packages ang system, at iyon ang value na dapat tumugma. Ang dalawa pa ay naglalarawan ng kernel at word size, at maaaring hindi tumugma sa userland sa isang multiarch na install.

Kapag hindi nagtugma ang mga sagot na iyon, magpasya kung alin ang sinusuportahan ng vendor bago mag-download ng ibang archive. Ang paghula ay gumagawa ng loop ng mga install na bawat isa ay nabigo sa ibang punto, at ang bawat kabiguan ay mukhang bagong problema.

Suriin ang interpreter, hindi lamang ang architecture

Ang isang dynamic executable ay nagtatala ng loader na inaasahan nito sa isang program header. Sa isang system na may ibang loader path, tumatanggi ang kernel na simulan ang file kahit na eksaktong tumutugma ang machine field. Iyon ang kabiguang nagpapadala ng mga tao na maghanap ng mga nawawalang library.

Sinasabi ng error message kung aling kaso ka naroon, at ang dalawang kaso ay madaling mapagkamalan. Ang pagtanggi sa format o architecture ay naiiba sa nawawalang file o interpreter, at isa lamang sa kanila ang naaayos sa pamamagitan ng pag-install ng ibang package.

readelf -l ./vendor-vpn | grep -A1 INTERP
ls -l /lib64/ld-linux-x86-64.so.2

Ang unang command ay nagpapakita ng interpreter path na hinihiling ng binary. Ang pangalawa ay sumusuri kung umiiral ang path na iyon, na naghihiwalay ng maling build sa nawawalang loader.

Huwag patakbuhin ang dependency lister laban sa isang hindi pinagkakatiwalaang binary, dahil ang ilang implementation ay maaaring mag-execute ng file na sinusuri nila. Panatilihing read-only ang pagsusuri at labanan ang tuksong magdagdag ng loader symlinks para mapatakbo ang isang hindi suportadong build.

Humingi ng build na hawak ang mga katotohanan

Ipadala sa vendor ang OS release, package architecture, class at machine values at ang unang error message. Ang kombinasyong iyon ay nakakakuha ng kapaki-pakinabang na sagot, habang ang screenshot ng isang pangkalahatang kabiguan ay nakakakuha ng support template.

Panatilihing hiwalay ang tanong sa binary mula sa tanong sa configuration. Kapag nagsimula ang tamang build, ang mga profile, credentials at ruta ay problema pa rin nila, at walang dami ng pag-edit ng profile ang makakapagpatakbo ng binary na mali ang architecture.