Ik wil het wine uitvoerbare bestand (versie 2.12) starten, maar ik krijg de volgende foutmelding ($ = 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 Het bestand is er echter:
$ which wine /usr/bin/wine Het uitvoerbare bestand is er zeker en geen dode 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: - Het is een 32-bit 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 Ik kan de dynamische sectie van het uitvoerbare bestand krijgen:
$ 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] Ik kan de gedeelde objectafhankelijkheden echter niet weergeven met ldd:
$ ldd /usr/bin/wine /usr/bin/ldd: line 117: /usr/bin/wine: No such file or directory strace toont:
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 +++ Bewerkt om suggestie toe te voegen door @jww : het probleem lijkt zich voor te doen voordat dynamisch is gekoppeld bibliotheken worden gevraagd, omdat er geen ld foutopsporingsberichten worden gegenereerd:
$ LD_DEBUG=all wine bash: /usr/bin/wine: No such file or directory Zelfs wanneer alleen de mogelijke waarden van LD_DEBUG, de fout treedt in plaats daarvan op
$ LD_DEBUG=help wine bash: /usr/bin/wine: No such file or directory Bewerkt om toe te voegen suggestie van @Raman Sailopal: Het probleem lijkt te liggen in het uitvoerbare bestand, aangezien het kopiëren van de inhoud van /usr/bin/wine naar een ander reeds gemaakt bestand produceert dezelfde fout
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 Wat is het probleem of wat kan ik doen om erachter te komen welk bestand of welke directory er ontbreekt?
uname -a:
Linux laptop 4.11.3-1-ARCH #1 SMP PREEMPT Sun May 28 10:40:17 CEST 2017 x86_64 GNU/Linux Reacties
Answer
Dit:
$ 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 Gecombineerd met dit:
$ ldd /usr/bin/wine /usr/bin/ldd: line 117: /usr/bin/wine: No such file or directory Sterk aanbevolen dat het systeem de /lib/ld-linux.so.2 ELF-interpreter niet heeft. Dat wil zeggen, op dit 64-bits systeem zijn geen 32-bits compatibiliteitsbibliotheken geïnstalleerd. Het antwoord van @ user1334609 is dus in wezen juist.
Opmerkingen
- Gaat iemand praten over de misleidende foutmelding?
Answer
OK, ik was de afgelopen acht uur bezig om mijn systeem weer aan de praat te krijgen nadat de CPU oververhit was geraakt Bij het opnieuw opstarten werd het duidelijk dat het zo verpest was dat zelfs de fall-back console van initrd mijn toetsenbord niet meer herkende. Het is mij een raadsel hoe het systeem erin is geslaagd om zo lang operationeel te blijven, terwijl ik probeerde de talloze suggesties van jullie te implementeren (heel erg bedankt !!)
Probleem bij opnieuw opstarten:
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 en daarna werkte geen toetsenbord 🙂
Het probleem was: een update verving de symlink /lib -> /usr/lib met een directory. Dus dat betekende dat alle bibliotheken en kernelmodules, die naar verwachting in /lib zouden staan, ontbraken 🙂
Dus ik heb de symlink opnieuw gemaakt en het basissysteem opnieuw geïnstalleerd vanaf een live-cd.
Nu ik weer internet heb, vond ik ook deze thread
Ik gebruikte ook de pakketbeheerder van mijn gemetselde installatie op schijf (genaamd pacman) vanaf de live-cd om alle pakketten van de basisgroep ( misschien alleen de kernel, dus pakket linux zou voldoende zijn geweest, ik weet het niet)
Om dat te bereiken, mount je de hoofdpartitie van de gemetselde installatie naar de /mnt directory van het live cd-systeem en gebruik chroot om pacman te laten denken aan /mnt is / (voeg de hoofdpartitie van je gemetselde systeem in voor 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 Voor de goede orde: maak een relatieve symlink, dus ln -s usr/lib /mnt/lib en niet ln -s /usr/lib /mnt/lib, omdat tijdens het vroege opstarten van het systeem (initrd-fase) de hoofdpartitie als eerste wordt aangekoppeld naar /new_root.Als de symlink absoluut is, krijgt u de bovengenoemde foutmelding tijdens het vroeg opstarten.
Opmerkingen
- Kleine hint: wanneer ik systemrescuecd gebruik, herhaal ik vaak gewoon over proc / sys / dev (voor pad in proc sys dev; mount -obind / $ path / mnt / $ path; done) voordat u de chroot uitvoert. Als je echter ‘ de arch install iso gebruikt, is het veel gemakkelijker om gewoon het meegeleverde arch-chroot uitvoerbare bestand uit te voeren aangezien het alles voor je doet. Het zit in het arch-install-scripts-pakket als iemand wil rondneuzen. 🙂
Answer
U probeert een 32-bits toepassing op een 64-bits besturingssysteem uit te voeren, dus je moet 32-bits compatibiliteitsbibliotheken installeren (in het bijzonder glibc) voordat dit kan werken.
Opmerkingen
- Geef aan hoe je oplossing de zaak oplost en beantwoord de vraag
- Wat Romeo zei; je zou apt-get op een arch-linux-systeem draaien, in plaats van pacman? En hoe zouden compressiebibliotheken en ncurses hen helpen?
Answer
Ter info, ik kwam hetzelfde probleem tegen toen ik in een op alpine gebaseerde docker-afbeelding. Het uitvoerbare bestand was een 64-bits ELF en de alpine-afbeelding was 64-bits en het uitvoerbare bestand werkte in een andere container. Dus vermoedelijk waren de bijgesneden alpine bibliotheken niet compatibel met mijn uitvoerbare bestand. De node.js Docker-hubpagina merkt op:
Het belangrijkste voorbehoud [om in de op Alpine gebaseerde container te draaien] is dat het musl libc gebruikt in plaats van glibc en vrienden , dus bepaalde software kan problemen tegenkomen afhankelijk van de diepte van hun libc-vereisten. De meeste software heeft hier echter geen probleem mee, dus deze variant is meestal een zeer veilige keuze. Zie deze Hacker News-commentaarthread voor meer bespreking van de problemen die zich zouden kunnen voordoen en enkele pro / contra-vergelijkingen van het gebruik van op Alpine gebaseerde images.
Mijn oplossing was om een andere (bijv. op Debian Jessie gebaseerde) containerafbeelding.
Reacties
- Bedankt voor het verbinden van dit oorspronkelijk sysadmin-probleem met de ” nieuwe ” wereld van containers!
/etc/pacman.conf. Alle afhankelijkheden van hetwine-pakket zijn geïnstalleerd. Echter, ze opnieuw installeren om er zeker van te zijn dat …/lib/ld-linux.so.2aanwezig op uw systeem? Alle symptomen wijzen erop dat het ontbreekt, controleer het gewoon./lib🙂filecommando laat zien welke interpreter is ingesteld voor dit uitvoerbare bestand.