Linux không thể thực thi được với Tập tin không tìm thấy tập tin ngay cả khi tập tin ở đó và trong PATH

Tôi muốn khởi chạy winetệp thực thi (Phiên bản 2.12), nhưng tôi gặp lỗi sau ( $= 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

Tuy nhiên, tập tin là có:

$ which wine
/usr/bin/wine

Việc thực thi chắc chắn là có và không có symlink chết:

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

Nó là ELF 32 bit:

$ 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

Tôi có thể lấy phần động của tệp thực thi:

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

Tuy nhiên, tôi không thể liệt kê các phụ thuộc đối tượng được chia sẻ bằng cách sử dụng ldd:

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

strace trình diễn:

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

Đã chỉnh sửa để thêm đề xuất bởi @jww : Sự cố dường như xảy ra trước khi các thư viện được liên kết động được yêu cầu, vì không có ldthông báo gỡ lỗi nào được tạo:

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

Ngay cả khi chỉ in các giá trị có thể có LD_DEBUG, lỗi vẫn xảy ra

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

Đã chỉnh sửa để thêm đề xuất của @Raman sailopal: Vấn đề dường như nằm trong tệp thực thi, vì sao chép nội dung của /usr/bin/winetệp khác đã được tạo sẽ gây ra lỗi tương tự

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

Vấn đề là gì hoặc tôi có thể làm gì để tìm ra tập tin hoặc thư mục nào bị thiếu?

uname -a:

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

Điều này:

$ 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

Kết hợp với điều này:

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

Rất khuyến nghị rằng hệ thống không có trình /lib/ld-linux.so.2thông dịch ELF. Đó là, hệ thống 64 bit này không có bất kỳ thư viện tương thích 32 bit nào được cài đặt. Do đó, câu trả lời của @ user1334609 về cơ bản là chính xác.

OK, tôi đã bận rộn trong tám giờ qua để hệ thống của tôi hoạt động trở lại sau khi tắt CPU quá nóng. Khi khởi động lại, rõ ràng là nó đã bị hỏng đến mức ngay cả bảng điều khiển dự phòng của initrd cũng không nhận ra bàn phím của tôi nữa. Đó là một bí ẩn đối với tôi làm thế nào hệ thống quản lý để hoạt động lâu như vậy, trong khi tôi đang cố gắng thực hiện vô số lời đề nghị của bạn (cảm ơn bạn rất nhiều !!)

Vấn đề khi khởi động lại:

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

và không có bàn phím nào hoạt động sau đó :-)

Vấn đề là: Một bản cập nhật đã thay thế symlink /lib -> /usr/libbằng một thư mục. Vì vậy, điều đó có nghĩa là tất cả các thư viện và mô-đun hạt nhân, dự kiến ​​sẽ /libbị thiếu :-)

Vì vậy, tôi đã tạo lại symlink và cài đặt lại hệ thống cơ bản từ đĩa CD trực tiếp.

Bây giờ tôi có internet một lần nữa, tôi cũng tìm thấy chủ đề này

Tôi cũng đã sử dụng trình quản lý gói cài đặt trên đĩa (được gọi pacman) của mình từ đĩa CD trực tiếp để cài đặt lại tất cả các gói của nhóm cơ sở (có thể chỉ là kernel, vì vậy gói linuxsẽ là đủ, tôi không biết)

Để thực hiện điều đó, hãy gắn phân vùng chính của cài đặt bricked vào /mntthư mục của hệ thống CD trực tiếp và sử dụng chrootđể pacmansuy nghĩ /mntlà /(chèn phân vùng chính của hệ thống bricked của bạn cho 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

Đối với bản ghi: tạo một liên kết tượng trưng tương đối, ln -s usr/lib /mnt/libvà không ln -s /usr/lib /mnt/lib, bởi vì trong quá trình khởi động hệ thống sớm (giai đoạn khởi đầu), phân vùng chính sẽ được gắn kết đầu tiên /new_root. Symlink sẽ là tuyệt đối, bạn sẽ nhận được lỗi đã đề cập ở trên trong quá trình khởi động sớm.

Bạn đang cố chạy ứng dụng 32 bit trên hệ điều hành 64 bit, vì vậy bạn cần cài đặt thư viện tương thích 32 bit (cụ thể là glibc) trước khi điều này có thể hoạt động.

FYI, tôi gặp vấn đề tương tự khi chạy trong hình ảnh docker dựa trên núi cao. Tệp thực thi là ELF 64 bit và hình ảnh trên núi là 64 bit và tệp thực thi hoạt động trong một thùng chứa khác. Vì vậy, có lẽ các thư viện trên núi cao không tương thích với thực thi của tôi. Các Node.js Docker trang hub ghi chú:

Nhắc nhở chính [để chạy trong container dựa trên Alps] là nó sử dụng libc musl thay vì glibc và bạn bè , vì vậy phần mềm nhất định có thể gặp sự cố tùy thuộc vào độ sâu của yêu cầu libc của họ. Tuy nhiên, hầu hết các phần mềm không có vấn đề gì với điều này, vì vậy biến thể này thường là một lựa chọn rất an toàn. Xem chủ đề bình luận Hacker News này để biết thêm thảo luận về các vấn đề có thể phát sinh và một số so sánh pro / con so với việc sử dụng hình ảnh dựa trên Alps.

Giải pháp của tôi là sử dụng một hình ảnh container khác (ví dụ dựa trên Debian Jessie).