Исполняемый файл Linux завершается с ошибкой «Файл не найден», даже если файл есть и находится в переменной PATH

Я хочу запустить wineисполняемый файл (Версия 2.12), но получаю следующую ошибку ( $= приглашение оболочки):

$ 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

Тем не менее, файл там:

$ which wine
/usr/bin/wine

Исполняемый файл определенно есть, и нет мертвой символической ссылки:

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

Это 32-битный ELF:

$ 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

Я могу получить динамический раздел исполняемого файла:

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

Однако я не могу перечислить зависимости общего объекта, используя ldd:

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

strace шоу:

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 +++

Отредактировано, чтобы добавить предложение от @jww : Проблема, по-видимому, возникает до того, как запрашиваются динамически связанные библиотеки, потому что ldсообщения отладки не генерируются:

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

Даже при печати только возможных значений LD_DEBUG, вместо этого возникает ошибка

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

Отредактировано, чтобы добавить предложение @Raman Sailopal: Кажется, проблема заключается в исполняемом файле, поскольку копирование содержимого /usr/bin/wineв другой уже созданный файл приводит к той же ошибке

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

В чем проблема или что я могу сделать, чтобы узнать, какой файл или каталог отсутствует?

uname -a:

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

Эта:

$ 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

В сочетании с этим:

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

Настоятельно говорит о том, что в системе нет /lib/ld-linux.so.2интерпретатора ELF. То есть в этой 64-битной системе не установлены 32-битные библиотеки совместимости. Таким образом, ответ @ user1334609 по сути правильный.

ОК, последние восемь часов я был занят восстановлением и запуском моей системы после выключения из-за перегрева процессора. При перезагрузке стало очевидно, что это настолько облажалось, что даже запасная консоль initrd больше не распознала мою клавиатуру. Для меня загадка, как системе удавалось так долго работать, пока я пытался воплотить в жизнь ваши бесчисленные предложения (большое спасибо !!)

Проблема при перезагрузке:

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

и после этого клавиатура не работает :-)

Проблема была: Обновление заменило символическую ссылку /lib -> /usr/libна каталог. Это означало, что все библиотеки и модули ядра, которые, как ожидается, будут /libотсутствовать :-)

Поэтому я воссоздал символическую ссылку и переустановил базовую систему с живого CD.

Теперь, когда у меня снова есть Интернет, я также нашел эту тему

Я также использовал менеджер пакетов моей кирпичной установки на диске (называемой pacman) с живого компакт-диска, чтобы переустановить все пакеты базовой группы (возможно, только ядро, поэтому пакета linuxбыло бы достаточно, я не знаю)

Чтобы достичь этого, смонтируйте основной раздел из замурованной установки в /mntкаталог живой системы CD и использование , chrootчтобы pacmanдумать , /mntэто /(вставка основного раздела ваших замуровали систем для 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

Для записи: создайте относительную символическую ссылку, так ln -s usr/lib /mnt/libи нет ln -s /usr/lib /mnt/lib, потому что во время ранней загрузки системы (этап initrd) основной раздел будет смонтирован первым /new_root. Если бы символическая ссылка была абсолютной, вы бы получили вышеупомянутую ошибку при ранней загрузке.

Вы пытаетесь запустить 32-разрядное приложение в 64-разрядной операционной системе, поэтому вам нужно установить 32-разрядные библиотеки совместимости (в частности, glibc), чтобы это работало.

К вашему сведению, я столкнулся с той же проблемой, возникающей в образе докера на альпийской основе. Исполняемый файл представлял собой 64-разрядный файл ELF, а образ Alpine был 64-разрядным, а исполняемый файл работал в другом контейнере. Так что предположительно урезанные альпийские библиотеки не были совместимы с моим исполняемым файлом. Node.js Docker хаб страниц заметок:

Основная оговорка [к запуску в контейнере на основе Alpine] заключается в том, что он использует musl libc вместо glibc и друзей , поэтому некоторые программы могут столкнуться с проблемами в зависимости от глубины их требований к libc. Тем не менее, большинство программ не имеют проблемы с этим, поэтому этот вариант, как правило, очень безопасный выбор. См. Эту ветку комментариев Hacker News для более подробного обсуждения проблем, которые могут возникнуть, и некоторых сравнений за и против использования изображений на основе Alpine.

Мое решение состояло в том, чтобы использовать другое (например, основанное на Debian Jessie) изображение контейнера.