लिनक्स निष्पादन योग्य "फ़ाइल नहीं मिली" के साथ विफल रहता है, भले ही फ़ाइल वहाँ हो और पाथ में हो

20

मैं wineनिष्पादन योग्य (संस्करण 2.12) लॉन्च करना चाहता हूं , लेकिन मुझे निम्न त्रुटि ( $= शेल प्रॉम्प्ट) मिलती है :

$ 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

हालाँकि, फ़ाइल वहाँ है:

$ which wine
/usr/bin/wine

निष्पादन योग्य निश्चित रूप से है और कोई मृत सिम्कलिन नहीं है:

$ 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-बिट ईएलएफ है:

$ 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

मुझे निष्पादन योग्य का गतिशील खंड मिल सकता है:

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

हालाँकि, मैं साझा ऑब्जेक्ट निर्भरता सूची का उपयोग नहीं कर सकता ldd:

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

strace दिखाता है:

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 द्वारा सुझाव जोड़ने के लिए संपादित : समस्या गतिशील रूप से जुड़े पुस्तकालयों से अनुरोध करने से पहले होती है, क्योंकि कोई ldडीबग संदेश सेट नहीं हैं:

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

यहां तक कि जब केवल संभव मूल्यों को प्रिंट करते हैं LD_DEBUG, तो इसके बजाय त्रुटि होती है

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

@ रामनपाल के सुझाव को संपादित करने के लिए संपादित: समस्या निष्पादन योग्य के भीतर झूठ लगती है, क्योंकि /usr/bin/wineपहले से ही बनाई गई फ़ाइल की सामग्री को कॉपी करने से एक ही त्रुटि उत्पन्न होती है

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

क्या समस्या है या मैं यह पता लगाने के लिए क्या कर सकता हूं कि कौन सी फ़ाइल या निर्देशिका गायब है?

uname -a:

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

— akraf
स्रोत

करता है / .wine में / usr / बिन काम?

— एल्डन बेल

1

आर्क बहु-सक्षम है। मल्टीबिल रिपोजिटरी में सक्षम है /etc/pacman.conf। wineपैकेज की सभी निर्भरताएं स्थापित की जाती हैं। हालाँकि, उन्हें पुन: स्थापित करने के लिए सुनिश्चित करें ...

— akraf

3

है /lib/ld-linux.so.2आपके सिस्टम पर मौजूद? सभी लक्षण गायब होने की ओर इशारा करते हैं, बस जाँच कर रहे हैं।

— एन। 'सर्वनाम' मी।

1

@ एसएम हां, आप सही थे। वास्तव में, पूरी निर्देशिका /libगायब थी :-)

— akraf

3

अनुभव;) जब आप एक निष्पादन योग्य चलाने की कोशिश करते हैं और एक "फ़ाइल नहीं मिली" त्रुटि प्राप्त करते हैं, जबकि फ़ाइल स्पष्ट रूप से यहीं है, यह दुभाषिया लापता है। आपका fileआदेश दिखाता है कि इस निष्पादन योग्य के लिए दुभाषिया क्या निर्धारित है।

— एन। 'सर्वनाम' मी।

12

इस:

$ 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

इसके साथ संयुक्त:

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

दृढ़ता से पता चलता है कि सिस्टम में /lib/ld-linux.so.2ELF दुभाषिया नहीं है । यही है, इस 64-बिट सिस्टम में कोई 32-बिट संगतता लाइब्रेरी स्थापित नहीं है। इस प्रकार, @ user1334609 का उत्तर अनिवार्य रूप से सही है।

— फ्लोरियन वीमर
स्रोत

4

ठीक है, मैं अपने सिस्टम को चालू करने और सीपीयू के बंद होने के बाद फिर से चलने के लिए पिछले आठ घंटों से व्यस्त था। रिबूट पर यह स्पष्ट हो गया कि यह इतना खराब हो गया था कि initrd के फॉल-बैक कंसोल ने भी मेरे कीबोर्ड को नहीं पहचाना। यह मेरे लिए एक रहस्य है कि सिस्टम इतने लंबे समय तक कैसे संचालित होने में कामयाब रहा, जबकि मैं आपके द्वारा अनगिनत सुझावों को लागू करने की कोशिश कर रहा था (आपको बहुत धन्यवाद !!)

रिबूट पर समस्या:

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

और कोई कीबोर्ड काम नहीं कर रहा है :-)

समस्या यह थी: एक अद्यतन ने सिम्लिंक /lib -> /usr/libको एक निर्देशिका से बदल दिया । तो इसका मतलब है कि सभी पुस्तकालयों और कर्नेल मॉड्यूल, जिनके /libगायब होने की उम्मीद है :-)

इसलिए मैंने सिमिंक को फिर से बनाया और एक लाइव सीडी से बेस सिस्टम को फिर से इंस्टॉल किया।

अब जब मेरे पास फिर से इंटरनेट है, तो मुझे यह धागा भी मिला

मैंने आधार समूह केpacman सभी पैकेजों को पुन: स्थापित करने के लिए लाइव सीडी से मेरे ईंट-ऑन इंस्टॉलेशन (कॉल ) के पैकेज मैनेजर का उपयोग किया (शायद केवल कर्नेल, इसलिए पैकेज पर्याप्त होगा, मुझे नहीं पता)linux

कि पूरा करने के लिए ईंटों से बने स्थापना का मुख्य विभाजन माउंट /mntलाइव सीडी प्रणाली और उपयोग की निर्देशिका chrootबनाने के लिए pacmanलगता है /mntहै /(अपने ईंटों से बने सिस्टम के लिए मुख्य विभाजन डालने 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

रिकॉर्ड के लिए: एक रिश्तेदार सिमलिंक बनाएं, ताकि ln -s usr/lib /mnt/libऔर न हो ln -s /usr/lib /mnt/lib, क्योंकि प्रारंभिक सिस्टम बूट (initrd स्टेज) के दौरान मुख्य विभाजन को माउंट किया जाएगा /new_root। क्या सिम्लिंक निरपेक्ष होगा, आपको शुरुआती बूट के दौरान उपर्युक्त त्रुटि मिलेगी।

— akraf
स्रोत

1

छोटा संकेत: जब सिस्टमरेस्क्यूकड का उपयोग कर रहा है, तो मैं अक्सर बस / sys / dev पर खरीद के लिए पुनरावृति करता हूं (रास्ते में proc sys देव के लिए, माउंट-गोबिंद / $ पथ / mnt / $ पथ; किया) chroot करने से पहले। हालाँकि, यदि आप आर्क इनस्टॉल का उपयोग कर रहे हैं, तो बहुत आसान है बस दिए गए आर्क-चेरोट को निष्पादन योग्य चलाना क्योंकि यह आपके लिए सब कुछ करता है। अगर कोई इधर-उधर ताकना चाहता है, तो आर्क-इंस्‍टॉल-स्क्रिप्ट पैकेज में। :)

— zaTricky

4

आप 64 बिट ऑपरेटिंग सिस्टम पर 32-बिट एप्लिकेशन को चलाने का प्रयास कर रहे हैं, इसलिए आपको काम करने से पहले 32-बिट संगतता लाइब्रेरी (विशेष रूप से ग्लिबक) को स्थापित करने की आवश्यकता है।

— user1334609
स्रोत

1

कृपया स्पष्ट करें कि आपका समाधान मामले को कैसे हल करता है और सवाल का जवाब देता है

— रोमियो निनोव

रोमियो ने क्या कहा; आप aac-lin पाक्समैन के बजाय एक आर्क-लाइनक्स सिस्टम पर चलेंगे? और पुस्तकालय और ncurses उन्हें कैसे मदद करेंगे?

— जेफ स्कालर

1

FYI करें, मैं एक अल्पाइन-आधारित डॉकटर छवि में चल रहे इसी मुद्दे में भाग गया। निष्पादन योग्य एक 64-बिट ईएलएफ था, और अल्पाइन छवि 64-बिट थी, और निष्पादन योग्य एक अलग कंटेनर में काम करता था। इसलिए संभवतः ट्रिम की गई अल्पाइन लाइब्रेरी मेरे निष्पादन योग्य नहीं थीं। Node.js डोकर हब पृष्ठ नोट:

मुख्य चेतावनी [अल्पाइन-आधारित कंटेनर में चलने के लिए] यह है कि यह glibc और दोस्तों के बजाय musl libc का उपयोग करता है , इसलिए कुछ सॉफ्टवेयर उनके libc आवश्यकताओं की गहराई के आधार पर मुद्दों में चल सकते हैं। हालाँकि, अधिकांश सॉफ़्टवेयर में यह समस्या नहीं होती है, इसलिए यह संस्करण आमतौर पर एक बहुत ही सुरक्षित विकल्प होता है। देखें इस हैकर समाचार टिप्पणी थ्रेड मुद्दों है कि पैदा हो सकता है और अल्पाइन आधारित छवियों का उपयोग करने के कुछ समर्थक / चोर तुलना की अधिक चर्चा के लिए।

मेरा समाधान एक अलग (जैसे डेबियन जेसी-आधारित) कंटेनर छवि का उपयोग करना था।

— जेफ वार्ड
स्रोत

कंटेनर की "नई" दुनिया में मूल रूप से sysadmin समस्या को जोड़ने के लिए धन्यवाद!

— akraf