web-dev-qa-db-fra.com

Comment puis-je résoudre l'erreur "impossible d'exécuter le fichier binaire"?

Lorsque je me connecte à l'aide de SSH, tout ce que je peux voir, c'est ceci ...

-bash: /usr/bin/id: cannot execute binary file
-bash: [: : integer expression expected

Je ne pouvais rien faire ici. Des commandes telles que halt, poweroff, reboot renverront command not found.

Comment puis-je réparer cela? J'utilise Debian Squeeze Linux

76
superuser

Habituellement, ce message d'erreur signifie que Linux ne reconnaît pas le fichier en tant que script Shell ou en tant que fichier exécutable.

Généralement, la cause est que l'exécution d'un fichier exécutable se fait sur une architecture incorrecte. Si vous essayez d'exécuter des exécutables x86 sur une CPU ARM, ce message s'affiche.

Est-ce que /usr/bin/id a été éventuellement écrasé?

80
LawrenceC

Essayez de l'exécuter en utilisant ./executablefilename au lieu d'utiliser sh executablefilename. Ce n'est pas un script Shell après tout.

23
RidDeBakTiYar

Le problème consiste à exécuter un fichier binaire pour une architecture de processeur différente. Vous pouvez utiliser objdump (à partir de binutils) pour vérifier l'architecture des fichiers binaires. Vous pouvez utiliser uname pour vérifier l'architecture d'une machine.

par exemple. J'ai rencontré cette erreur "impossible d'exécuter le fichier binaire" lors de l'installation de FF.Communicator - un plug-in firefox pour Chrome (je peux donc exécuter les pages utilisant des applets Java).

  • objdump indique que le binaire est en 64 bits elf64-x86-64
  • uname montre que ma machine est en 32 bits i686

    $ ./FF.Communicator bash: ./FF.Communicator: impossible d'exécuter le fichier binaire $ uname -mpio i686 i686 GNU/Linux $ objdump -a ./FF.Communicator ./FF.Communicator: format de fichier elf64-x86-64 ./Communicateur

  • objdump sur un binaire en état de fonctionnement sur ma machine indique qu'il s'agit de 32 bits elf32-i386

    $ objdump -a/bin/ls/bin/ls: format de fichier elf32-i386

En utilisant ces outils, vous pouvez vérifier les architectures des machines et des fichiers binaires, pas seulement les architectures intel, mais également les processeurs.

Pour les utilisateurs de Mac OSX, vous pouvez trouver les informations d'architecture d'un fichier spécifique à l'aide de la commande "fichier":

$ file filename_here
9
gaoithe

Je fais des suppositions folles ici, mais il semble que ce qui suit se passe:

  1. Vous vous connectez via SSH, en déclenchant bash pour exécuter votre ~/.profile ou ~/.bashrc afin de configurer votre environnement pour vous (ceci est normal).
  2. À un moment donné, il tente d'exécuter /bin/id pour obtenir votre ID utilisateur, ce qui échoue, ce qui provoque une erreur d'expression entière et met fin au script avant de pouvoir configurer votre $PATH.
  3. Parce que votre $PATH n'est pas défini, bash ne peut exécuter que des commandes avec le chemin complet spécifié.

Utilisez export PATH=/bin:/usr/bin:/sbin:/usr/sbin pour résoudre le problème $PATH jusqu'à ce que vous puissiez réparer la cause première de l'échec de/bin/id.

5
Darth Android

le fichier binaire est constitué d'instructions machine que le processeur peut comprendre. Votre système d'exploitation ne signifie pas que le même exécutable sera exécuté. aller et venir entre le jeu d'instructions du processeur compatible avec fonctionnera généralement bien, si elles ne sont pas compatibles CPU ne sera pas en mesure de comprendre les instructions.

0
acoh Facha

Cela signifie que vous essayez d'exécuter un fichier binaire à l'aide de votre script bash, qui n'est pas destiné à être exécuté tel que vous l'avez essayé. C'est déjà un fichier binaire et vous essayez d'analyser et d'exécuter votre $ Shell.

dans un exemple très simple, si vous essayez d’exécuter la commande `w 'comme

$ bash w
/usr/bin/w: /usr/bin/w: cannot execute binary file

de la même manière, vous pouvez utiliser la même méthode ou telle qu'elle apparaît dans votre extrait de code.

Tandis que, pour le reste de vos commandes, toutes ces commandes d’arrêt, d’arrêt, de redémarrage, etc. appartiennent à la racine et ont besoin de réglages de super-utilisateur pour être exécutées et exécutées. Les utilisateurs normaux ne peuvent pas les exécuter. Une autre explication est que ces commandes sont placées dans/sbin/et/usr/sbin, ce qui pourrait ne pas être dans votre variable $ PATH (utilisée pour valider les commandes sous votre garde)

0
Nasir Mahmood