Plik wykonywalny systemu Linux kończy się niepowodzeniem z powodu „Nie znaleziono pliku”, nawet jeśli plik tam jest i w PATH

Chcę uruchomić wineplik wykonywalny (wersja 2.12), ale pojawia się następujący błąd ( $= monit powłoki):

$ 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

Plik jest jednak tam:

$ which wine
/usr/bin/wine

Plik wykonywalny na pewno tam jest i nie ma martwego dowiązania symbolicznego:

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

Jest to 32-bitowy 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

Mogę uzyskać sekcję dynamiczną pliku wykonywalnego:

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

Nie mogę jednak wyświetlić zależności współdzielonych obiektów za pomocą ldd:

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

strace przedstawia:

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

Edytowane w celu dodania sugestii przez @jww : Wydaje się, że problem występuje przed zażądaniem dynamicznie połączonych bibliotek, ponieważ nie ldsą generowane żadne komunikaty debugowania:

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

Nawet gdy drukowane są tylko możliwe wartości LD_DEBUG, zamiast tego pojawia się błąd

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

Edytowane w celu dodania sugestii @Raman Sailopal: Wydaje się, że problem leży w pliku wykonywalnym, ponieważ kopiowanie zawartości /usr/bin/winedo innego już utworzonego pliku powoduje ten sam błąd

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

Na czym polega problem lub co mogę zrobić, aby dowiedzieć się, którego brakuje pliku lub katalogu?

uname -a:

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

To:

$ 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

W połączeniu z tym:

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

Zdecydowanie sugeruje, że system nie ma /lib/ld-linux.so.2interpretera ELF. Oznacza to, że ten 64-bitowy system nie ma zainstalowanych bibliotek kompatybilności 32-bitowej. Dlatego odpowiedź @ user1334609 jest zasadniczo poprawna.

OK, przez ostatnie osiem godzin byłem zajęty, aby ponownie uruchomić system po zamknięciu przegrzania procesora. Po ponownym uruchomieniu okazało się, że jest tak zepsute, że nawet cofnięta konsola initrd nie rozpoznała już mojej klawiatury. Dla mnie tajemnicą jest to, jak system potrafił działać tak długo, gdy próbowałem wdrożyć niezliczone sugestie (dziękuję bardzo !!)

Problem przy ponownym uruchomieniu:

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

i potem nie działa klawiatura :-)

Problem polegał na tym, że aktualizacja zastąpiła dowiązanie symboliczne /lib -> /usr/libkatalogiem. Oznaczało to, że /libbrakowało wszystkich bibliotek i modułów jądra, które powinny się znaleźć :-)

Więc odtworzyłem dowiązanie symboliczne i ponownie zainstalowałem system podstawowy z płyty CD na żywo.

Teraz, gdy znów mam internet, znalazłem ten wątek

Użyłem również menedżera pakietów mojej murowanej instalacji na dysku (wywołanej pacman) z Live CD, aby ponownie zainstalować wszystkie pakiety grupy podstawowej (może tylko jądro, więc pakiet linuxbyłby wystarczający, nie wiem)

Aby tego dokonać, należy zamontować główną partycję instalacji murowaną do /mntkatalogu live CD i użytkowania systemu chroot, aby pacmanmyśleć /mntto /(wkładka głównej partycji Twojego systemu dla murowane 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

Dla przypomnienia: utwórz względne dowiązanie symboliczne, więc ln -s usr/lib /mnt/libnie ln -s /usr/lib /mnt/lib, ponieważ podczas wczesnego uruchamiania systemu (etap initrd) partycja główna zostanie najpierw zamontowana /new_root. Gdyby dowiązanie symboliczne było bezwzględne, dostaniesz wyżej wspomniany błąd podczas wczesnego uruchamiania.

Próbujesz uruchomić 32-bitową aplikację w 64-bitowym systemie operacyjnym, dlatego musisz zainstalować 32-bitowe biblioteki kompatybilności (w szczególności glibc), zanim będzie to możliwe.

Do twojej wiadomości, natknąłem się na ten sam problem na obrazie dokera w alpejskim stylu. Plik wykonywalny był 64-bitowym ELF, a obraz alpejski był 64-bitowy, a plik wykonywalny działał w innym kontenerze. Więc prawdopodobnie przycięte biblioteki alpejskie nie były kompatybilne z moim plikiem wykonywalnym. Node.js dokowane strona piasta notatki:

Głównym zastrzeżeniem [do działania w kontenerze opartym na alpejskim] jest to, że używa musl libc zamiast glibc i znajomych , więc pewne oprogramowanie może napotykać problemy w zależności od głębokości ich wymagań libc. Jednak większość oprogramowania nie ma z tym problemu, więc ten wariant jest zwykle bardzo bezpiecznym wyborem. Zobacz ten wątek z komentarzem Hacker News, aby uzyskać więcej dyskusji na temat problemów, które mogą się pojawić, oraz niektórych porównań zalet i wad korzystania z obrazów na bazie Alpine.

Moim rozwiązaniem było użycie innego obrazu kontenera (np. Opartego na Debian Jessie).