L’installateur VPN annonce 32 bits : vérifiez plutôt l’en-tête ELF

Une page de téléchargement annonce 32 bits, le fichier atterrit sur un Raspberry Pi et l’installateur échoue avec un message qui ne nomme aucune partie utile du problème. Deux exécutables entièrement différents comptent tous deux comme 32 bits au sens ELF, et un seul d’entre eux peut tourner sur cette carte. Le champ de classe est un fait, le champ de machine en est un autre, et un nom de fichier ne vous dit fiablement ni l’un ni l’autre. Lisez l’en-tête avant de changer une bibliothèque ou d’essayer un autre miroir.

La classe dit la taille de mot, la machine dit le jeu d’instructions

La référence ELF de Linux définit un champ de classe et un champ de machine dans l’en-tête du fichier, et les deux répondent à des questions différentes. La classe indique si le fichier utilise la forme 32 bits ou 64 bits ; la machine indique pour quel jeu d’instructions il a été compilé. Une compilation x86 32 bits et une compilation ARM 32 bits s’accordent sur la première et diffèrent sur la seconde. C’est ainsi qu’une étiquette promettant la bonne taille de mot livre quand même du code que le processeur ne peut pas décoder. La troisième valeur qui vaut la lecture est l’interpréteur demandé, que les en-têtes de programme nomment quand le binaire en déclare un.

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

La première commande imprime l’en-tête, la seconde imprime les en-têtes de programme quand le fichier en a, et la troisième liste les objets partagés dont le chargeur aura besoin. Notez classe, machine et interpréteur ensemble, car ces trois valeurs sont toute la question de compatibilité à ce niveau. Aucune des trois n’apparaît sur un bouton de téléchargement, c’est pourquoi le fichier doit être inspecté plutôt que décrit.

Quel interpréteur il demande au noyau

Un exécutable qui déclare un interpréteur demande au noyau un chemin de chargeur précis. Quand ce chargeur manque, le lancement échoue alors même que le fichier que vous avez nommé se trouve juste là. C’est le point où les gens concluent que le téléchargement est corrompu, alors que la vraie réponse est un chargeur que la distribution ne fournit pas.

Faites correspondre le chargeur au système que vous exécutez réellement : la version du système, l’architecture de l’espace utilisateur et le paquet qui fournit le chargeur. Un noyau 64 bits ne peut exécuter un espace utilisateur 32 bits que si cet espace et son chargeur sont installés, donc les capacités du processeur ne sont pas le facteur décisif. Une courte vérification nomme l’interpréteur sur une seule ligne, et elle prend moins de temps qu’un ticket de support. Un script shell échoue encore autrement, car son interpréteur est nommé sur la première ligne et non dans un en-tête ELF, et lire cette ligne ne coûte rien.

file --brief ./vendor-vpn

Faites correspondre le téléchargement à l’architecture du paquet

Les architectures de paquets des distributions encodent la même distinction dans leur propre vocabulaire, et c’est à ce vocabulaire que renvoie la déclaration de support d’un fournisseur. Comparez la valeur que votre gestionnaire de paquets rapporte à celle que le fournisseur documente, au lieu de comparer une étiquette marketing à un nom de fichier. Les paires qui posent problème sont amd64 contre arm64, et armhf contre armel, car chaque paire semble interchangeable dans une liste de téléchargement. Un nom de fichier finissant par x64 ou ia32 décrit une cible de compilation, pas la machine qui le contient.

Chaque ligne est un cas où la taille de mot semble correcte et le code se comporte quand même mal, ou bien où il démarre puis échoue une couche plus bas. Lisez la colonne interpréteur comme une exigence ferme et non comme une indication, car le noyau résout ce chemin avant que la moindre partie de votre code s’exécute. L’émulation est une décision de déploiement avec ses propres conséquences de performance et de support, et elle n’est jamais impliquée par un processeur qui annonce une taille de mot plus large.

dpkg --print-architecture

ENOEXEC et ENOENT sont des échecs différents

L’étape de lancement rapporte l’une de deux erreurs, et elles pointent vers des problèmes différents. Lire la valeur de l’erreur classe l’échec avant que vous n’exécutiez quoi que ce soit d’autre.

ENOEXEC signifie que le format n’a pas été reconnu : mauvaise architecture, mauvaise classe ou quelque chose qui n’est pas du tout un exécutable. ENOENT sur un fichier ELF signifie généralement que l’interpréteur manque, même si le fichier que vous avez demandé existe. Le même ENOENT peut aussi signifier que l’interpréteur d’un script manque, c’est pourquoi la première ligne d’un script compte. Dans tous les cas le message nomme la couche, et traiter chaque « introuvable » comme une configuration absente envoie l’enquête dans la mauvaise direction. Citez la valeur de l’erreur dans le ticket, car elle survit mieux au récit que la phrase qui l’entoure.

Ce qu’il ne faut pas faire quand le binaire ne démarre pas

Forcer un binaire inexpliqué à travers un habillage shell ne le fait pas fonctionner. Ne lancez pas un vérificateur de dépendances à la légère sur un fichier auquel vous ne faites pas confiance, car son exécution peut dans certaines circonstances exécuter du code du binaire. N’ajoutez pas de liens symboliques de chargeur, n’échangez pas les bibliothèques de l’hôte et ne récupérez pas une vieille archive depuis un miroir tiers pour contourner le message. Chacune de ces actions élargit la surface de changement sans toucher l’incompatibilité que l’en-tête a déjà nommée.

Quand vous contactez le fournisseur, envoyez des valeurs plutôt qu’une histoire : la version du système, l’architecture du paquet, les chaînes de classe et de machine, l’interpréteur demandé et la première ligne d’erreur. Cet ensemble résout les questions de support plus vite qu’une capture d’écran d’un installateur qui échoue. Les anciens artefacts et les sorties de forum mémorisées ne sont pas une matrice de support actuelle, et une fois qu’un binaire natif se charge, le profil, l’authentification et le routage restent un travail séparé.