Quiero iniciar el wine ejecutable (Versión 2.12), pero obtengo el siguiente error ($ = indicador de 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 

Sin embargo, el archivo está ahí:

$ which wine /usr/bin/wine 

El ejecutable definitivamente está ahí y no hay un enlace simbólico muerto:

$ 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: - 

Es un 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 

Puedo obtener la sección dinámica del ejecutable:

$ 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] 

Sin embargo, no puedo enumerar las dependencias de objetos compartidos usando ldd:

$ ldd /usr/bin/wine /usr/bin/ldd: line 117: /usr/bin/wine: No such file or directory 

strace muestra:

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 agregar una sugerencia por @jww : el problema parece ocurrir antes de que se vincule dinámicamente bibliotecas se solicitan porque no se generan ld mensajes de depuración:

$ LD_DEBUG=all wine bash: /usr/bin/wine: No such file or directory 

Incluso cuando solo se imprimen los valores posibles de LD_DEBUG, se produce el error en su lugar

$ LD_DEBUG=help wine bash: /usr/bin/wine: No such file or directory 

Editado para agregar sugerencia de @Raman Sailopal: El problema parece estar dentro del ejecutable, ya que copiar el contenido de /usr/bin/wine a otro archivo ya creado produce el mismo error

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 

¿Cuál es el problema o qué puedo hacer para averiguar qué archivo o directorio falta?


uname -a:

Linux laptop 4.11.3-1-ARCH #1 SMP PREEMPT Sun May 28 10:40:17 CEST 2017 x86_64 GNU/Linux 

Comentarios

  • hace ./wine in / usr / bin work?
  • Arch es compatible con multilib. El repositorio de Multilib está habilitado en /etc/pacman.conf. Todas las dependencias del paquete wine están instaladas. Sin embargo, reinstalándolos solo para asegurarse …
  • ¿Está /lib/ld-linux.so.2 presente en su sistema? Todos los síntomas apuntan a que falta, solo verifique.
  • @ n.m. Sí, tenías razón. De hecho, faltaba todo el directorio /lib 🙂
  • Experiencia;) cuando intentas ejecutar un ejecutable y obtienes un » archivo no encontrado » error mientras que el archivo está obviamente aquí, ‘ falta el intérprete. Su comando file muestra qué intérprete está configurado para este ejecutable.

Respuesta

Esto:

$ 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 con esto:

$ ldd /usr/bin/wine /usr/bin/ldd: line 117: /usr/bin/wine: No such file or directory 

Sugiere fuertemente que el sistema no tiene el /lib/ld-linux.so.2 intérprete ELF. Es decir, este sistema de 64 bits no tiene ninguna biblioteca de compatibilidad de 32 bits instalada. Por lo tanto, la respuesta de @ user1334609 es esencialmente correcta.

Comentarios

  • ¿Alguien va a hablar sobre el mensaje de error engañoso?

Respuesta

De acuerdo, estuve ocupado durante las últimas ocho horas para que mi sistema vuelva a funcionar después de que la CPU se apague por sobrecalentamiento Al reiniciar, se hizo evidente que estaba tan estropeado que incluso la consola alternativa de initrd ya no reconocía mi teclado. Es un misterio para mí cómo el sistema logró permanecer operativo durante tanto tiempo, mientras yo intentaba implementar las innumerables sugerencias de ustedes (¡muchas gracias!)

Problema al reiniciar:

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 

y no funciona el teclado después 🙂

El problema era: una actualización reemplazó el enlace simbólico /lib -> /usr/lib con un directorio. Eso significaba que faltaban todas las bibliotecas y módulos del kernel, que se esperaba que estuvieran en /lib 🙂

Así que recreé el enlace simbólico y reinstalé el sistema base desde un CD en vivo.

Ahora que tengo Internet nuevamente, también encontré este hilo

También usé el administrador de paquetes de mi instalación en disco bloqueada (llamada pacman) desde el Live CD para reinstalar todos los paquetes del grupo base ( tal vez solo el kernel, por lo que el paquete linux hubiera sido suficiente, no lo sé)

Para lograr eso, monte la partición principal de la instalación en ladrillo en el directorio /mnt del sistema de CD en vivo y use chroot para hacer pacman pensar /mnt es / (inserte la partición principal de su sistema de ladrillos 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 el registro: cree un enlace simbólico relativo, por lo que ln -s usr/lib /mnt/lib y no ln -s /usr/lib /mnt/lib, porque durante el inicio temprano del sistema (etapa initrd), la partición principal se montará primero a /new_root.Si el enlace simbólico fuera absoluto, obtendría el error mencionado anteriormente durante el arranque temprano.

Comentarios

  • Pequeña pista: cuando utilizo systemrescuecd, a menudo solo repito sobre proc / sys / dev (para la ruta en proc sys dev; do mount -obind / $ ruta / mnt / $ ruta; hecho) antes de hacer el chroot. Sin embargo, si ‘ está usando arch install iso, será mucho más fácil ejecutar el ejecutable arch-chroot provisto, ya que lo hace todo por usted. Está en el paquete arch-install-scripts si alguien quiere hurgar. 🙂

Respuesta

Está intentando ejecutar una aplicación de 32 bits en un sistema operativo de 64 bits, así que necesita instalar bibliotecas de compatibilidad de 32 bits (glibc en particular) antes de que esto funcione.

Comentarios

  • Aclare cómo su solución resuelve el caso y responda la pregunta
  • Lo que dijo Romeo; ¿Ejecutaría apt-get en un sistema arch-linux, en lugar de pacman? ¿Y cómo les ayudarían las bibliotecas de compresión y ncurses?

Respuesta

Para su información, me encontré con el mismo problema al ejecutar en una imagen de Docker basada en los Alpes. El ejecutable era un ELF de 64 bits, la imagen alpina era de 64 bits y el ejecutable funcionaba en un contenedor diferente. Entonces, presumiblemente, las bibliotecas alpinas recortadas no eran compatibles con mi ejecutable. La node.js Docker hub page señala:

La advertencia principal [para ejecutarse en el contenedor basado en Alpine] es que usa musl libc en lugar de glibc y amigos , por lo que cierto software puede tener problemas dependiendo de la profundidad de sus requisitos de libc. Sin embargo, la mayoría del software no tiene problemas con esto, por lo que esta variante suele ser una opción muy segura. Consulte este hilo de comentarios sobre Hacker News para obtener más información sobre el problemas que puedan surgir y algunas comparaciones a favor y en contra del uso de imágenes basadas en Alpine.

Mi solución fue usar una diferente (por ejemplo, basada en Debian Jessie) imagen del contenedor.

Comentarios

  • Gracias por conectar este problema original del administrador de sistemas al » nuevo » ¡mundo de contenedores!

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *