Is je VPN-binary gebouwd voor deze cpu? Lees de ELF-header

Beide bestanden zijn 32-bits en slechts één ervan draait op je board. Een ELF32-build voor Intel en een ELF32-build voor ARM zijn het eens over het klasseveld en oneens over alles wat ertoe doet. Een downloadpagina met een 32-bits optie heeft je bijna niets verteld tot je de header leest van het bestand dat je echt hebt gedownload. De naam ervan wijzigen verandert geen enkele instructie.

Klasse en machine beantwoorden verschillende vragen

Het klasseveld zegt of het bestand 32-bits of 64-bits structuren gebruikt. Het machineveld noemt de instructieset waarvoor het bestand is gecompileerd. Alleen het eerste lezen is hoe een x86-build op een ARM-board belandt met een bestandsnaam die volkomen aannemelijk lijkt. Beide waarden komen uit dezelfde opdracht, daarom is het zo makkelijk om er één over te slaan.

Dezelfde verwarring geldt voor 64-bits labels, waar aarch64 en x86-64 een woordgrootte delen en helemaal geen instructies. Een leverancierspagina die één 64-bits download noemt, beschrijft de eigen build, niet jouw machine. Controleer de header van het bestand in plaats van de kolomkop op de pagina.

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

De eerste opdracht print de header, inclusief klasse en machine. De tweede toont programmaheaders, waar een interpreterverzoek staat. De derde geeft je één regel wanneer een tabel meer is dan je nodig hebt.

Uitvoerrechten toevoegen of een distributiecontrole patchen vertaalt niets. Emulatie is, waar het platform die ondersteunt, een implementatiebeslissing met eigen prestatie- en afhankelijkheidskosten.

Lees de header voordat je het installatieprogramma uitvoert

Inspecteer een vertrouwd artefact voordat je er iets uit uitvoert. Een installatieprogramma dat halverwege mislukt, kan vervangen bibliotheken en niets werkends achterlaten, wat een slechter startpunt is dan het archief waarmee je begon. Headerinspectie is alleen-lezen en omkeerbaar in de zin dat er niets aan het systeem verandert.

Vergelijk het machineveld met de pakketarchitectuur van het draaiende systeem, niet met de marketingnaam van het board. Een 64-bits cpu die een 32-bits userland draait, heeft de 32-bits build nodig, en dat detail bepaalt welke download native is. De capaciteit van het board is niet de beperking; het geïnstalleerde userland is dat.

dpkg --print-architecture
uname -m
getconf LONG_BIT

De eerste opdracht meldt de architectuur waarvoor het systeem pakketten installeert, en dat is de waarde die moet kloppen. De andere twee beschrijven de kernel en de woordgrootte, en die kunnen afwijken van het userland bij een multiarch-installatie.

Wanneer die antwoorden verschillen, beslis dan welke de leverancier ondersteunt voordat je nog een archief downloadt. Gissen levert een lus van installaties op die elk op een ander punt mislukken, en elke mislukking lijkt een nieuw probleem.

Controleer de interpreter, niet alleen de architectuur

Een dynamisch uitvoerbaar bestand legt de loader die het verwacht vast in een programmaheader. Op een systeem met een ander loaderpad weigert de kernel het bestand te starten, zelfs als het machineveld exact klopt. Dat is de mislukking die mensen naar ontbrekende bibliotheken laat zoeken.

De foutmelding vertelt je in welk geval je zit, en de twee gevallen zijn makkelijk te verwarren. Een afwijzing van formaat of architectuur verschilt van een ontbrekend bestand of interpreter, en slechts één ervan wordt verholpen door een ander pakket te installeren.

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

De eerste opdracht toont het interpreterpad dat de binary aanvraagt. De tweede controleert of dat pad bestaat, wat een verkeerde build scheidt van een ontbrekende loader.

Voer geen afhankelijkheidslijst uit op een niet-vertrouwde binary, want sommige implementaties kunnen het bestand uitvoeren dat ze inspecteren. Houd de inspectie alleen-lezen en weersta de verleiding om loader-symlinks toe te voegen om een niet-ondersteunde build te laten starten.

Vraag om een build met de feiten in de hand

Stuur de leverancier de OS-versie, de pakketarchitectuur, de klasse- en machinewaarden en de eerste foutmelding. Die combinatie levert een bruikbaar antwoord op, terwijl een screenshot van een algemene fout een supporttemplate oplevert.

Houd de binary-vraag gescheiden van de configuratievraag. Zodra de juiste build start, zijn profielen, inloggegevens en routes nog steeds hun eigen problemen, en geen enkele profielbewerking laat een binary met de verkeerde architectuur draaien.