Quiero iniciar el wine
ejecutable (Versión 2.12), pero aparece el siguiente error ( $
= solicitud 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 sugerencias por @jww : El problema parece suceder antes de solicitar bibliotecas vinculadas dinámicamente, porque no ld
se generan mensajes de depuración:
$ LD_DEBUG=all wine
bash: /usr/bin/wine: No such file or directory
Incluso cuando solo imprime los valores posibles de LD_DEBUG
, el error ocurre en su lugar
$ LD_DEBUG=help wine
bash: /usr/bin/wine: No such file or directory
Editado para agregar una sugerencia de @Raman Sailopal: el problema parece estar dentro del ejecutable, ya que copiar el contenido de /usr/bin/wine
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
fuente
/etc/pacman.conf
. Todas las dependencias delwine
paquete están instaladas. Sin embargo, reinstalarlos solo para asegurarse .../lib/ld-linux.so.2
presente en su sistema? Todos los síntomas indican que falta, solo la verificación./lib
faltaba todo el directorio :-)file
comando muestra qué intérprete está configurado para este ejecutable.Respuestas:
Esta:
Combinado con esto:
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.fuente
OK, estuve ocupado durante las últimas ocho horas para volver a poner en funcionamiento mi sistema después de que la CPU se sobrecalentara. Al reiniciar se hizo evidente que estaba tan jodido que incluso la consola de respaldo de initrd ya no reconocía mi teclado. Para mí es un misterio cómo el sistema logró mantenerse operativo durante tanto tiempo, mientras intentaba implementar las innumerables sugerencias que hizo (¡muchas gracias!)
Problema al reiniciar:
y ningún teclado funciona después :-)
El problema era: una actualización reemplazó el enlace simbólico
/lib -> /usr/lib
con un directorio. Eso significaba que/lib
faltaban todas las bibliotecas y módulos del núcleo, que se espera que estén en :-)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 utilicé el administrador de paquetes de mi instalación en disco bloqueada (llamada
pacman
) desde el CD en vivo para reinstalar todos los paquetes del grupo base (tal vez solo el núcleo, por lo que el paquetelinux
habría sido suficiente, no lo sé)Para lograr eso, montar la partición principal de la instalación ladrillera al
/mnt
directorio del sistema de CD en vivo y el usochroot
para hacerpacman
pensar/mnt
es/
(insertar partición principal de su sistema de ladrillerasdXXX
)Para el registro: cree un enlace simbólico relativo, así
ln -s usr/lib /mnt/lib
y noln -s /usr/lib /mnt/lib
, porque durante el arranque inicial del sistema (etapa initrd), la partición principal se montará primero/new_root
. Si el enlace simbólico fuera absoluto, obtendría el error mencionado anteriormente durante el arranque temprano.fuente
Está intentando ejecutar una aplicación de 32 bits en un sistema operativo de 64 bits, por lo que necesita instalar bibliotecas de compatibilidad de 32 bits (glibc en particular) antes de que esto pueda funcionar.
fuente
Para su información, me encontré con este mismo problema que se ejecuta en una imagen acoplable alpina. El ejecutable era un ELF de 64 bits, y 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. Las notas de la página del concentrador de Docker de node.js :
Mi solución fue utilizar una imagen de contenedor diferente (por ejemplo, basada en Debian Jessie).
fuente