VPN-installeerder sê 32-bis: ondersoek eerder die ELF-kop

’n Aflaai-bladsy sê 32-bis, die lêer beland op ’n Raspberry Pi, en die installeerder faal met ’n boodskap wat geen nuttige deel van die probleem noem nie. Twee heeltemal verskillende uitvoerbare lêers tel albei as 32-bis in die ELF-sin, en net een van hulle kan op daardie bord loop. Die klasveld is een feit, die masjienveld is ’n ander, en ’n lêernaam vertel jou betroubaar nie een van die twee nie. Lees die kop voordat jy ’n biblioteek verander of ’n ander spieël probeer.

Klas sê woordgrootte, masjien sê instruksiestel

Die Linux ELF-verwysing definieer ’n klasveld en ’n masjienveld in die lêerkop, en die twee beantwoord verskillende vrae. Klas sê of die lêer 32-bis- of 64-bis-vorm gebruik; masjien sê vir watter instruksiestel dit gebou is. ’n 32-bis x86-bou en ’n 32-bis ARM-bou stem oor die eerste saam en verskil oor die tweede. Dis hoe ’n etiket wat die regte woordgrootte belowe, steeds kode lewer wat die verwerker nie kan dekodeer nie. Die derde waarde wat die moeite werd is om te lees, is die gevraagde interpreteerder, wat die programkoppe noem wanneer die binêre lêer een verklaar.

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

Die eerste opdrag druk die kop, die tweede druk programkoppe wanneer die lêer enige het, en die derde lys die gedeelde objekte wat die laaier nodig sal hê. Teken klas, masjien en interpreteerder saam op, want daardie drie waardes is die hele verenigbaarheidsvraag op hierdie vlak. Nie een van die drie verskyn op ’n aflaai-knoppie nie, en daarom moet die lêer ondersoek word eerder as beskryf.

Watter interpreteerder dit by die kern vra

’n Uitvoerbare lêer wat ’n interpreteerder verklaar, vra die kern om een spesifieke laaierpad. Wanneer daardie laaier ontbreek, faal die bekendstelling selfs al staan die lêer wat jy genoem het reg daar. Dis die punt waar mense besluit die aflaai is korrup, terwyl die werklike antwoord ’n laaier is wat die verspreiding nie verskaf nie.

Pas die laaier by die stelsel wat jy werklik gebruik: die bedryfstelsel-weergawe, die gebruikersruimte-argitektuur en die pakket wat die laaier verskaf. ’n 64-bis kern kan ’n 32-bis gebruikersruimte loop net wanneer daardie gebruikersruimte en sy laaier geïnstalleer is, so die verwerker se vermoëns is nie die beslissende faktor nie. Een kort kontrole noem die interpreteerder op ’n enkele reël, en dit neem minder tyd as ’n ondersteuningskaartjie. ’n Dopskrip faal weer anders, want sy interpreteerder word op die eerste reël genoem eerder as in ’n ELF-kop, en om daardie reël te lees kos niks.

file --brief ./vendor-vpn

Pas die aflaai by die pakket-argitektuur

Verspreidingspakket-argitekture kodifiseer dieselfde onderskeiding in hulle eie woordeskat, en daardie woordeskat is waarop ’n verskaffer se ondersteuningsverklaring verwys. Vergelyk die waarde wat jou pakketbestuurder rapporteer met die waarde wat die verskaffer dokumenteer, in plaas daarvan om ’n bemarkingsetiket teen ’n lêernaam te vergelyk. Die pare wat moeilikheid veroorsaak, is amd64 teenoor arm64, en armhf teenoor armel, want elke paar lyk uitruilbaar in ’n aflaailyse. ’n Lêernaam wat op x64 of ia32 eindig, beskryf ’n boutteiken, nie die masjien wat dit hou nie.

Elke ry is ’n geval waar die woordgrootte reg lyk en die kode steeds verkeerd optree, of waar dit begin en dan een laag laer faal. Lees die interpreteerder-kolom as ’n harde vereiste eerder as ’n wenk, want die kern los daardie pad op voordat enige van jou kode uitvoer. Emulasie is ’n ontplooiingsbesluit met sy eie prestasie- en ondersteuningsgevolge, en dit word nooit geïmpliseer deur ’n verwerker wat ’n wyer woordgrootte adverteer nie.

dpkg --print-architecture

ENOEXEC en ENOENT is verskillende foute

Die bekendstellingsfase rapporteer een van twee foute, en hulle wys na verskillende probleme. Om die foutwaarde te lees, klassifiseer die faling voordat jy enigiets anders hardloop.

ENOEXEC beteken die formaat is nie herken nie: verkeerde argitektuur, verkeerde klas, of iets wat glad nie ’n uitvoerbare lêer is nie. ENOENT op ’n ELF-lêer beteken gewoonlik die interpreteerder ontbreek, selfs al bestaan die lêer wat jy gevra het. Dieselfde ENOENT kan ook beteken ’n skrip se interpreteerder is afwesig, en daarom maak die eerste reël van ’n skrip saak. Hoe dit ook al sy, die boodskap noem die laag, en om elke nie-gevind as ’n ontbrekende konfigurasie te behandel, stuur die ondersoek in die verkeerde rigting. Haal die foutwaarde in die kaartjie aan, want dit oorleef oorvertelling beter as die sin daar rondom.

Wat om nie te doen wanneer die binêre lêer nie wil begin nie

Om ’n onverklaarde binêre lêer deur ’n skrip-omhulsel te dwing, maak nie dat dit loop nie. Moenie ’n afhanklikheidskontrole nonchalant op ’n lêer hardloop wat jy nie vertrou nie, want om dit te hardloop kan in sommige omstandighede kode uit die binêre lêer uitvoer. Moenie laaier-skakels byvoeg, gasheer-biblioteke omruil of ’n ou argief van ’n derdeparty-spieël haal om verby die boodskap te kom nie. Elkeen van daardie dinge verbreed die veranderingsoppervlak sonder om die wanverhouding te raak wat die kop reeds genoem het.

Wanneer jy die verskaffer nader, stuur waardes eerder as ’n verhaal: die bedryfstelsel-weergawe, die pakket-argitektuur, die klas- en masjienstringe, die gevraagde interpreteerder en die eerste foutreël. Daardie stel los ondersteuningsvrae vinniger op as ’n skermfoto van ’n falende installeerder. Ou artefakte en onthoude forum-uitsette is nie ’n huidige ondersteuningsmatriks nie, en sodra ’n inheemse binêre lêer laai, bly profiel, verifikasie en roetering aparte werk.