Votre binaire VPN est-il compilé pour ce processeur ? Lisez l'en-tête ELF

Les deux fichiers sont en 32 bits et un seul d'entre eux s'exécute sur votre carte. Une compilation ELF32 pour Intel et une compilation ELF32 pour ARM s'accordent sur le champ de classe et diffèrent sur tout ce qui compte. Une page de téléchargement proposant une option 32 bits ne vous a presque rien dit tant que vous n'avez pas lu l'en-tête du fichier que vous avez réellement téléchargé. Le renommer ne change pas une seule instruction.

La classe et la machine répondent à des questions différentes

Le champ de classe indique si le fichier utilise des structures 32 bits ou 64 bits. Le champ de machine nomme le jeu d'instructions pour lequel le fichier a été compilé. Ne lire que le premier, c'est ainsi qu'une compilation x86 atterrit sur une carte ARM avec un nom de fichier qui paraît parfaitement plausible. Les deux valeurs viennent de la même commande, c'est pourquoi il est si facile d'en oublier une.

La même confusion vaut pour les étiquettes 64 bits, où aarch64 et x86-64 partagent une taille de mot et aucune instruction. Une page de fournisseur qui liste un seul téléchargement 64 bits décrit sa propre compilation, pas votre machine. Vérifiez l'en-tête du fichier plutôt que l'en-tête de colonne de la page.

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

La première commande affiche l'en-tête, classe et machine comprises. La seconde montre les en-têtes de programme, où réside une demande d'interpréteur. La troisième vous donne une ligne quand un tableau est plus que ce dont vous avez besoin.

Ajouter un droit d'exécution ou corriger un contrôle de distribution ne traduit rien. L'émulation, là où la plateforme la prend en charge, est une décision de déploiement avec son propre coût en performance et en dépendances.

Lisez l'en-tête avant de lancer l'installateur

Inspectez un artefact de confiance avant d'en exécuter quoi que ce soit. Un installateur qui échoue à mi-chemin peut laisser des bibliothèques remplacées et rien qui fonctionne, ce qui est un pire point de départ que l'archive avec laquelle vous avez commencé. L'inspection de l'en-tête est en lecture seule et réversible au sens où rien ne change sur le système.

Comparez le champ de machine à l'architecture de paquets du système en cours d'exécution, pas au nom commercial de la carte. Un processeur 64 bits exécutant un espace utilisateur 32 bits a besoin de la compilation 32 bits, et ce détail décide quel téléchargement est natif. La capacité de la carte n'est pas la contrainte ; l'espace utilisateur installé l'est.

dpkg --print-architecture
uname -m
getconf LONG_BIT

La première commande indique l'architecture pour laquelle le système installe des paquets, et c'est la valeur qui doit correspondre. Les deux autres décrivent le noyau et la taille de mot, et elles peuvent différer de l'espace utilisateur lors d'une installation multiarch.

Quand ces réponses divergent, décidez laquelle le fournisseur prend en charge avant de télécharger une autre archive. Deviner produit une boucle d'installations qui échouent chacune à un endroit différent, et chaque échec ressemble à un nouveau problème.

Vérifiez l'interpréteur, pas seulement l'architecture

Un exécutable dynamique enregistre le chargeur qu'il attend dans un en-tête de programme. Sur un système dont le chemin du chargeur diffère, le noyau refuse de démarrer le fichier même si le champ de machine correspond exactement. C'est l'échec qui envoie les gens chercher des bibliothèques manquantes.

Le message d'erreur vous dit dans quel cas vous êtes, et les deux cas sont faciles à confondre. Un rejet de format ou d'architecture diffère d'un fichier ou d'un interpréteur manquant, et un seul d'entre eux se corrige en installant un autre paquet.

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

La première commande montre le chemin d'interpréteur que demande le binaire. La seconde vérifie si ce chemin existe, ce qui sépare une mauvaise compilation d'un chargeur manquant.

N'exécutez pas un listeur de dépendances sur un binaire non fiable, car certaines implémentations peuvent exécuter le fichier qu'elles inspectent. Gardez l'inspection en lecture seule et résistez à l'ajout de liens symboliques de chargeur pour faire démarrer une compilation non prise en charge.

Demandez une compilation avec les faits en main

Envoyez au fournisseur la version du système d'exploitation, l'architecture de paquets, les valeurs de classe et de machine et le premier message d'erreur. Cette combinaison obtient une réponse utile, tandis qu'une capture d'écran d'un échec générique obtient un modèle de support.

Gardez la question du binaire séparée de la question de la configuration. Une fois la bonne compilation démarrée, les profils, les identifiants et les routes restent leurs propres problèmes, et aucune quantité d'édition de profil ne fera fonctionner un binaire d'architecture incorrecte.