Dosya yürütülebilir ve PATH içinde olsa bile Linux yürütülebilir dosyası “Dosya bulunamadı” ile başarısız oluyor


20

wineYürütülebilir dosyayı (Sürüm 2.12) başlatmak istiyorum , ancak aşağıdaki hatayı alıyorum ( $= kabuk istemi):

$ 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

Ancak, dosya orada:

$ which wine
/usr/bin/wine

Yürütülebilir kesinlikle orada ve hiçbir ölü symlink:

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

32 bit ELF'dir:

$ 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

Yürütülebilir dosyanın dinamik bölümünü alabilirsiniz:

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

Ancak, paylaşılan nesne bağımlılıkları kullanarak listeleyemiyorum ldd:

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

strace gösterileri:

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

@Jww tarafından öneri eklemek için düzenlendi : Sorun, dinamik olarak bağlı kitaplıklar istenmeden önce gerçekleşiyor gibi görünüyor, çünkü ldhata ayıklama iletileri oluşturulmadı:

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

Yalnızca olası değerlerini yazdırırken bile LD_DEBUG, bunun yerine hata oluşur

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

@Raman Sailopal önerisi eklemek için düzenlendi: Sorun, /usr/bin/winezaten oluşturulmuş başka bir dosyanın içeriğini kopyalamak aynı hatayı oluşturduğundan , yürütülebilir dosyada yatıyor gibi görünüyor

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

Sorun nedir veya hangi dosya veya dizinin eksik olduğunu bulmak için ne yapabilirim?


uname -a:

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

./wine in / usr / bin nasıl çalışır?
Aiden Bell

1
Arch çok kademeli özelliktedir. İçinde çok katmanlı havuz etkinleştirildi /etc/pacman.conf. winePaketin tüm bağımlılıkları kurulur. Ancak, sadece emin olmak için onları yeniden ...
akraf

3
/lib/ld-linux.so.2sisteminizde mevcut? Tüm semptomlar eksik olduğunu gösterir, sadece kontrol eder.
n. 'zamirler' m.

1
@nm Evet, haklıydın. Aslında, tüm dizin /libeksik :-)
akraf

3
Deneyim;) çalıştırılabilir bir dosya çalıştırmaya çalıştığınızda ve dosya açık bir şekilde buradayken "dosya bulunamadı" hatası almaya çalıştığınızda, yorumlayıcı eksiktir. Sizin filene tercüman komut gösterileri bu yürütülebilir için ayarlanır.
n. 'zamirler' m.

Yanıtlar:


12

Bu:

$ 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

Bununla birlikte:

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

Sistemin /lib/ld-linux.so.2ELF yorumlayıcısına sahip olmadığını şiddetle önerir . Yani, bu 64 bit sistemde yüklü 32 bit uyumluluk kitaplığı yoktur. Bu nedenle, @ user1334609'un cevabı aslında doğrudur.


4

Tamam, CPU'nun aşırı ısınmasından sonra sistemimi tekrar açıp çalıştırmak için son sekiz saat boyunca meşguldüm. Yeniden başlatıldığında, initrd'ın geri dönüş konsolunun bile klavyemi artık tanımadığı çok berbat oldu. Benim tarafınızdan sayısız öneri uygulamaya çalışırken, sistemin bu kadar uzun süre nasıl çalışmayı başardığı benim için bir gizem (çok teşekkür ederim!)

Yeniden başlatma sorunu:

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

ve daha sonra hiçbir klavye çalışma :-)

Sorun şuydu: Güncelleştirme, sembolik bağın /lib -> /usr/libyerine bir dizini yerleştirdi. Bu, içinde olması beklenen tüm kütüphanelerin ve çekirdek modüllerinin /libeksik olduğu anlamına geliyordu :-)

Bu yüzden symlink'i yeniden oluşturdum ve temel sistemi canlı bir CD'den yeniden kurdum.

Şimdi tekrar internetim olduğuna göre, bu konuyu da buldum

Ayrıca temel grubunpacman tüm paketlerini yeniden yüklemek için canlı CD'deki tuğlalı disk kurulumumun (çağrılan ) paket yöneticisini kullandım (belki sadece çekirdek, bu yüzden paket yeterli olurdu, bilmiyorum)linux

Bunu başarmak için için tuğla tesisatın ana bölüm bağlama /mntcanlı CD sistemi ve kullanım dizinine chrootyapmak pacmandüşünmek /mntolduğunu /(için tuğlalı sistemin ana bölüm insert 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

Kayıt için: göreceli bir sembolik bağlantı oluşturun, bu yüzden ln -s usr/lib /mnt/libdeğil ln -s /usr/lib /mnt/lib, çünkü erken sistem önyüklemesi sırasında (initrd aşaması) ana bölüm ilk önce monte edilecektir /new_root. Symlink mutlak olursa, erken önyükleme sırasında yukarıda belirtilen hatayı alırsınız.


1
Küçük ipucu: systemrescuecd kullanırken, genellikle chroc yapmadan önce proc / sys / dev üzerinden yineleyin (proc sys dev'deki yol için; mount -obind / $ path / mnt / $ path; done). Ancak arch install iso kullanıyorsanız, sizin için her şeyi yaptığı gibi sağlanan arch-chroot yürütülebilir dosyasını çalıştırmak çok daha kolaydır. Birisi poke yapmak istiyorsa, arch-install-scripts paketinde. :)
zaTricky

4

32 bit uygulamayı 64 bit işletim sisteminde çalıştırmaya çalışıyorsunuz, bu yüzden işe yaramadan önce 32 bit uyumluluk kitaplıkları (özellikle glibc) yüklemeniz gerekiyor.


1
Lütfen çözümünüzün davayı nasıl
çözdüğünü açıklayın

Romeo'nun söyledikleri; Pacman yerine arch-linux sisteminde apt-get çalıştırır mıydınız? Sıkıştırma kütüphaneleri ve hemşireler onlara nasıl yardımcı olur?
Jeff Schaller

1

Bilginize, aynı sorun alpin tabanlı bir docker görüntüde çalışan karşılaştım. Yürütülebilir dosya 64 bit ELF ve dağ görüntüsü 64 bit idi ve yürütülebilir dosya farklı bir kapta çalıştı. Yani muhtemelen kesilmiş dağ kütüphaneleri benim çalıştırılabilir dosya ile uyumlu değildi. Docker hub sayfa node.js notlar:

Ana ihtar [Alp tabanlı kap içinde çalışan] o kullanımının yapmasıdır libc'nin MUSL yerine glibc'nin ve arkadaşları kadar emin yazılım kendi libc gereksinimlerinin derinliğine bağlı sorunlarla karşılaşma. Bununla birlikte, çoğu yazılımın bu konuda bir sorunu yoktur, bu nedenle bu varyant genellikle çok güvenli bir seçimdir. Ortaya çıkabilecek sorunlar ve Alpine tabanlı görüntülerin kullanımıyla ilgili bazı pro / con karşılaştırmaları için bu Hacker News yorum başlığına bakın .

Benim çözümüm farklı (örn. Debian Jessie tabanlı) bir kapsayıcı görüntüsü kullanmaktı.


Başlangıçta bu sysadmin problemini "yeni" konteyner dünyasına bağladığınız için teşekkürler!
akraf
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.