Er VPN-binærfilen din bygget for denne prosessoren? Les ELF-hodet
ELF-klasse og -maskin er forskjellige felt, og tolken er et tredje. Les alle tre før du installerer en VPN-klient på en Pi eller et annet kort.
Begge filene er 32-bit, og bare én av dem kjører på kortet ditt. En ELF32-bygg for Intel og en ELF32-bygg for ARM er enige om klassefeltet og uenige om alt som betyr noe. En nedlastingsside som tilbyr et 32-bit-alternativ har nesten ikke fortalt deg noe før du leser hodet på filen du faktisk lastet ned. Å gi den nytt navn endrer ikke én eneste instruksjon.
Klasse og maskin svarer på forskjellige spørsmål
Klassefeltet sier om filen bruker 32-bit- eller 64-bit-strukturer. Maskinfeltet navngir instruksjonssettet filen ble kompilert for. Å lese bare det første er måten en x86-bygg havner på et ARM-kort med et filnavn som ser helt troverdig ut. Begge verdiene kommer fra samme kommando, derfor er det så lett å hoppe over én.
Den samme forvirringen gjelder 64-bit-etiketter, der aarch64 og x86-64 deler en ordstørrelse og ingen instruksjoner. En leverandørside som lister opp én 64-bit-nedlasting beskriver sin egen bygg, ikke maskinen din. Sjekk hodet på filen i stedet for kolonneoverskriften på siden.
readelf -h ./vendor-vpn readelf -l ./vendor-vpn | head -20 file ./vendor-vpn
Den første kommandoen skriver ut hodet, inkludert klasse og maskin. Den andre viser programhoder, der en tolkeforespørsel ligger. Den tredje gir deg én linje når en tabell er mer enn du trenger.
Å legge til kjøretillatelse eller å patche en distribusjonssjekk oversetter ingenting. Emulering, der plattformen støtter det, er en utrullingsbeslutning med sin egen kostnad for ytelse og avhengigheter.
Les hodet før du kjører installasjonsprogrammet
Undersøk et klarert artefakt før du utfører noe fra det. Et installasjonsprogram som feiler halvveis kan etterlate erstattede biblioteker og ingenting som virker, noe som er et dårligere utgangspunkt enn arkivet du begynte med. Header-undersøkelse er skrivebeskyttet og reversibel i den forstand at ingenting på systemet endres.
Sammenlign maskinfeltet med pakkearkitekturen til det kjørende systemet, ikke med markedsføringsnavnet til kortet. En 64-bit-CPU som kjører et 32-bit-brukerland trenger 32-bit-byggen, og den detaljen avgjør hvilken nedlasting som er nativ. Kortets evne er ikke begrensningen; det installerte brukerlandet er.
dpkg --print-architecture uname -m getconf LONG_BIT
Den første kommandoen rapporterer arkitekturen systemet installerer pakker for, og det er verdien som må stemme. De to andre beskriver kjernen og ordstørrelsen, og de kan være uenige med brukerlandet ved en multiarch-installasjon.
Når disse svarene er uenige, må du bestemme hvilken leverandøren støtter før du laster ned et nytt arkiv. Gjetting skaper en løkke av installasjoner som hver feiler på et forskjellig punkt, og hver feil ser ut som et nytt problem.
Sjekk tolken, ikke bare arkitekturen
En dynamisk kjørbar fil registrerer lasteren den forventer i et programhode. På et system med en annen lasterbane nekter kjernen å starte filen selv om maskinfeltet stemmer nøyaktig. Det er feilen som sender folk på jakt etter manglende biblioteker.
Feilmeldingen forteller deg hvilket tilfelle du er i, og de to tilfellene er lette å forveksle. En avvisning av format eller arkitektur er forskjellig fra en manglende fil eller tolk, og bare ett av dem løses ved å installere en annen pakke.
readelf -l ./vendor-vpn | grep -A1 INTERP ls -l /lib64/ld-linux-x86-64.so.2
Den første kommandoen viser tolkeløypa den binære filen ber om. Den andre sjekker om den løypa finnes, noe som skiller en feil bygg fra en manglende laster.
Ikke kjør en avhengighetslister mot en ikke-klarert binærfil, fordi noen implementasjoner kan kjøre filen de undersøker. Hold undersøkelsen skrivebeskyttet, og motstå fristelsen til å legge til laster-symlenker for å få en ikke-støttet bygg til å starte.
Be om en bygg med fakta i hånden
Send leverandøren OS-versjonen, pakkearkitekturen, klasse- og maskinverdiene og den første feilmeldingen. Den kombinasjonen gir et nyttig svar, mens et skjermbilde av en generisk feil gir en støttemal.
Hold det binære spørsmålet atskilt fra konfigurasjonsspørsmålet. Når den riktige byggen starter, er profiler, påloggingsinformasjon og ruter fortsatt deres egne problemer, og ingen mengde profilredigering får en binærfil med feil arkitektur til å kjøre.