/ home / amnesia / myfile: comando não encontrado - executável de 64 bits, kernel de 64 bits

Question

Tentando executar um arquivo executável no terminal (estou usando o Tails live OS), mas continuo recebendo uma mensagem de erro. Eu já defini permissões. O comando que escrevi:

sudo ./home/amnesia/myfile

Eu recebo "Comando não encontrado"?

Eu tentei executá-lo com ou sem sudo:

$ sudo /home/amnesia/myfile
sudo: unable to execute /home/amnesia/myfile: No such file or directory
$ /home/amnesia/myfile
bash: /home/amnesia/myfile: No such file or directory

Informações sobre o arquivo (é um binário, não um script):

$ ls -l /home/amnesia/myfile
-rwxrwxrwx 1 amnesia amnesia 15327 Sep  3  2013 /home/amnesia/myfile
$ file /home/amnesia/myfile
ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared lies), for GNU/Linux 2.6.9, not stripped

Informações sobre o meu sistema:

$ uname -a
Linux amnesia 3.16-3-amd64 #1 SMP Debian 3.16.5-1 (2014-10-10) x86_64 GNU/Linux
$ file /bin/ls
/bin/ls: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.26, BuildID[sha1]=0xd3280633faaabf56a14a26693d2f810a32222e51, stripped

    

Answer 1

$ /home/amnesia/myfile
bash: /home/amnesia/myfile: No such file or directory
$ file /home/amnesia/myfile
ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared lies), for GNU/Linux 2.6.9, not stripped

Portanto, myfile existe, mas a execução dá a mensagem "Nenhum arquivo ou diretório". Isso acontece na seguinte circunstância:

• O arquivo depende de um carregador - é um executável vinculado dinamicamente e precisa de um programa de carregamento para carregar as bibliotecas vinculadas dinamicamente. (O carregador também pode ser o intérprete designado por uma linha shebang, mas o bash detecta esse caso e fornece uma mensagem de erro diferente.)
• O arquivo do carregador não está presente.

A mensagem “Nenhum arquivo ou diretório” é realmente sobre o carregador, mas o shell não sabe que o carregador está envolvido, por isso ele relata o nome do arquivo original. Explico isso com mais detalhes em “Nenhum arquivo ou diretório” está em binários instalados pelo Optware .

Por que você não pode executar este programa? Porque você não tem o carregador dinâmico para executáveis de 64 bits.

$ uname -a
Linux amnesia 3.16-3-amd64 #1 SMP Debian 3.16.5-1 (2014-10-10) x86_64 GNU/Linux
$ file /bin/ls
/bin/ls: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.26, BuildID[sha1]=0xd3280633faaabf56a14a26693d2f810a32222e51, stripped

Seu sistema tem um kernel de 64 bits, mas o resto do sistema é de 32 bits. O Linux suporta essa configuração (um kernel de 64 bits pode executar programas de 64 bits e de 32 bits, mas um kernel de 32 bits só pode executar programas de 32 bits). O kernel pode carregar o programa muito bem; você seria capaz de executar um executável amd64 vinculado estaticamente. No entanto, você não tem o carregador de 64 bits ( /lib64/ld-linux-x86-64.so.2 ) nem presumivelmente qualquer biblioteca de 64 bits. Então você não pode executar executáveis amd64 dinamicamente vinculados.

Por que você executaria um kernel de 64 bits com uma área de usuário de 32 bits?

• Para usar mais de cerca de 3 GB de memória física. (Esta não é a única maneira - outra possibilidade é executar um kernel de 32 bits que suporte PAE).
• Para poder executar binários de 64 bits, por exemplo inicializando no SO ao vivo e então fazendo o script em um sistema de 64 bits instalado em algum lugar.
• Para reduzir o esforço de manutenção para a distribuição: forneça um único kernel para hardware recente e torne-o de 64 bits.
• Para executar máquinas virtuais de 64 bits (alguns mecanismos de VM exigem um kernel de 64 bits para executar uma VM de 64 bits).

Eu não acho que o Tails forneça um sistema de 64 bits. Você deve obter uma versão de 32 bits do executável. Se você não puder, use alguma outra distribuição (possivelmente em uma máquina virtual).

    

Answer 2

se você não tiver: chmod

chmod u+x /home/amnesia/myfile

e remova o '.' desde o começo. precisava quando você no mesmo diretório do arquivo é

sudo /home/amnesia/myfile

aqui está uma demonstração:

    

Answer 3

Sugiro que verifique o seguinte:

• Executar file /home/amnesia/myfile . Isso determinará o tipo de arquivo que você está tentando executar;
• Execute o script sem sudo para obter uma mensagem mais significativa;
• Se for algo como um script de shell, um set -x também ajudará você a descobrir o que está acontecendo. Você também pode executar o script com sh -x ;
• Pode ser uma linha quebrada de shebang (ex: intérprete ruim). Cole a saída de head -5 /home/amnesia/myfile ;
• Pode ser que você tenha novas linhas 'DOS' no seu script. Se esse arquivo for um script com novas linhas do DOS, um simples dos2unix myfile ou perl -pi -e 's/\r\n/\n/g' input.file poderá corrigir o problema;

Answer 4

Eu tive o mesmo problema. No Debian 7.8 a correção foi instalar o pacote lsb :

apt-get install lsb

Eu tive que instalar um pacote similar (não me lembro exatamente qual) no CentOS.