Виконаний файл 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відсутні :-)

Тому я відтворив симпосилання та встановив базову систему з живого компакт-диска.

Тепер, коли у мене знову є Інтернет, я також знайшов цю тему

Я також використовував диспетчер пакунків моєї встановленої на цегляному диску диска (викликається 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), перш ніж це зможе працювати.

FYI, я зіткнувся з цим самим випуском, працюючи в докерському образі на альпійській основі. Виконаний файл був 64-розрядним ELF, а альпійське зображення - 64-бітним, а виконуваний файл працював в іншому контейнері. Тож імовірно, оброблені альпійські бібліотеки не сумісні з моїм виконуваним файлом. Сторінка концентратора Docker node.js відзначає:

Основний застереження [для запуску в контейнері на альпійській мові] полягає в тому, що він використовує musl libc замість glibc та друзів , тому певне програмне забезпечення може зіткнутися з проблемами залежно від глибини їхніх вимог до libc. Однак у більшості програмного забезпечення це не виникає, тому такий варіант зазвичай є дуже безпечним вибором. Дивіться цей коментарний потік новин Hacker News для більшого обговорення проблем, які можуть виникнути, а також деякі порівняльні можливості використання зображень на альпійській основі.

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