VPN-instalilo diras 32-bit: kontrolu la ELF-kapon anstataŭe

Paĝo de elŝuto diras 32-bit, la dosiero alteriĝas sur Raspberry Pi, kaj la instalilo malsukcesas kun mesaĝo kiu nomas neniun utilan parton de la problemo. Du tute malsamaj plenumeblaj dosieroj ambaŭ nombriĝas kiel 32-bit laŭ la ELF-signifo, kaj nur unu el ili povas ruliĝi sur tiu tabulo. La klasa kampo estas unu fakto, la maŝina kampo estas alia, kaj dosiernomo fidinde diras al vi neniun el ili. Legu la kapon antaŭ ol ŝanĝi bibliotekon aŭ provi alian spegulon.

La klaso diras vortgrandecon, la maŝino diras instrukciaron

La Linux ELF-referenco difinas klasan kampon kaj maŝinan kampon en la dosierkapa, kaj la du respondas malsamajn demandojn. La klaso diras ĉu la dosiero uzas la 32-bit-formon aŭ la 64-bit-formon; la maŝino diras por kiu instrukciaro ĝi estis konstruita. 32-bit x86-builto kaj 32-bit ARM-builto konsentas pri la unua kaj malkonsentas pri la dua. Tiel etikedo promesanta la ĝustan vortgrandecon ankoraŭ liveras kodon, kiun la procesoro ne povas malĉifri. La tria leginda valoro estas la petata interpretilo, kiun la programkapoj nomas kiam la binara dosiero deklaras unu.

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

La unua komando presas la kapon, la dua presas programkapojn kiam la dosiero havas iujn, kaj la tria listigas la kunhavatajn objektojn, kiujn la ŝargilo bezonos. Notu klason, maŝinon kaj interpretilon kune, ĉar tiuj tri valoroj estas la tuta kongrueca demando ĉe ĉi tiu tavolo. Neniu el la tri aperas sur elŝuta butono, kaj tial la dosiero devas esti ekzamenata, ne priskribata.

Kiun interpretilon ĝi petas de la kerno

Plenumebla dosiero, kiu deklaras interpretilon, petas de la kerno unu specifan ŝargilan vojon. Kiam tiu ŝargilo mankas, la lanĉo malsukcesas eĉ se la dosiero, kiun vi nomis, kuŝas ĝuste tie. Tio estas la punkto, kie homoj decidas, ke la elŝuto estas difektita, dum la reala respondo estas ŝargilo, kiun la distribuo ne liveras.

Kongruigu la ŝargilon kun la sistemo, kiun vi efektive rulas: la OS-eldono, la arkitekturo de la uzantspaco kaj la pako, kiu provizas la ŝargilon. 64-bit kerno povas ruli 32-bit uzantspacon nur kiam tiu uzantspaco kaj ĝia ŝargilo estas instalitaj, do la kapabloj de la procesoro ne estas la decida faktoro. Unu mallonga kontrolo nomas la interpretilon en unu linio, kaj ĝi daŭras malpli ol subtena bileto. Shell-skripto malsukcesas denove alimaniere, ĉar ĝia interpretilo estas nomata en la unua linio, ne en ELF-kapo, kaj legi tiun linion kostas nenion.

file --brief ./vendor-vpn

Kongruigu la elŝuton kun la paka arkitekturo

La pakaj arkitekturoj de distribuaĵoj kodas la saman distingon en sia propra vortprovizo, kaj al tiu vortprovizo raportas la subtena deklaro de vendanto. Komparu la valoron, kiun via pakadministrilo raportas, kun la valoro, kiun la vendanto dokumentas, anstataŭ kompari merkatan etikedon kun dosiernomo. La paroj, kiuj kaŭzas problemojn, estas amd64 kontraŭ arm64 kaj armhf kontraŭ armel, ĉar ĉiu paro aspektas interŝanĝebla en elŝuta listo. Dosiernomo finiĝanta per x64 aŭ ia32 priskribas buildan celon, ne la maŝinon, kiu ĝin tenas.

Ĉiu vico estas kazo, kie la vortgrandeco aspektas ĝusta kaj la kodo tamen miskondutas, aŭ kie ĝi startas kaj poste malsukcesas unu tavolon pli malalte. Legu la interpretilan kolumnon kiel malmolan postulon, ne kiel aludon, ĉar la kerno solvas tiun vojon antaŭ ol kia ajn via kodo plenumiĝas. Emulado estas deploja decido kun propraj sekvoj por rendimento kaj subteno, kaj ĝin neniam implicas procesoro reklamanta pli larĝan vortgrandecon.

dpkg --print-architecture

ENOEXEC kaj ENOENT estas malsamaj fiaskoj

La lanĉa fazo raportas unu el du eraroj, kaj ili montras al malsamaj problemoj. Legi la eraran valoron klasifikas la fiaskon antaŭ ol vi rulas ion alian.

ENOEXEC signifas, ke la formato ne estis rekonoita: malĝusta arkitekturo, malĝusta klaso, aŭ io, kio entute ne estas plenumebla dosiero. ENOENT ĉe ELF-dosiero kutime signifas, ke la interpretilo mankas, kvankam la dosiero, kiun vi petis, ekzistas. La sama ENOENT povas ankaŭ signifi, ke mankas la interpretilo de skripto, tial la unua linio de skripto gravas. Ĉiukaze la mesaĝo nomas la tavolon, kaj trakti ĉiun «ne trovita» kiel mankan agordon sendas la esploron en la malĝustan direkton. Citu la eraran valoron en la bileto, ĉar ĝi pluvivas rerakonton pli bone ol la frazo ĉirkaŭ ĝi.

Kion ne fari kiam la binara dosiero ne startas

Trudi neklarigitan binaran dosieron tra shell-ĉirkaŭaĵo ne igas ĝin ruliĝi. Ne rulu dependecon-kontrolilon senzorge sur dosiero, kiun vi ne fidas, ĉar ĝia rulo povas en iuj cirkonstancoj plenumi kodon el la binara dosiero. Ne aldonu ŝargilajn simbolajn ligilojn, ne interŝanĝu gastigantajn bibliotekojn kaj ne elŝutu malnovan arĥivon de triaparta spegulo por preterpasi la mesaĝon. Ĉiu el tiuj larĝigas la ŝanĝan surfacon sen tuŝi la malkongruon, kiun la kapo jam nomis.

Kiam vi turnas vin al la vendanto, sendu valorojn, ne rakonton: la OS-eldonon, la pakan arkitekturon, la klasajn kaj maŝinajn ĉenojn, la petatan interpretilon kaj la unuan erar-linion. Tiu aro solvas subtenajn demandojn pli rapide ol ekrankopio de malsukcesanta instalilo. Malnovaj artefaktoj kaj memoritaj forumaj eligoj ne estas aktuala subtena matrico, kaj post kiam indiĝena binara dosiero ŝargiĝas, profilo, aŭtentikigo kaj enkursigado restas aparta laboro.