Szeretném elindítani a wine futtatható fájlt (2.12-es verzió), de a következő hibát kapom ($ = 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 A fájl azonban ott van:
$ which wine /usr/bin/wine A futtatható fájl biztosan ott van, és nincs holt 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: - Ez egy 32 bites 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 Meg tudom szerezni a futtatható fájl dinamikus szakaszát:
$ 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] Nem tudom azonban felsorolni a megosztott objektum-függőségeket a :
$ ldd /usr/bin/wine /usr/bin/ldd: line 117: /usr/bin/wine: No such file or directory strace megmutatja:
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 +++ Szerkesztette @jww javaslat hozzáadásához könyvtárak kérés, mert nem jön létre ld hibakereső üzenet:
$ LD_DEBUG=all wine bash: /usr/bin/wine: No such file or directory Még akkor is, ha csak a LD_DEBUG, a hiba helyette fordul elő
$ LD_DEBUG=help wine bash: /usr/bin/wine: No such file or directory Hozzáadva szerkesztve @Raman Sailopal javaslata: Úgy tűnik, hogy a probléma a futtatható fájlban rejlik, mivel a /usr/bin/wine tartalmának másolása már létrehozott fájlba ugyanaz a hiba
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 Mi a probléma, vagy mit tehetek, hogy kiderítsem, melyik fájl vagy könyvtár hiányzik?
uname -a:
Linux laptop 4.11.3-1-ARCH #1 SMP PREEMPT Sun May 28 10:40:17 CEST 2017 x86_64 GNU/Linux Megjegyzések
Válasz
Ez:
$ 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 Ezzel együtt:
$ ldd /usr/bin/wine /usr/bin/ldd: line 117: /usr/bin/wine: No such file or directory Erősen javasolja hogy a rendszer nem rendelkezik az /lib/ld-linux.so.2 ELF tolmácsával. Vagyis ebben a 64 bites rendszerben nincsenek telepítve 32 bites kompatibilitási könyvtárak. Így a @ user1334609 válasza lényegében helyes.
Megjegyzések
- Beszélni fog valaki a megtévesztő hibaüzenetről?
Válasz
OK, az elmúlt nyolc órában elfoglalt voltam, hogy a rendszerem újra működésbe lépjen a CPU túlmelegedésének leállítása után Újraindításkor nyilvánvalóvá vált, hogy annyira el van csavarva, hogy még az initrd visszaeső konzolja sem ismerte fel a billentyűzetemet. Rejtély számomra, hogy a rendszernek hogyan sikerült ilyen sokáig működőképesnek maradnia, miközben megpróbáltam végrehajtani a számtalan javaslatot (köszönöm szépen !!)
Probléma az újraindításkor:
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 és utána nem működik billentyűzet 🙂
A probléma az volt: Egy frissítés lecserélte a symlink /lib -> /usr/lib könyvtárral. Tehát ez azt jelentette, hogy minden könyvtár és kernelmodul, amelyek várhatóan /lib fájlban lesznek, hiányoztak 🙂
Tehát újrateremtettem a symlinket, és újratelepítettem az alaprendszert egy élő CD.
Most, hogy újra van internetem, találtam ezt a szálat
A csomagom kezelőjét is használtam kiosztott lemezes telepítés (az úgynevezett pacman) az élő CD-ről a alapcsoport összes csomagjának újratelepítéséhez ( lehet, hogy csak a kernel, így a linux csomag elég lett volna, nem tudom)
Ennek megvalósításához csatolja a téglafalú telepítés fő partícióját a az élő CD-rendszer /mnt könyvtárát, és a chroot segítségével pacman gondolkodni tud /mnt / (illessze be a téglázott rendszer fő partícióját a sdXXX fájlba)
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 A rekord számára: hozzon létre egy relatív szimlinket, tehát ln -s usr/lib /mnt/lib és nem ln -s /usr/lib /mnt/lib, mert a rendszer korai indításakor (initrd szakasz) a fő partíciót telepítik először a /new_root címre.Ha a symlink abszolút lenne, akkor a korai indításkor a fent említett hibát kapná.
Megjegyzések
- Kis tipp: A systemrescuecd használatakor gyakran csak a proc / sys / dev-et ismétlem (a proc sys dev elérési útján; do mount -obind / $ path / mnt / $ path; kész), mielőtt elvégezné a chroot-t. Ha azonban ‘ az arch telepíti az iso-t, sokkal könnyebb futtatni a mellékelt arch-chroot futtatható fájlt, mivel az mindent megtesz az Ön számára. Az arch-install-scripts csomagban van, ha valaki piszkálni akar. 🙂
Válasz
32 bites alkalmazást próbál futtatni 64 bites operációs rendszeren, ezért telepítéséhez 32 bites kompatibilitási könyvtárakat kell telepítenie (különösen a glibc-t).
Megjegyzések
- Kérjük, tisztázza, hogy megoldása hogyan oldja meg az esetet és válaszoljon a kérdésre
- amit Rómeó mondott; az apt-get futtatná egy arch-linux rendszeren, pacman helyett? És hogyan segítenék őket a tömörítési könyvtárak és az ncursek?
Válasz
FYI, futottam ugyanezen problémán futva alpesi alapú dokkoló képen. A futtatható fájl 64 bites ELF, az alpesi kép pedig 64 bites volt, és a futtatható fájl más tárolóban működött. Tehát feltehetően a kivágott alpesi könyvtárak nem voltak kompatibilisek a futtatható fájlommal. A node.js Docker hub oldal megjegyzi:
A fő figyelmeztetés [az Alpine-alapú tárolóban való futtatáshoz] az, hogy a musl libc -et használja a glibc és ismerősei , így bizonyos szoftverek problémákba ütközhetnek a libc követelményeik mélységétől függően. A legtöbb szoftvernek azonban ezzel nincs problémája, ezért ez a változat általában nagyon biztonságos választás. A további részletekért lásd: ezt a Hacker News megjegyzésszálat . felmerülő problémák és az alpesi alapú képek használatának néhány pro / con összehasonlítása.
Megoldásom egy másik (pl. Debian Jessie-alapú) használata volt tároló kép.
Megjegyzések
- Köszönjük, hogy összekapcsolta ezt az eredetileg a sysadmin problémát a ” új ” konténerek világa!
/etc/pacman.conffájlban. Awinecsomag összes függősége telepítve van. Azonban újratelepítés csak annak érdekében, hogy megbizonyosodjon arról, hogy …/lib/ld-linux.so.2a rendszerén? Minden tünet arra utal, hogy hiányzik, csak ellenőrizni kell./libkönyvtár hiányzott 🙂fileparancs megmutatja, hogy milyen tolmács van beállítva ehhez a futtatható fájlhoz.