Är din VPN-binärfil byggd för den här processorn? Läs ELF-huvudet

Båda filerna är 32-bitars och bara en av dem körs på ditt kort. En ELF32-bygge för Intel och en ELF32-bygge för ARM är överens om klassfältet och oense om allt som spelar roll. En nedladdningssida som erbjuder ett 32-bitarsalternativ har nästan inte sagt dig något förrän du läser huvudet på filen du faktiskt laddade ner. Att byta namn på den ändrar inte en enda instruktion.

Klass och maskin svarar på olika frågor

Klassfältet säger om filen använder 32-bitars eller 64-bitars strukturer. Maskinfältet anger den instruktionsuppsättning som filen kompilerades för. Att bara läsa det första är hur en x86-bygge hamnar på ett ARM-kort med ett filnamn som ser helt trovärdigt ut. Båda värdena kommer från samma kommando, därför är det så lätt att hoppa över ett.

Samma förvirring gäller 64-bitarsetiketter, där aarch64 och x86-64 delar en ordstorlek och inga instruktioner. En leverantörssida som listar en enda 64-bitarsnedladdning beskriver sin egen bygge, inte din maskin. Kontrollera filens huvud i stället för kolumnrubriken på sidan.

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

Det första kommandot skriver ut huvudet, inklusive klass och maskin. Det andra visar programhuvuden, där en tolkförfrågan finns. Det tredje ger dig en rad när en tabell är mer än du behöver.

Att lägga till körbehörighet eller patcha en distributionskontroll översätter ingenting. Emulering, där plattformen stöder det, är ett driftsättningsbeslut med sin egen kostnad för prestanda och beroenden.

Läs huvudet innan du kör installationsprogrammet

Granska en betrodd artefakt innan du kör något från den. Ett installationsprogram som misslyckas halvvägs kan lämna ersatta bibliotek och ingenting som fungerar, vilket är en sämre utgångspunkt än arkivet du började med. Huvudgranskning är skrivskyddad och reversibel i den meningen att ingenting på systemet ändras.

Jämför maskinfältet med paketarkitekturen hos det körande systemet, inte med kortets marknadsföringsnamn. En 64-bitarsprocessor som kör ett 32-bitars användarland behöver 32-bitarsbygget, och den detaljen avgör vilken nedladdning som är inhemsk. Kortets förmåga är inte begränsningen; det installerade användarlandet är det.

dpkg --print-architecture
uname -m
getconf LONG_BIT

Det första kommandot rapporterar den arkitektur systemet installerar paket för, och det är värdet som måste stämma. De andra två beskriver kärnan och ordstorleken, och de kan skilja sig från användarlandet vid en multiarkitekturinstallation.

När dessa svar skiljer sig måste du avgöra vilken leverantören stöder innan du laddar ner ett annat arkiv. Gissningar skapar en loop av installationer som var och en misslyckas på olika punkter, och varje fel ser ut som ett nytt problem.

Kontrollera tolken, inte bara arkitekturen

En dynamisk körbar fil registrerar den laddare den förväntar sig i ett programhuvud. På ett system med en annan laddarsökväg vägrar kärnan starta filen även om maskinfältet stämmer exakt. Det är det fel som skickar folk att leta efter saknade bibliotek.

Felmeddelandet berättar vilket fall du är i, och de två fallen är lätta att förväxla. En avvisning av format eller arkitektur skiljer sig från en saknad fil eller tolk, och bara ett av dem åtgärdas genom att installera ett annat paket.

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

Det första kommandot visar tolksökvägen som binärfilen begär. Det andra kontrollerar om den sökvägen finns, vilket skiljer en felaktig bygge från en saknad laddare.

Kör inte en beroendelista mot en icke betrodd binärfil, eftersom vissa implementationer kan köra filen de granskar. Håll granskningen skrivskyddad och stå emot frestelsen att lägga till laddarsymlinkar för att få en icke stödd bygge att starta.

Be om en bygge med fakta i handen

Skicka OS-versionen, paketarkitekturen, klass- och maskinvärdena och det första felmeddelandet till leverantören. Den kombinationen ger ett användbart svar, medan en skärmbild av ett allmänt fel ger en supportmall.

Håll binärfrågan åtskild från konfigurationsfrågan. När rätt bygge startar är profiler, inloggningsuppgifter och rutter fortfarande deras egna problem, och ingen mängd profilredigering får en binärfil med fel arkitektur att köras.