Vreau să lansez executabilul wine
(versiunea 2.12), dar primesc următoarea eroare ($
= prompt shell):
$ 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
Cu toate acestea, fișierul este acolo:
$ which wine /usr/bin/wine
Executabilul este cu siguranță acolo și nu există link simbolic mort:
$ 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: -
Este un ELF pe 32 de biți:
$ 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
Pot obține secțiunea dinamică a executabilului:
$ 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]
Cu toate acestea, nu pot lista dependențele obiectelor partajate folosind ldd
:
$ ldd /usr/bin/wine /usr/bin/ldd: line 117: /usr/bin/wine: No such file or directory
strace
arată:
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 +++
Editat pentru a adăuga sugestie de @jww : Problema pare să se întâmple înainte de a fi conectată dinamic biblioteci sunt solicitate, deoarece nu sunt generate ld
mesaje de depanare:
$ LD_DEBUG=all wine bash: /usr/bin/wine: No such file or directory
Chiar și atunci când se imprimă numai valorile posibile ale LD_DEBUG
, eroarea apare în schimb
$ LD_DEBUG=help wine bash: /usr/bin/wine: No such file or directory
Editat pentru a adăuga sugestie a lui @Raman Sailopal: Problema pare să se afle în executabil, deoarece copierea conținutului /usr/bin/wine
într-un alt fișier deja creat produce aceeași eroare
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
Care este problema sau ce pot face pentru a afla ce fișier sau director lipsește?
uname -a
:
Linux laptop 4.11.3-1-ARCH #1 SMP PREEMPT Sun May 28 10:40:17 CEST 2017 x86_64 GNU/Linux
Comentarii
Răspuns
Aceasta:
$ 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
Combinată cu aceasta:
$ ldd /usr/bin/wine /usr/bin/ldd: line 117: /usr/bin/wine: No such file or directory
Sugerează cu tărie că sistemul nu are interpretul /lib/ld-linux.so.2
ELF. Adică, acest sistem pe 64 de biți nu are instalate biblioteci de compatibilitate pe 32 de biți. Astfel, răspunsul lui @ user1334609 este în esență corect.
Comentarii
- Va vorbi cineva despre mesajul de eroare înșelător?
Răspuns
OK, am fost ocupat în ultimele opt ore să-mi pun sistemul în funcțiune din nou după oprirea supraîncălzirii procesorului La repornire a devenit evident că a fost atât de înșelat încât nici consola de rezervă a initrd nu mi-a mai recunoscut tastatura. Este un mister pentru mine cum a reușit sistemul să rămână funcțional atât de mult timp, în timp ce încercam să pun în aplicare nenumăratele sugestii de către dvs. (mulțumesc mult !!)
Problemă la repornire:
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 nu mai funcționează tastatura după aceea 🙂
Problema a fost: o actualizare a înlocuit link-ul simbolic /lib -> /usr/lib
cu un director. Deci asta însemna că toate bibliotecile și modulele kernel, care se așteaptă să fie în /lib
, lipseau 🙂
Așa că am recreat link-ul simbol și am reinstalat sistemul de bază un CD live.
Acum că am din nou internet, am găsit și acest fir
Am folosit și managerul de pachete al meu instalare blocată pe disc (numită pacman
) de pe CD-ul live pentru a reinstala toate pachetele din grupul de bază ( poate doar nucleul, așa că pachetul linux
ar fi fost suficient, nu știu)
Pentru a realiza acest lucru, montați partiția principală a instalației cărămidate la directorul /mnt
al sistemului live CD și utilizați chroot
pentru a face pacman
să gândească /mnt
este /
(introduceți partiția principală a sistemului tăiat pentru 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
Pentru înregistrare: creați o legătură simbolică relativă, deci ln -s usr/lib /mnt/lib
și nu ln -s /usr/lib /mnt/lib
, deoarece în timpul pornirii timpurii a sistemului (etapa initrd) partiția principală va fi montată mai întâi la /new_root
.Dacă legătura simbolică ar fi absolută, veți primi eroarea menționată mai sus în timpul pornirii timpurii.
Comentarii
- Sugestie mică: Când folosesc systemrescuecd, adesea iterez peste proc / sys / dev (pentru calea în proc sys dev; montați -obind / $ path / mnt / $ path; done) înainte de a face chroot. Cu toate acestea, dacă ‘ utilizați iso de instalare a arhivei, este mult mai ușor să rulați executabilul furnizat de arch-chroot, deoarece face totul pentru dvs. Se află în pachetul arch-install-scripts dacă cineva dorește să arunce. 🙂
Răspuns
Încercați să rulați aplicația pe 32 de biți pe un sistem de operare pe 64 de biți, deci trebuie să instalați biblioteci de compatibilitate pe 32 de biți (în special glibc) înainte ca acest lucru să funcționeze.
Comentarii
- Vă rugăm să clarificați modul în care soluția dvs. rezolvă cazul și răspundeți la întrebarea
- Ce a spus Romeo; ai rula apt-get pe un sistem arch-linux, în loc de pacman? Și cum le-ar ajuta bibliotecile de compresie și ncurses?
Răspuns
FYI, am întâlnit aceeași problemă într-o imagine de andocare bazată pe alpină. Executabilul a fost un ELF pe 64 de biți, iar imaginea alpină a fost pe 64 de biți, iar executabilul a funcționat într-un container diferit. Deci, probabil, bibliotecile alpine tăiate nu erau compatibile cu executabilul meu. Pagina node.js Docker hub page notează:
Avertismentul principal [pentru a rula în containerul bazat pe Alpine] este că folosește musl libc în loc de glibc și prieteni , astfel încât anumite programe ar putea avea probleme în funcție de profunzimea cerințelor lor de libc. Cu toate acestea, majoritatea software-urilor nu au nicio problemă cu acest lucru, deci această variantă este de obicei o alegere foarte sigură. Consultați acest fir de comentarii despre Știrile hacker pentru mai multe discuții despre probleme care ar putea apărea și unele comparații pro / contra utilizării imaginilor bazate pe Alpine.
Soluția mea a fost să folosesc altul (de exemplu, bazat pe Debian Jessie) imagine container.
Comentarii
- Vă mulțumim că ați conectat această problemă inițial sysadmin la ” nou ” lumea containerelor!
/etc/pacman.conf
. Sunt instalate toate dependențele pachetuluiwine
. Cu toate acestea, reinstalați-le doar pentru a vă asigura că …/lib/ld-linux.so.2
prezent pe sistemul dvs.? Toate simptomele indică faptul că lipsește, doar verificarea./lib
lipsea 🙂file
arată ce interpret este setat pentru acest executabil.