VPN-installatieprogramma zegt 32-bit: controleer in plaats daarvan de ELF-header

Een downloadpagina zegt 32-bit, het bestand belandt op een Raspberry Pi en het installatieprogramma faalt met een melding die geen bruikbaar deel van het probleem noemt. Twee heel verschillende uitvoerbare bestanden tellen beide als 32-bit in ELF-zin, en slechts één ervan kan op dat bord draaien. Het klasseveld is één feit, het machineveld een ander, en een bestandsnaam vertelt je betrouwbaar geen van beide. Lees de header voordat je een bibliotheek wijzigt of een andere spiegel probeert.

De klasse zegt de woordgrootte, de machine de instructieset

De Linux ELF-referentie definieert een klasseveld en een machineveld in de bestandsheader, en die twee beantwoorden verschillende vragen. De klasse zegt of het bestand de 32-bit- of de 64-bit-vorm gebruikt; de machine zegt voor welke instructieset het is gebouwd. Een 32-bit x86-build en een 32-bit ARM-build zijn het eens over het eerste en oneens over het tweede. Zo levert een label dat de juiste woordgrootte belooft toch code die de processor niet kan decoderen. De derde waarde die het lezen waard is, is de gevraagde interpreter, die de programmaheaders noemen wanneer het binaire bestand er een aangeeft.

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

De eerste opdracht drukt de header af, de tweede drukt programmaheaders af wanneer het bestand die heeft, en de derde somt de gedeelde objecten op die de loader nodig zal hebben. Noteer klasse, machine en interpreter samen, want die drie waarden vormen de hele compatibiliteitsvraag op dit niveau. Geen van de drie staat op een downloadknop, daarom moet het bestand worden onderzocht in plaats van beschreven.

Welke interpreter het de kernel vraagt

Een uitvoerbaar bestand dat een interpreter aangeeft, vraagt de kernel om één specifiek loaderpad. Ontbreekt die loader, dan mislukt het starten ook al staat het bestand dat je noemde er precies. Dat is het punt waarop mensen concluderen dat de download beschadigd is, terwijl het echte antwoord een loader is die de distributie niet levert.

Stem de loader af op het systeem dat je werkelijk draait: de OS-versie, de architectuur van de gebruikersruimte en het pakket dat de loader levert. Een 64-bits kernel kan een 32-bits gebruikersruimte alleen draaien wanneer die ruimte en zijn loader zijn geïnstalleerd, dus de mogelijkheden van de processor zijn niet de beslissende factor. Eén korte controle noemt de interpreter op één regel, en dat kost minder tijd dan een supportticket. Een shellscript faalt weer anders, omdat de interpreter op de eerste regel staat en niet in een ELF-header, en die regel lezen kost niets.

file --brief ./vendor-vpn

Stem de download af op de pakketarchitectuur

Pakketarchitecturen van distributies coderen dezelfde tweedeling in hun eigen vocabulaire, en dat vocabulaire is waar een supportverklaring van een leverancier naar verwijst. Vergelijk de waarde die je pakketbeheerder meldt met de waarde die de leverancier documenteert, in plaats van een marketinglabel met een bestandsnaam te vergelijken. De paren die problemen geven zijn amd64 tegenover arm64, en armhf tegenover armel, omdat elk paar in een downloadlijst uitwisselbaar lijkt. Een bestandsnaam die eindigt op x64 of ia32 beschrijft een builddoel, niet de machine die hem bevat.

Elke rij is een geval waarin de woordgrootte juist lijkt en de code zich toch verkeerd gedraagt, of waarin hij start en daarna één laag dieper faalt. Lees de interpreterkolom als een harde eis en niet als een aanwijzing, omdat de kernel dat pad oplost voordat enige code van jou draait. Emulatie is een uitroldecisie met eigen gevolgen voor prestaties en ondersteuning, en zij wordt nooit geïmpliceerd door een processor die met een bredere woordgrootte adverteert.

dpkg --print-architecture

ENOEXEC en ENOENT zijn verschillende fouten

De startfase meldt een van twee fouten, en ze wijzen op verschillende problemen. Het lezen van de foutwaarde classificeert het falen voordat je iets anders draait.

ENOEXEC betekent dat het formaat niet is herkend: verkeerde architectuur, verkeerde klasse of iets dat helemaal geen uitvoerbaar bestand is. ENOENT bij een ELF-bestand betekent meestal dat de interpreter ontbreekt, ook al bestaat het bestand dat je opvroeg. Dezelfde ENOENT kan ook betekenen dat de interpreter van een script ontbreekt, daarom doet de eerste regel van een script ertoe. Hoe dan ook noemt de melding de laag, en elk „niet gevonden“ als ontbrekende configuratie behandelen stuurt het onderzoek de verkeerde kant op. Citeer de foutwaarde in het ticket, want die overleeft het navertellen beter dan de zin eromheen.

Wat je niet moet doen als het binaire bestand niet start

Een onverklaard binair bestand door een shell-wrapper heen duwen laat het niet draaien. Draai een afhankelijkheidscontrole niet achteloos op een bestand dat je niet vertrouwt, want het draaien ervan kan onder sommige omstandigheden code uit het binaire bestand uitvoeren. Voeg geen loader-symbolische koppelingen toe, wissel geen hostbibliotheken uit en haal geen oud archief van een derdepartijspiegel om de melding te omzeilen. Elk daarvan verbreedt het wijzigingsoppervlak zonder de mismatch aan te raken die de header al noemde.

Wanneer je de leverancier benadert, stuur waarden in plaats van een verhaal: de OS-versie, de pakketarchitectuur, de klasse- en machinestrings, de gevraagde interpreter en de eerste foutregel. Die set lost supportvragen sneller op dan een schermafbeelding van een falend installatieprogramma. Oude artefacten en onthouden forumpostings zijn geen actuele supportmatrix, en zodra een native binair bestand laadt, blijven profiel, verificatie en routering apart werk.