Chcę uruchomić wine
plik 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 ld
są 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/wine
do 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
źródło
/etc/pacman.conf
. Wszystkie zależnościwine
pakietu są zainstalowane. Jednak ich ponowna instalacja, aby się upewnić .../lib/ld-linux.so.2
obecny w twoim systemie? Wszystkie objawy wskazują, że tego brakuje, po prostu sprawdzam./lib
brakowało całego katalogu :-)file
polecenie pokazuje, jaki interpreter jest ustawiony dla tego pliku wykonywalnego.Odpowiedzi:
To:
W połączeniu z tym:
Zdecydowanie sugeruje, że system nie ma
/lib/ld-linux.so.2
interpretera ELF. Oznacza to, że ten 64-bitowy system nie ma zainstalowanych bibliotek kompatybilności 32-bitowej. Dlatego odpowiedź @ user1334609 jest zasadniczo poprawna.źródło
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:
i potem nie działa klawiatura :-)
Problem polegał na tym, że aktualizacja zastąpiła dowiązanie symboliczne
/lib -> /usr/lib
katalogiem. Oznaczało to, że/lib
brakował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 pakietlinux
byłby wystarczający, nie wiem)Aby tego dokonać, należy zamontować główną partycję instalacji murowaną do
/mnt
katalogu live CD i użytkowania systemuchroot
, abypacman
myśleć/mnt
to/
(wkładka głównej partycji Twojego systemu dla murowanesdXXX
)Dla przypomnienia: utwórz względne dowiązanie symboliczne, więc
ln -s usr/lib /mnt/lib
nieln -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.źródło
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.
źródło
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:
Moim rozwiązaniem było użycie innego obrazu kontenera (np. Opartego na Debian Jessie).
źródło