파일이 있고 경로에 있지만 "파일을 찾을 수 없음"으로 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.