O instalador de VPN di 32 bits: revise a cabeceira ELF

Unha páxina de descarga di 32 bits, o ficheiro aterra nun Raspberry Pi e o instalador falla cunha mensaxe que non nomea ningunha parte útil do problema. Dous executables completamente distintos contan ambos como 32 bits no sentido ELF, e só un deles pode executarse nesa placa. O campo de clase é un feito, o campo de máquina é outro, e un nome de ficheiro non lle di de forma fiable ningún dos dous. Lea a cabeceira antes de cambiar unha biblioteca ou probar outro espello.

A clase di o tamaño de palabra, a máquina di o conxunto de instrucións

A referencia ELF de Linux define un campo de clase e un campo de máquina na cabeceira do ficheiro, e ambos responden preguntas distintas. A clase di se o ficheiro usa a forma de 32 bits ou a de 64 bits; a máquina di para que conxunto de instrucións se compilou. Unha compilación x86 de 32 bits e unha compilación ARM de 32 bits coinciden no primeiro e difiren no segundo. Así é como unha etiqueta que promete o tamaño de palabra correcto entrega igualmente código que o procesador non pode descodificar. O terceiro valor que merece lerse é o intérprete solicitado, que as cabeceiras de programa nomean cando o binario declara un.

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

O primeiro comando imprime a cabeceira, o segundo imprime as cabeceiras de programa cando o ficheiro ten algunha, e o terceiro lista os obxectos compartidos que o cargador necesitará. Anote clase, máquina e intérprete xuntos, porque eses tres valores son toda a cuestión de compatibilidade nesta capa. Ningún dos tres aparece nun botón de descarga, e por iso hai que inspeccionar o ficheiro en lugar de describilo.

Que intérprete lle pide ao núcleo

Un executable que declara un intérprete pide ao núcleo unha ruta de cargador concreta. Cando ese cargador falta, o arranque falla aínda que o ficheiro que vostede nomeou estea xusto alí. Ese é o punto no que a xente decide que a descarga está corrupta, cando a resposta real é un cargador que a distribución non inclúe.

Axuste o cargador ao sistema que realmente executa: a versión do sistema operativo, a arquitectura do espazo de usuario e o paquete que proporciona o cargador. Un núcleo de 64 bits pode executar un espazo de usuario de 32 bits só cando ese espazo e o seu cargador están instalados, así que as capacidades do procesador non son o factor decisivo. Unha comprobación breve nomea o intérprete nunha soa liña, e tarda menos que un ticket de soporte. Un script de shell falla doutra maneira, porque o seu intérprete se nomea na primeira liña e non nunha cabeceira ELF, e ler esa liña non custa nada.

file --brief ./vendor-vpn

Axuste a descarga á arquitectura do paquete

As arquitecturas de paquete das distribucións codifican a mesma distinción no seu propio vocabulario, e ese vocabulario é ao que se refire a declaración de soporte dun provedor. Compare o valor que informa o seu xestor de paquetes co valor que documenta o provedor, en lugar de comparar unha etiqueta de márketing cun nome de ficheiro. Os pares que causan problemas son amd64 fronte a arm64, e armhf fronte a armel, porque cada par parece intercambiable nunha lista de descarga. Un nome de ficheiro que remata en x64 ou ia32 describe un obxectivo de compilación, non a máquina que o contén.

Cada fila é un caso no que o tamaño de palabra parece correcto e o código segue comportándose mal, ou no que arranca e logo falla unha capa máis abaixo. Lea a columna de intérprete como un requisito duro e non como unha pista, porque o núcleo resolve esa ruta antes de que se execute calquera código seu. A emulación é unha decisión de despregamento coas súas propias consecuencias de rendemento e soporte, e nunca a implica un procesador que anuncia un tamaño de palabra maior.

dpkg --print-architecture

ENOEXEC e ENOENT son fallos distintos

A etapa de arranque informa un de dous erros, e apuntan a problemas diferentes. Ler o valor do erro clasifica o fallo antes de que execute calquera outra cousa.

ENOEXEC significa que o formato non se recoñeceu: arquitectura equivocada, clase equivocada ou algo que non é un executable en absoluto. ENOENT nun ficheiro ELF adoita significar que falta o intérprete, aínda que o ficheiro que pediu existe. O mesmo ENOENT tamén pode significar que falta o intérprete dun script, e por iso importa a primeira liña dun script. En calquera caso a mensaxe nomea a capa, e tratar cada «non atopado» como unha configuración ausente envía a investigación na dirección equivocada. Cite o valor do erro no ticket, porque sobrevive ao reconto mellor que a frase que o rodea.

Que non facer cando o binario non arranca

Forzar un binario non explicado a través dun envoltorio de shell non o fai funcionar. Non execute un comprobador de dependencias á lixeira sobre un ficheiro no que non confía, porque executalo pode executar código do binario nalgunhas circunstancias. Non engada ligazóns simbólicas do cargador, non cambie bibliotecas do host nin descargue un ficheiro antigo dun espello de terceiros para saltar a mensaxe. Cada unha desas cousas amplía a superficie de cambio sen tocar a discrepancia que a cabeceira xa nomeou.

Cando se dirixa ao provedor, envíe valores e non unha historia: a versión do sistema operativo, a arquitectura do paquete, as cadeas de clase e máquina, o intérprete solicitado e a primeira liña de erro. Ese conxunto resolve as preguntas de soporte máis rápido que unha captura de pantalla dun instalador que falla. Os artefactos antigos e as saídas de foro recordadas non son unha matriz de soporte actual, e unha vez que un binario nativo carga, o perfil, a autenticación e o encamiñamento seguen sendo traballo aparte.