ปฏิบัติการ Linux ล้มเหลวด้วย“ ไม่พบไฟล์” แม้ว่าไฟล์จะอยู่ที่นั่นและใน PATH

ฉันต้องการเปิดใช้งานwineexecutable (เวอร์ชั่น 2.12) แต่ฉันได้รับข้อผิดพลาดต่อไปนี้ ( $= shell prompt):

$ 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

ปฏิบัติการที่แน่นอนอยู่ที่นั่นและไม่มี 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: -

มันเป็น ELF 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

แก้ไขเพื่อเพิ่มข้อเสนอแนะของ @Raman Sailopal:ปัญหาดูเหมือนว่าจะอยู่ในความสามารถในการปฏิบัติการเนื่องจากการคัดลอกเนื้อหาของ/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

นี้:

$ 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.2ล่าม ELF นั่นคือระบบ 64- บิตนี้ไม่มีการติดตั้งไลบรารีความเข้ากันได้แบบ 32 บิตใด ๆ ดังนั้นคำตอบของ @ user1334609 นั้นถูกต้อง

ตกลงฉันไม่ว่างในช่วงแปดชั่วโมงที่ผ่านมาเพื่อให้ระบบของฉันทำงานอีกครั้งหลังจาก CPU ปิดเครื่องร้อนเกินไป เมื่อรีบูตมันก็เห็นได้ชัดว่ามันเมามากจนแม้แต่คอนโซลด้านหลังของ 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

และแป้นพิมพ์ไม่ทำงานหลังจากนั้น :-)

ปัญหาคือ: การปรับปรุงแทนที่ symlink /lib -> /usr/libด้วยไดเรกทอรี ดังนั้นนั่นหมายถึงไลบรารีและโมดูลเคอร์เนลทั้งหมดซึ่งคาดว่าจะ/libหายไป :-)

ดังนั้นฉันจึงสร้าง symlink ขึ้นมาใหม่และติดตั้งระบบฐานใหม่จากซีดีสด

ตอนนี้ฉันมีอินเทอร์เน็ตอีกครั้งฉันก็พบกระทู้นี้

ฉันยังใช้ตัวจัดการแพ็กเกจของการติดตั้งบนแผ่นดิสก์ของฉัน (เรียกว่าpacman) จากไลฟ์ซีดีเพื่อติดตั้งแพ็กเกจทั้งหมดของกลุ่มฐาน (อาจเป็นเพียงเคอร์เนลดังนั้นแพ็คเกจlinuxจะเพียงพอแล้วฉันไม่รู้)

เพื่อให้บรรลุผลนั้นให้ติดตั้งพาร์ติชั่นหลักของการติดตั้งแบบ Bricked ไปยังไดเร็กตอรี่/mntของระบบซีดีที่ใช้งานอยู่และใช้chrootเพื่อให้pacmanคิดว่า/mntเป็น/(ใส่พาร์ติชั่นหลักของระบบ Bricked สำหรับ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

สำหรับบันทึก: สร้าง symlink ญาติเพื่อให้ln -s usr/lib /mnt/libและไม่ได้ln -s /usr/lib /mnt/libเพราะในระหว่างการบูตระบบต้น (เวที initrd) /new_rootพาร์ทิชันหลักจะได้รับการติดตั้งครั้งแรกที่ symlink จะเป็นแบบสัมบูรณ์หรือไม่คุณจะได้รับข้อผิดพลาดดังกล่าวข้างต้นในระหว่างการบู๊ตตอนต้น

คุณกำลังพยายามเรียกใช้แอปพลิเคชัน 32 บิตบนระบบปฏิบัติการ 64 บิตดังนั้นคุณต้องติดตั้งไลบรารีความเข้ากันได้แบบ 32 บิต (โดยเฉพาะอย่างยิ่ง glibc) ก่อนจึงจะสามารถทำงานได้

FYI ฉันพบปัญหาเดียวกันนี้ที่ทำงานในอิมเมจของ Docker ที่ใช้อัลไพน์ ไฟล์สั่งการเป็น ELF แบบ 64 บิตและรูปอัลไพน์นั้นเป็นแบบ 64 บิตและไฟล์ที่เรียกทำงานนั้นจะทำงานในคอนเทนเนอร์อื่น ดังนั้นห้องสมุดอัลไพน์ที่ถูกตัดทอนจึงเข้ากันไม่ได้กับปฏิบัติการของฉัน Node.js เทียบท่าหน้าฮับบันทึก:

ข้อแม้หลัก[ไปที่การทำงานในอัลไพน์ที่ใช้ภาชนะ]คือมันใช้musl libcแทนglibc และเพื่อนดังนั้นซอฟต์แวร์บางอย่างอาจพบปัญหาขึ้นอยู่กับความลึกของข้อกำหนด libc ของพวกเขา อย่างไรก็ตามซอฟต์แวร์ส่วนใหญ่ไม่มีปัญหาเกี่ยวกับเรื่องนี้ดังนั้นตัวแปรนี้มักจะเป็นตัวเลือกที่ปลอดภัยมาก ดูที่เธรด Hacker Newsสำหรับการสนทนาเพิ่มเติมเกี่ยวกับปัญหาที่อาจเกิดขึ้นและการเปรียบเทียบแบบมืออาชีพในการใช้ภาพจากอัลไพน์

วิธีแก้ปัญหาของฉันคือการใช้อิมเมจคอนเทนเนอร์อื่น (เช่น Debian Jessie)