Chcę uruchomić plik wykonywalny wine (wersja 2.12), ale pojawia się następujący błąd ($ = zachęta 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 Jednak plik tam jest:
$ which wine /usr/bin/wine Plik wykonywalny na pewno istnieje i nie ma martwego łącza 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: - To jest 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ć dynamiczną sekcję 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] Jednak nie mogę wyświetlić zależności obiektów współdzielonych za pomocą ldd:
$ ldd /usr/bin/wine /usr/bin/ldd: line 117: /usr/bin/wine: No such file or directory strace pokazuje:
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 +++ Zmieniono w celu dodania sugestii przez @jww : problem wydaje się występować przed dynamicznym połączeniem biblioteki są żądane, ponieważ nie są generowane ld komunikaty debugowania:
$ LD_DEBUG=all wine bash: /usr/bin/wine: No such file or directory Nawet w przypadku drukowania tylko możliwych wartości LD_DEBUG, zamiast tego pojawia się błąd
$ LD_DEBUG=help wine bash: /usr/bin/wine: No such file or directory Edytowano, aby dodać sugestia @Raman Sailopal: Wydaje się, że problem leży w pliku wykonywalnym, ponieważ skopiowanie zawartości /usr/bin/wine do innego już utworzonego pliku daje 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 pliku lub katalogu brakuje?
uname -a:
Linux laptop 4.11.3-1-ARCH #1 SMP PREEMPT Sun May 28 10:40:17 CEST 2017 x86_64 GNU/Linux Komentarze
Odpowiedź
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 interpretera ELF /lib/ld-linux.so.2. Oznacza to, że ten 64-bitowy system nie ma zainstalowanych żadnych 32-bitowych bibliotek zgodności. Zatem odpowiedź @ user1334609 jest zasadniczo poprawna.
Komentarze
- Czy ktoś będzie mówił o wprowadzającym w błąd komunikacie o błędzie?
Odpowiedź
OK, byłem zajęty przez ostatnie osiem godzin, aby ponownie uruchomić system po wyłączeniu z powodu przegrzania procesora Po restarcie okazało się, że jest tak spieprzony, że nawet awaryjna konsola initrd nie rozpoznaje już mojej klawiatury. Jest dla mnie tajemnicą, jak system działał przez tak długi czas, kiedy próbowałem wdrożyć niezliczone sugestie przez Ciebie (bardzo dziękuję !!)
Problem z ponownym uruchomieniem:
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 klawiatura nie działała później 🙂
Problem był następujący: aktualizacja zastąpiła dowiązanie symboliczne /lib -> /usr/lib z katalogiem. Oznacza to, że brakowało wszystkich bibliotek i modułów jądra, które powinny znajdować się w /lib 🙂
Więc odtworzyłem dowiązanie symboliczne i ponownie zainstalowałem system podstawowy z Live CD.
Teraz, gdy mam ponownie Internet, znalazłem również ten wątek
Użyłem również menedżera pakietów mojego zamurowana instalacja na dysku (o nazwie pacman) z Live CD w celu ponownej instalacji wszystkich pakietów grupy podstawowej ( może tylko jądro, więc pakiet linux wystarczyłby, nie wiem)
Aby to zrobić, zamontuj główną partycję zamurowanej instalacji na katalogu /mnt systemu Live CD i użyj chroot, aby pacman myśleć /mnt to / (wstaw główną partycję swojego systemu zamurowanego dla 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 zapisu: utwórz względne łącze symboliczne, więc ln -s usr/lib /mnt/lib, a nie ln -s /usr/lib /mnt/lib, ponieważ podczas wczesnego startu systemu (etap initrd) główna partycja zostanie zamontowana jako pierwsza do /new_root.Gdyby dowiązanie symboliczne było bezwzględne, wystąpiłby wspomniany powyżej błąd podczas wczesnego rozruchu.
Komentarze
- Mała wskazówka: Używając systemrescuecd, często po prostu iteruję po proc / sys / dev (dla ścieżki w proc sys dev; do mount -obind / $ path / mnt / $ path; done) przed wykonaniem chroot. Jeśli jednak ' używasz arch install iso, o wiele łatwiej jest po prostu uruchomić dostarczony plik wykonywalny arch-chroot, ponieważ robi wszystko za ciebie. Jest w pakiecie arch-install-scripts, jeśli ktoś chce się w nim pogrzebać. 🙂
Odpowiedź
Próbujesz uruchomić aplikację 32-bitową w 64-bitowym systemie operacyjnym, więc musisz zainstalować 32-bitowe biblioteki kompatybilności (w szczególności glibc), zanim to zadziała.
Komentarze
- Wyjaśnij, w jaki sposób Twoje rozwiązanie rozwiązuje sprawę i odpowiedz na pytanie
- Co powiedział Romeo; uruchomiłbyś apt-get w systemie arch-linux zamiast pacmana? I w jaki sposób biblioteki kompresji i ncurses pomogłyby im?
Odpowiedź
Do Twojej wiadomości, napotkałem ten sam problem podczas uruchamiania w obrazie dockera opartym na Alpach. Plik wykonywalny był 64-bitowym ELF, a obraz alpejski był 64-bitowy, a plik wykonywalny działał w innym kontenerze. Więc przypuszczalnie przycięte biblioteki alpejskie nie były zgodne z moim plikiem wykonywalnym. Uwagi node.js Docker hub :
Główne zastrzeżenie [do uruchamiania w kontenerze opartym na Alpach] polega na tym, że używa musl libc zamiast glibc i przyjaciele , więc niektóre programy mogą napotykać problemy w zależności od poziomu wymagań libc. Jednak większość programów nie ma z tym problemu, więc ten wariant jest zwykle bardzo bezpiecznym wyborem. Zobacz ten wątek z komentarzami Hacker News , aby uzyskać więcej informacji na temat problemy, które mogą się pojawić i niektóre porównania za / przeciw używania obrazów z Alpine.
Moim rozwiązaniem było użycie innego (np. opartego na Debianie Jessie) obraz kontenera.
Komentarze
- Dziękujemy za połączenie tego pierwotnego problemu z administratorem systemu z ” nowym ” świat kontenerów!
/etc/pacman.conf. Wszystkie zależności pakietuwinesą zainstalowane. Jednak przeinstalowanie ich tylko po to, aby się upewnić …/lib/ld-linux.so.2jest obecny w twoim systemie? Wszystkie symptomy wskazują na to, że brakuje, wystarczy sprawdzić./lib🙂filepokazuje, jaki interpreter jest ustawiony dla tego pliku wykonywalnego.