Il tuo binario VPN è compilato per questa CPU? Leggi l'intestazione ELF

Entrambi i file sono a 32 bit e solo uno di essi gira sulla tua scheda. Una build ELF32 per Intel e una build ELF32 per ARM concordano sul campo classe e discordano su tutto ciò che conta. Una pagina di download che offre un'opzione a 32 bit non ti ha detto quasi nulla finché non leggi l'intestazione del file che hai effettivamente scaricato. Rinominarlo non cambia una sola istruzione.

Classe e macchina rispondono a domande diverse

Il campo classe dice se il file usa strutture a 32 o a 64 bit. Il campo macchina nomina il set di istruzioni per cui il file è stato compilato. Leggere solo il primo è il modo in cui una build x86 finisce su una scheda ARM con un nome di file che sembra del tutto plausibile. Entrambi i valori provengono dallo stesso comando, per questo è così facile saltarne uno.

La stessa confusione vale per le etichette a 64 bit, dove aarch64 e x86-64 condividono una dimensione di parola e nessuna istruzione. Una pagina del fornitore che elenca un solo download a 64 bit descrive la propria build, non la tua macchina. Controlla l'intestazione del file invece dell'intestazione di colonna della pagina.

readelf -h ./vendor-vpn
readelf -l ./vendor-vpn | head -20
file ./vendor-vpn

Il primo comando stampa l'intestazione, comprese classe e macchina. Il secondo mostra le intestazioni di programma, dove risiede una richiesta di interprete. Il terzo ti dà una riga quando una tabella è più di quanto ti serve.

Aggiungere il permesso di esecuzione o correggere un controllo di distribuzione non traduce nulla. L'emulazione, dove la piattaforma la supporta, è una decisione di distribuzione con il proprio costo in prestazioni e dipendenze.

Leggi l'intestazione prima di eseguire l'installer

Ispeziona un artefatto fidato prima di eseguirne qualcosa. Un installer che fallisce a metà può lasciare librerie sostituite e niente che funzioni, il che è un punto di partenza peggiore dell'archivio con cui hai iniziato. L'ispezione dell'intestazione è in sola lettura e reversibile nel senso che nulla cambia sul sistema.

Confronta il campo macchina con l'architettura dei pacchetti del sistema in esecuzione, non con il nome commerciale della scheda. Una CPU a 64 bit che esegue uno spazio utente a 32 bit ha bisogno della build a 32 bit, e quel dettaglio decide quale download è nativo. La capacità della scheda non è il vincolo; lo è lo spazio utente installato.

dpkg --print-architecture
uname -m
getconf LONG_BIT

Il primo comando riporta l'architettura per cui il sistema installa i pacchetti, ed è il valore che deve corrispondere. Gli altri due descrivono il kernel e la dimensione della parola, e possono discordare dallo spazio utente in un'installazione multiarch.

Quando queste risposte discordano, decidi quale supporta il fornitore prima di scaricare un altro archivio. Indovinare produce un ciclo di installazioni che falliscono ciascuna in un punto diverso, e ogni fallimento sembra un nuovo problema.

Controlla l'interprete, non solo l'architettura

Un eseguibile dinamico registra il loader che si aspetta in un'intestazione di programma. Su un sistema con un percorso del loader diverso, il kernel rifiuta di avviare il file anche se il campo macchina corrisponde esattamente. È il fallimento che manda le persone a cercare librerie mancanti.

Il messaggio di errore ti dice in quale caso sei, e i due casi sono facili da confondere. Un rifiuto di formato o architettura è diverso da un file o un interprete mancante, e solo uno dei due si corregge installando un altro pacchetto.

readelf -l ./vendor-vpn | grep -A1 INTERP
ls -l /lib64/ld-linux-x86-64.so.2

Il primo comando mostra il percorso dell'interprete richiesto dal binario. Il secondo verifica se quel percorso esiste, il che separa una build sbagliata da un loader mancante.

Non eseguire un elencatore di dipendenze su un binario non fidato, perché alcune implementazioni possono eseguire il file che ispezionano. Mantieni l'ispezione in sola lettura e resisti alla tentazione di aggiungere link simbolici del loader per far partire una build non supportata.

Chiedi una build con i fatti in mano

Invia al fornitore la versione del sistema operativo, l'architettura dei pacchetti, i valori di classe e macchina e il primo messaggio di errore. Quella combinazione ottiene una risposta utile, mentre uno screenshot di un guasto generico ottiene un modello di supporto.

Tieni la questione del binario separata dalla questione della configurazione. Una volta avviata la build corretta, profili, credenziali e rotte restano problemi loro, e nessuna modifica dei profili farà funzionare un binario con architettura sbagliata.