파일이 있고 경로에 있지만 "파일을 찾을 수 없음"으로 Linux 실행 파일이 실패 함


20

wine실행 파일 (버전 2.12) 을 시작하려고 하지만 다음 오류가 발생합니다 ( $= 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

그러나 파일은 다음과 같습니다.

$ 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 비트 ELF입니다.

$ 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

/ usr / bin에서 ./wine이 작동합니까?
— 에이든 벨

1
아치는 다중 라이브러리 가능합니다. 에서 Multilib 저장소가 활성화되었습니다 /etc/pacman.conf. wine패키지 의 모든 종속성 이 설치되었습니다. 그러나, 그냥 확인하기 위해 다시 설치 ...
— akraf

3
가 /lib/ld-linux.so.2시스템에 존재? 모든 증상은 검사 중 누락되었음을 나타냅니다.
— n. '대명사'm.

1
@nm 네, 맞습니다. 실제로, 전체 디렉토리 /lib가 누락되었습니다 :-)
— akraf

3
Experience;) 파일이 여기에있는 동안 실행 파일을 실행하려고하면 "파일을 찾을 수 없음"오류가 발생하면 인터프리터가 누락 된 것입니다. 당신의 file어떤 인터프리터 명령 프로그램이 실행 설정됩니다.
— n. '대명사'm.

답변:


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

CPU가 과열 된 후 시스템을 다시 가동시키기 위해 지난 8 시간 동안 바빴습니다. 재부팅시 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이 누락 될 것으로 예상됩니다 :-)

그래서 심볼릭 링크를 다시 만들고 라이브 CD에서 기본 시스템을 다시 설치했습니다.

인터넷이 다시 연결 되었으므로이 스레드 도 찾았습니다.

또한 기본pacman CD의 모든 패키지를 다시 설치하기 위해 라이브 CD에서 벽돌로 된 온 디스크 설치 ( ) 의 패키지 관리자를 사용했습니다 ( 커널 만 가능하므로 패키지 는 충분했을 것입니다)linux

이 작업을 수행하려면에 벽돌로 설치의 기본 파티션을 마운트 /mnt라이브 CD 시스템 및 사용의 디렉토리를 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. 심볼릭 링크가 절대적이라면 초기 부팅 중에 위에서 언급 한 오류가 발생합니다.


1
작은 힌트 : systemrescuecd를 사용할 때 chroot를 수행하기 전에 종종 proc / sys / dev (proc sys dev의 경로; mount -obind / $ path / mnt / $ path; done)를 반복합니다. 그러나 아치 설치 iso를 사용하는 경우 제공된 arch-chroot 실행 파일을 실행하는 것이 훨씬 쉽습니다. 누군가가 찌르기를 원한다면 arch-install-scripts 패키지에 있습니다. :)
— zaTricky

4

64 비트 운영 체제에서 32 비트 응용 프로그램을 실행하려고하므로 32 비트 호환 라이브러리 (특히 glibc)를 설치해야 작동합니다.


1
솔루션이 사례를 해결하는 방법을 명확히하고 질문에 답변하십시오
— Romeo Ninov

로미오가 말한 것; pacman 대신 arch-linux 시스템에서 apt-get을 실행 하시겠습니까? 압축 라이브러리와 ncurses가 어떻게 도움이됩니까?
— Jeff Schaller

1

참고로, 알파인 기반 도커 이미지에서 실행되는 동일한 문제가 발생했습니다. 실행 파일은 64 비트 ELF이고 알파인 이미지는 64 비트이며 실행 파일은 다른 컨테이너에서 작동했습니다. 아마도 잘린 알파인 라이브러리는 내 실행 파일과 호환되지 않았을 것입니다. 은 도커 허브 페이지 Node.js를 노트 :

Alpine 기반 컨테이너에서 실행 하는 주된주의 사항 은 glibc 및 friends 대신 musl libc 를 사용 하므로 libc 요구 사항의 깊이에 따라 특정 소프트웨어에 문제가 발생할 수 있다는 것입니다. 그러나 대부분의 소프트웨어에는이 문제가 없으므로이 변형은 일반적으로 매우 안전한 선택입니다. 발생할 수있는 문제와 알파인 기반 이미지 사용에 대한 몇 가지 장단점 비교에 대한 자세한 내용은 이 해커 뉴스 주석 스레드 를 참조하십시오 .

내 솔루션은 다른 (예 : 데비안 Jessie 기반) 컨테이너 이미지를 사용하는 것이 었습니다.


원래의 sysadmin 문제를 "새로운"컨테이너 세계에 연결해 주셔서 감사합니다!
— akraf
당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.