L’instal·lador de VPN diu 32 bits: mireu la capçalera ELF

Una pàgina de descàrrega diu 32 bits, el fitxer arriba a una Raspberry Pi i l’instal·lador falla amb un missatge que no nomena cap part útil del problema. Dos executables completament diferents compten tots dos com a 32 bits en el sentit ELF, i només un d’ells pot executar-se en aquesta placa. El camp de classe és un fet, el camp de màquina és un altre, i un nom de fitxer no us diu de manera fiable cap dels dos. Llegiu la capçalera abans de canviar una biblioteca o provar un altre mirall.

La classe diu la mida de paraula, la màquina diu el conjunt d’instruccions

La referència ELF de Linux defineix un camp de classe i un camp de màquina a la capçalera del fitxer, i tots dos responen preguntes diferents. La classe diu si el fitxer fa servir la forma de 32 bits o la de 64 bits; la màquina diu per a quin conjunt d’instruccions es va construir. Una compilació x86 de 32 bits i una compilació ARM de 32 bits coincideixen en el primer i difereixen en el segon. Així és com una etiqueta que promet la mida de paraula correcta encara lliura codi que el processador no pot descodificar. El tercer valor que val la pena llegir és l’intèrpret sol·licitat, que les capçaleres de programa nomenen quan el binari en declara un.

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

La primera ordre imprimeix la capçalera, la segona imprimeix les capçaleres de programa quan el fitxer en té, i la tercera llista els objectes compartits que el carregador necessitarà. Anoteu classe, màquina i intèrpret junts, perquè aquests tres valors són tota la qüestió de compatibilitat en aquesta capa. Cap dels tres no apareix en un botó de descàrrega, i per això cal inspeccionar el fitxer en lloc de descriure’l.

Quin intèrpret demana al nucli

Un executable que declara un intèrpret demana al nucli una ruta de carregador concreta. Quan aquest carregador falta, l’arrencada falla encara que el fitxer que heu nomenat sigui just allà. Aquest és el punt on la gent decideix que la descàrrega és corrupta, quan la resposta real és un carregador que la distribució no forneix.

Feu coincidir el carregador amb el sistema que realment executeu: la versió del sistema operatiu, l’arquitectura de l’espai d’usuari i el paquet que forneix el carregador. Un nucli de 64 bits pot executar un espai d’usuari de 32 bits només quan aquest espai i el seu carregador estan instal·lats, així que les capacitats del processador no són el factor decisiu. Una comprovació curta nomena l’intèrpret en una sola línia, i triga menys que un tiquet de suport. Un script de shell falla encara d’una altra manera, perquè el seu intèrpret es nomena a la primera línia i no en una capçalera ELF, i llegir aquesta línia no costa res.

file --brief ./vendor-vpn

Feu coincidir la descàrrega amb l’arquitectura del paquet

Les arquitectures dels paquets de distribució codifiquen la mateixa distinció amb el seu propi vocabulari, i és aquest vocabulari al qual es refereix la declaració de suport d’un proveïdor. Compareu el valor que informa el vostre gestor de paquets amb el valor que documenta el proveïdor, en lloc de comparar una etiqueta de màrqueting amb un nom de fitxer. Les parelles que causen problemes són amd64 contra arm64, i armhf contra armel, perquè cada parella sembla intercanviable en una llista de descàrrega. Un nom de fitxer que acaba en x64 o ia32 descriu un objectiu de compilació, no la màquina que el conté.

Cada fila és un cas on la mida de paraula sembla correcta i el codi encara es comporta malament, o on arrenca i després falla una capa més avall. Llegiu la columna d’intèrpret com un requisit dur i no com un indici, perquè el nucli resol aquesta ruta abans que s’executi cap del vostre codi. L’emulació és una decisió de desplegament amb les seves pròpies conseqüències de rendiment i suport, i mai no la implica un processador que anuncia una mida de paraula més gran.

dpkg --print-architecture

ENOEXEC i ENOENT són fallades diferents

L’etapa d’arrencada informa d’un dels dos errors, i apunten a problemes diferents. Llegir el valor de l’error classifica la fallada abans que executeu res més.

ENOEXEC vol dir que el format no s’ha reconegut: arquitectura equivocada, classe equivocada o alguna cosa que no és cap executable. ENOENT en un fitxer ELF normalment vol dir que falta l’intèrpret, encara que el fitxer que heu demanat existeixi. El mateix ENOENT també pot voler dir que falta l’intèrpret d’un script, i per això la primera línia d’un script importa. En qualsevol cas el missatge nomena la capa, i tractar cada «no trobat» com una configuració que falta envia la investigació en la direcció equivocada. Citeu el valor de l’error al tiquet, perquè sobreviu a la reexplicació millor que la frase del voltant.

Què no fer quan el binari no arrenca

Forçar un binari no explicat a través d’un embolcall de shell no el fa funcionar. No executeu un comprovador de dependències amb lleugeresa sobre un fitxer en què no confieu, perquè executar-lo pot fer córrer codi del binari en algunes circumstàncies. No afegiu enllaços simbòlics del carregador, no canvieu biblioteques de l’amfitrió ni baixeu un arxiu antic d’un mirall de tercers per saltar-vos el missatge. Cadascuna d’aquestes coses amplia la superfície de canvi sense tocar la discrepància que la capçalera ja ha nomenat.

Quan us adreceu al proveïdor, envieu valors i no una història: la versió del sistema operatiu, l’arquitectura del paquet, les cadenes de classe i màquina, l’intèrpret sol·licitat i la primera línia d’error. Aquest conjunt resol les preguntes de suport més de pressa que una captura de pantalla d’un instal·lador que falla. Els artefactes antics i les sortides de fòrum recordades no són una matriu de suport actual, i un cop un binari natiu es carrega, el perfil, l’autenticació i l’encaminament segueixen sent feina a part.