Desejo iniciar o wine executável (versão 2.12), mas recebo o seguinte erro ($ = prompt do shell):
$ wine bash: /usr/bin/wine: No such file or directory $ /usr/bin/wine bash: /usr/bin/wine: No such file or directory $ cd /usr/bin $ ./wine bash: ./wine: No such file or directory No entanto, o arquivo está lá:
$ which wine /usr/bin/wine O executável definitivamente está lá e nenhum link simbólico morto:
$ stat /usr/bin/wine File: /usr/bin/wine Size: 9712 Blocks: 24 IO Block: 4096 regular file Device: 802h/2050d Inode: 415789 Links: 1 Access: (0755/-rwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2017-07-13 13:53:00.000000000 +0200 Modify: 2017-07-08 03:42:45.000000000 +0200 Change: 2017-07-13 13:53:00.817346043 +0200 Birth: - É um ELF de 32 bits:
$ file /usr/bin/wine /usr/bin/wine: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=eaf6de433d8196e746c95d352e0258fe2b65ae24, stripped Posso obter a seção dinâmica do executável:
$ readelf -d /usr/bin/wine Dynamic section at offset 0x1efc contains 27 entries: Tag Type Name/Value 0x00000001 (NEEDED) Shared library: [libwine.so.1] 0x00000001 (NEEDED) Shared library: [libpthread.so.0] 0x00000001 (NEEDED) Shared library: [libc.so.6] 0x0000001d (RUNPATH) Library runpath: [$ORIGIN/../lib32] 0x0000000c (INIT) 0x7c000854 0x0000000d (FINI) 0x7c000e54 [more addresses without file names] No entanto, não posso listar as dependências de objetos compartilhados usando ldd:
$ ldd /usr/bin/wine /usr/bin/ldd: line 117: /usr/bin/wine: No such file or directory strace mostra:
execve("/usr/bin/wine", ["wine"], 0x7fff20dc8730 /* 66 vars */) = -1 ENOENT (No such file or directory) fstat(2, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 4), ...}) = 0 write(2, "strace: exec: No such file or di"..., 40strace: exec: No such file or directory ) = 40 getpid() = 23783 exit_group(1) = ? +++ exited with 1 +++ Editado para adicionar sugestão por @jww : O problema parece acontecer antes de ser vinculado dinamicamente bibliotecas são solicitados, porque nenhuma ld mensagem de depuração é gerada:
$ LD_DEBUG=all wine bash: /usr/bin/wine: No such file or directory Mesmo quando imprimindo apenas os valores possíveis de LD_DEBUG, o erro ocorre em seu lugar
$ LD_DEBUG=help wine bash: /usr/bin/wine: No such file or directory Editado para adicionar sugestão de @Raman Sailopal: O problema parece estar dentro do executável, pois copiar o conteúdo de /usr/bin/wine para outro arquivo já criado produz o mesmo erro
root:bin # cp cat testcmd root:bin # testcmd --help Usage: testcmd [OPTION]... [FILE]... Concatenate FILE(s) to standard output. [rest of cat help page] root:bin # dd if=wine of=testcmd 18+1 records in 18+1 records out 9712 bytes (9.7 kB, 9.5 KiB) copied, 0.000404061 s, 24.0 MB/s root:bin # testcmd bash: /usr/bin/testcmd: No such file or directory Qual é o problema ou o que posso fazer para descobrir qual arquivo ou diretório está faltando?
uname -a:
Linux laptop 4.11.3-1-ARCH #1 SMP PREEMPT Sun May 28 10:40:17 CEST 2017 x86_64 GNU/Linux Comentários
Resposta
Isto:
$ file /usr/bin/wine /usr/bin/wine: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=eaf6de433d8196e746c95d352e0258fe2b65ae24, stripped Combinado com isto:
$ ldd /usr/bin/wine /usr/bin/ldd: line 117: /usr/bin/wine: No such file or directory Sugere fortemente que o sistema não possui o /lib/ld-linux.so.2 interpretador ELF. Ou seja, este sistema de 64 bits não possui nenhuma biblioteca de compatibilidade de 32 bits instalada. Portanto, a resposta de @ user1334609 “está essencialmente correta.
Comentários
- Alguém vai falar sobre a mensagem de erro enganosa?
Resposta
Ok, estive ocupado nas últimas oito horas para colocar meu sistema em funcionamento novamente após o desligamento por superaquecimento da CPU Na reinicialização, tornou-se aparente que ele estava tão bagunçado que até mesmo o console substituto do initrd não reconhecia mais meu teclado. É um mistério para mim como o sistema conseguiu permanecer operante por tanto tempo, enquanto eu tentava implementar as inúmeras sugestões de vocês (muito obrigado !!)
Problema na reinicialização:
Warning: /lib/modules/4.11.3-1-ARCH/modules.devname not found - ignoring ERROR: device "UUID=..." not found. Skipping fsck. ERROR: Unable to find root device "UUID=...". You are being dropped to a recovery shell Type "exit" to try and continue booting sh: can"t access tty: job control turned off e nenhum teclado funcionou depois 🙂
O problema era: Uma atualização substituiu o link simbólico /lib -> /usr/lib com um diretório. Isso significava que todas as bibliotecas e módulos do kernel, que deveriam estar em /lib estavam faltando 🙂
Então eu recriei o link simbólico e reinstalei o sistema básico um CD ao vivo.
Agora que tenho internet novamente, também encontrei este tópico
Eu também usei o gerenciador de pacotes do meu instalação em disco bricked (chamada pacman) do live CD para reinstalar todos os pacotes do grupo base ( talvez apenas o kernel, então o pacote linux teria sido o suficiente, não sei)
Para fazer isso, monte a partição principal da instalação bricked para o diretório /mnt do sistema de live CD e use chroot para fazer pacman pensar /mnt é / (insira a partição principal do seu sistema bricked para sdXXX)
mount /dev/sdXXX /mnt # Recreate the /lib -> usr/lib symlink ln -s usr/lib /lib # Mount essential system folders also to the respective subfolders of /mnt mount -t proc proc /mnt/proc mount -t sysfs sys /mnt/sys mount -o bind /dev /mnt/dev # Fake /mnt to be /, so that pacman installs the packages to the correct places chroot /mnt # Reinstall the Arch Linux base system pacman -Sy base Para registro: crie um link simbólico relativo, então ln -s usr/lib /mnt/lib e não ln -s /usr/lib /mnt/lib, porque durante a inicialização inicial do sistema (estágio initrd), a partição principal será montada primeiro para /new_root.Se o link simbólico fosse absoluto, você obteria o erro mencionado acima durante a inicialização.
Comentários
- Pequena dica: ao usar o systemrescuecd, muitas vezes eu apenas itero sobre proc / sys / dev (para o caminho em proc sys dev; do mount -obind / $ path / mnt / $ path; done) antes de fazer o chroot. No entanto, se você ‘ estiver usando a iso de instalação do arch, é muito mais fácil apenas executar o executável arch-chroot fornecido, pois ele faz tudo para você. Está no pacote arch-install-scripts se alguém quiser bisbilhotar. 🙂
Resposta
Você está tentando executar um aplicativo de 32 bits em um sistema operacional de 64 bits, então você precisa instalar bibliotecas de compatibilidade de 32 bits (glibc em particular) para que isso funcione.
Comentários
- Esclareça como sua solução resolve o caso e responda a pergunta
- O que Romeu disse; você executaria apt-get em um sistema arch-linux, em vez de pacman? E como as bibliotecas de compactação e ncurses os ajudariam?
Resposta
Para sua informação, encontrei o mesmo problema ao executar em uma imagem docker baseada em alpino. O executável era um ELF de 64 bits, a imagem alpina de 64 bits e o executável funcionava em um contêiner diferente. Então, presumivelmente, as bibliotecas alpinas aparadas não eram compatíveis com meu executável. A página do hub do Docker node.js observa:
A advertência principal [para ser executado no contêiner baseado em Alpine] é que ele usa musl libc em vez de glibc e amigos , portanto, determinados softwares podem ter problemas dependendo da profundidade de seus requisitos libc. No entanto, a maioria dos softwares não tem problemas com isso, então essa variante é geralmente uma escolha muito segura. Consulte este tópico de comentários do Hacker News para mais discussões sobre o problemas que podem surgir e algumas comparações prós / contras do uso de imagens baseadas em Alpine.
Minha solução foi usar um diferente (por exemplo, baseado em Debian Jessie) imagem do contêiner.
Comentários
- Obrigado por conectar este problema originalmente de administrador de sistema ao ” novo ” mundo de contêineres!
/etc/pacman.conf. Todas as dependências do pacotewineestão instaladas. No entanto, reinstalá-los apenas para ter certeza …/lib/ld-linux.so.2está presente em seu sistema? Todos os sintomas apontam para a falta dele, basta verificar./libestava faltando 🙂filemostra qual interpretador está definido para este executável.