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

  • face ./wine în / usr / bin work?
  • Arch este multilib-capabil. Depozitul Multilib este activat în /etc/pacman.conf. Sunt instalate toate dependențele pachetului wine. Cu toate acestea, reinstalați-le doar pentru a vă asigura că …
  • Este /lib/ld-linux.so.2 prezent pe sistemul dvs.? Toate simptomele indică faptul că lipsește, doar verificarea.
  • @ n.m. Da, ai avut dreptate. De fapt, întregul director /lib lipsea 🙂
  • Experiență;) când încercați să rulați un executabil și să obțineți un ” fișierul nu a fost găsit ” eroare în timp ce fișierul este evident chiar aici, ‘ este interpretul lipsă. Comanda file arată ce interpret este setat pentru acest executabil.

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!

Lasă un răspuns

Adresa ta de email nu va fi publicată. Câmpurile obligatorii sunt marcate cu *