Obtention du message "Not found" lors de l'exécution d'un fichier binaire 32 bits sur un système 64 bits

J'ai actuellement un problème étrange sur debian (Wheezy / amd64).

J'ai créé un chroot pour installer un serveur (je ne peux pas donner plus de détails à ce sujet, désolé). Appelons son chemin /chr_path/. Pour rendre les choses faciles, j'ai initialisé ce chroot avec un debootstrap (également Wheezy / amd64).

Tout semblait bien fonctionner à l'intérieur du chroot, mais lorsque j'ai lancé le script d'installation de mon serveur, j'ai reçu: zsh: Not found /some_path/perl(l'installateur contient un binaire Perl pour certaines raisons)

Naturellement, j'ai vérifié l' /some_path/emplacement et j'ai trouvé le binaire "perl". fileen environnement chroot, retourne:

/some_path/perl ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.2.5, not stripped

Le fichier existe, semble ok, a les droits corrects. Je peux utiliser file, ls, vimsur elle , mais dès que je tente de l' exécuter - ./perlpar exemple - je reçois: zsh: Not found ./perl.

Cette situation est tout à fait compréhensible pour moi. De plus :

Je peux exécuter d'autres binaires de base (/ bin / ls, ...) dans le chroot sans commettre d'erreur
J'ai les mêmes problèmes pour les autres fichiers binaires fournis avec le projet
Lorsque j'essaie d'exécuter le binaire à partir de la racine principale ( /chr_path/some_path/perl), cela fonctionne.
J'ai essayé de mettre un des binaires avec une copie de mon fichier ls. J'ai vérifié que les droits d'accès étaient les mêmes mais cela ne changeait rien (l'un fonctionnait, l'autre ne l'était pas)

— Elenaher
source

Il s'agit du même problème car "Aucun fichier ou répertoire de ce type" ne concerne les fichiers binaires installés par Optware . Notez que votre Perl est un exécutable 32 bits. Vous manquez le système d'exécution 32 bits ( libc6-i386package, ou ia32-libssi vous voulez beaucoup de bibliothèques).

— Gilles, arrête de faire le mal

@ Gilles: Merci beaucoup! Une installation d'aptitude ia32-libs a résolu le problème !! J'avais vu que le Perl était de 32 bits, mais comme il fonctionnait sur le système principal (le même distrib), je pensais qu'il n'était pas lié. En fait, je dois avoir installé le système d’exécution 32 bits sur le système principal à un moment donné.

— Elenaher

@ Gilles: Je pense que j'ajouterais cela comme une réponse concise au lieu de marquer ceci comme une question dupliquée. L’environnement est suffisamment différent pour que, même si le problème est le même, les personnes à la recherche ont plus de chances de frapper l’un ou l’autre.

— Caleb

@Caleb Nous ne supprimons pas les doublons pour exactement cette raison; les chercheurs qui trouveront celui-ci suivront simplement le lien en double vers l'autre message. Si tel est le même problème, il devrait probablement être fermé

— Michael Mrozek

@MichaelMrozek J'ai changé d'avis sur cette question: bien que le problème sous-jacent soit le même, la solution concrète est un peu différente (ne pas mélanger les ABI ARM dans un cas, ce qui permet une prise en charge 32 bits sur une distribution Linux amd64 dans l'autre). . Donc, je suppose que cette question est ouverte après tout.

— Gilles 'SO- arrête d'être méchant'

Réponses:

Lorsque vous ne parvenez pas à exécuter un fichier dépendant d'un «chargeur», l'erreur que vous obtenez peut faire référence au chargeur plutôt qu'au fichier que vous exécutez.

Le chargeur d'un exécutable natif lié dynamiquement est la partie du système responsable du chargement des bibliothèques dynamiques. C'est quelque chose comme /lib/ld.soou /lib/ld-linux.so.2, et devrait être un fichier exécutable.
Le chargeur d'un script est le programme mentionné sur la ligne shebang, par exemple /bin/shpour un script qui commence par #!/bin/sh. (Bash et zsh affichent un message «mauvais interprète» au lieu de «commande introuvable» dans ce cas.)

Le message d'erreur est plutôt trompeur car il n'indique pas que le chargeur est le problème. Malheureusement, il serait difficile de résoudre ce problème car l'interface du noyau ne permettait de signaler qu'un code d'erreur numérique, mais pas d'indiquer également que l'erreur concernait en fait un fichier différent. Certains shells font le travail eux-mêmes pour les scripts (en lisant la #!ligne et en retravaillant la condition d'erreur), mais aucun de ceux que j'ai vus ne tente de faire la même chose pour les fichiers binaires natifs.

lddCela ne fonctionnera pas non plus sur les fichiers binaires, car il définit des variables d’environnement spéciales, puis exécute le programme et permet au chargeur d’effectuer le travail. stracene fournirait aucune information significative non plus, car il ne rapporterait pas plus que ce que le noyau rapportait, et comme nous l'avons vu, le noyau ne peut pas tout rapporter.

Cette situation se produit souvent lorsque vous essayez d'exécuter un fichier binaire pour le bon système (ou la bonne famille de systèmes) et la superarchitecture, mais pour la mauvaise sous-architecture. Ici, vous avez des binaires ELF sur un système qui en attend, le noyau les charge donc parfaitement. Ce sont des binaires i386 s'exécutant sur un processeur x86_64. Les instructions ont donc un sens et permettent au programme de rechercher le chargeur. Mais le programme est un programme 32 bits (comme le filemontre la sortie) cherche le chargeur 32 bits /lib/ld-linux.so.2et vous n’avez probablement installé que le chargeur 64 bits /lib64/ld-linux-x86-64.so.2dans le chroot.

Vous devez installer le système d'exécution 32 bits dans le chroot: le chargeur et toutes les bibliothèques dont les programmes ont besoin. À partir de Debian Wheezy, si vous souhaitez une prise en charge de i386 et x86_64, commencez par une installation amd64 et activez le support multiarch : run dpkg --add-architecture i386then apt-get updateet apt-get install libc6:i386 zlib1g:i386 …(si vous souhaitez générer une liste des dépendances du paquet perl de Debian, voyez ce que les bibliothèques sont susceptibles de contenir. être nécessaire, vous pouvez utiliser aptitude search -F %p '~Rdepends:^perl$ ~ri386'). Vous pouvez extraire une collection de bibliothèques communes en installant le ia32-libspaquet (vous devez d'abord activer le support multiarch). Sur Debian amd64 jusqu’à Wheezy, le chargeur 32 bits est dans le libc6-i386paquet. Vous pouvez installer un plus grand ensemble de bibliothèques 32 bits en installant ia32-libs.

— Gilles, arrête de faire le mal
source

Est-ce la seule chose qui peut déclencher le message d'erreur? J'ai les bibliothèques 32 bits installées et voici la sortie deldd mais je reçois toujours la même erreur.

— Nathan Osman

@NathanOsman Probablement unix.stackexchange.com/questions/76490/…

— Gilles 'arrête d'être méchant'

J'ai essayé d'installer lsb-coremais cela n'a pas semblé aider. Je pense que je ferais mieux d'ouvrir une nouvelle question pour cela.

— Nathan Osman

Merci pour cela, vous venez de terminer deux jours de casse-tête. Je pensais que tout était compilé statiquement mais ce n'était pas le cas!

— Finn O'leary

Courez ldd(1)sur votre perlbinaire. Souvent, l' Not founderreur apparemment déroutante sur un fichier qui est clairement là existe parce qu'une des bibliothèques partagées utilisées par le programme est introuvable.

Il est donc possible que votre chroot soit incomplet en ce qui concerne les bibliothèques partagées nécessaires à vos fichiers binaires.

— camh
source

En fait, je reçois: perl is not a dynamic executablequand je suis dans le chroot et que je reçois la liste correcte des dépendances de l’extérieur. Je vérifie actuellement s'il y a quelque chose d'étrange, mais j'ai utilisé un debootstrap pour éviter ce type de manque et j'ai déjà beaucoup de bibliothèques en place (il y a un exécutable perl dans le système chroot qui fonctionne bien mais c'est une version différente; peut-être que je ferai juste quelques lien symbolique?)

— Elenaher

Pour être honnête, j'aurais cru que debootstrap aurait produit un chroot complet, aussi je ne m'attendrais pas à ce que ma réponse soit correcte à cet égard. Mais je suis tombé sur la bibliothèque manquante dans le problème de chroot avant alors j'ai pensé que je verrais si ma réponse volerait.

— camh

cf. Commentaire à Gilles sur l'article principal: Vous aviez raison. Il manquait des libs. Le principal avantage de debootstrap est que je pouvais résoudre le problème avec une installation d'aptitude de base :)

— Elenaher