Jag vill starta wine körbar (version 2.12), men jag får följande fel ($ = 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 Filen finns däremot:
$ which wine /usr/bin/wine Den körbara är definitivt där och ingen död 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: - Det är en 32-bitars 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 Jag kan få den dynamiska delen av den körbara:
$ 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] Jag kan dock inte lista de delade objektberoenden med ldd:
$ ldd /usr/bin/wine /usr/bin/ldd: line 117: /usr/bin/wine: No such file or directory strace visar:
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 +++ Redigerad för att lägga till förslag av @jww : Problemet verkar inträffa innan dynamiskt länkat bibliotek begärs, eftersom inga ld felsökningsmeddelanden genereras:
$ LD_DEBUG=all wine bash: /usr/bin/wine: No such file or directory Även när man bara skriver ut de möjliga värdena för LD_DEBUG, felet uppstår istället
$ LD_DEBUG=help wine bash: /usr/bin/wine: No such file or directory Redigerat för att lägga till förslag från @Raman Sailopal: Problemet verkar ligga inom den körbara filen, eftersom kopiering av innehållet i /usr/bin/wine till en annan redan skapad fil ger samma fel
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 Vad är problemet eller vad kan jag göra för att ta reda på vilken fil eller katalog som saknas?
uname -a:
Linux laptop 4.11.3-1-ARCH #1 SMP PREEMPT Sun May 28 10:40:17 CEST 2017 x86_64 GNU/Linux Kommentarer
Svar
Detta:
$ 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 Kombinerat med detta:
$ ldd /usr/bin/wine /usr/bin/ldd: line 117: /usr/bin/wine: No such file or directory Föreslår starkt att systemet inte har /lib/ld-linux.so.2 ELF-tolk. Det vill säga, det här 64-bitarssystemet har inga 32-bitars kompatibilitetsbibliotek installerade. Således är @ user1334609: s svar väsentligen korrekt.
Kommentarer
- Kommer någon att prata om det missvisande felmeddelandet?
Svar
OK, jag var upptagen de senaste åtta timmarna för att få igång mitt system igen efter att CPU-överhettning stängts av Vid omstart blev det uppenbart att det var så uppskruvat att till och med fallkonsolen för initrd inte kände igen mitt tangentbord längre. Det är ett mysterium för mig hur systemet lyckades vara operativt så länge, medan jag försökte implementera de otaliga förslagen från dig (tack så mycket !!)
Problem vid omstart:
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 och inget tangentbord fungerar efteråt 🙂
Problemet var: en uppdatering ersatte symlink /lib -> /usr/lib med en katalog. Så det innebar att alla bibliotek och kärnmoduler som förväntas vara i /lib saknades 🙂
Så jag återskapade symlink och installerade om bassystemet från en live-CD.
Nu när jag har internet igen hittade jag också den här tråden
Jag använde också pakethanteraren för min murad installation på disken (kallad pacman) från live-CD: n för att installera om alla paket i basgruppen ( kanske bara kärnan, så paket linux skulle ha varit tillräckligt, jag vet inte)
För att åstadkomma detta, montera huvudpartitionen på den murade installationen till /mnt -katalogen för live-CD-systemet och använd chroot för att få pacman att tänka /mnt är / (infoga ditt brickade systems huvudpartition för 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 För ordens skull: skapa en relativ symlänk, så ln -s usr/lib /mnt/lib och inte ln -s /usr/lib /mnt/lib, för under tidig systemstart (initrd-steg) kommer huvudpartitionen att monteras först till /new_root.Skulle symlänken vara absolut, skulle du få ovan nämnda fel under tidig start.
Kommentarer
- Liten ledtråd: När jag använder systemrescuecd itererar jag ofta bara över proc / sys / dev (för sökväg i proc sys dev; montera -obind / $ path / mnt / $ path; done) innan du gör chroot. Men om du ’ använder arch install iso, är det mycket lättare att bara köra den medföljande arch-chroot-körningen eftersom den gör allt åt dig. Det finns i arch-install-scripts-paketet om någon vill peka runt. 🙂
Svar
Du försöker köra 32-bitarsapplikation på ett 64-bitars operativsystem, så du måste installera 32-bitars kompatibilitetsbibliotek (särskilt glibc) innan detta kan fungera.
Kommentarer
- Förklara hur din lösning löser ärendet och svara på frågan
- Vad Romeo sa; skulle du köra apt-get på ett arch-linux-system istället för pacman? Och hur skulle komprimeringsbibliotek och ncurses hjälpa dem?
Svar
FYI, jag stötte på samma fråga som kör i en alpinbaserad dockerbild. Den körbara var en 64-bitars ELF, och den alpina bilden var 64-bit, och den körbara arbetade i en annan behållare. Så förmodligen var de trimmade alpina biblioteken inte kompatibla med min körbara. node.js Docker hub-sida anteckningar:
Huvudförbehållet [att köra i den alpina baserade behållaren] är att den använder musl libc istället för glibc och vänner , så viss programvara kan stöta på problem beroende på djupet i deras libc-krav. Men de flesta programvaror har inget problem med detta, så den här varianten är vanligtvis ett mycket säkert val. Se denna Hacker News-kommentartråd för mer diskussion om problem som kan uppstå och vissa pro / con-jämförelser av att använda Alpine-baserade bilder.
Min lösning var att använda en annan (t.ex. Debian Jessie-baserad) containerbild.
Kommentarer
- Tack för att du anslöt detta ursprungligen sysadminproblem till ” nya ” värld av containrar!
/etc/pacman.conf. Alla beroenden i paketetwineär installerade. Men ominstallera dem bara för att se till …/lib/ld-linux.so.2på ditt system? Alla symtom pekar på att det saknas, bara att kontrollera./libsaknades 🙂file-kommando visar vilken tolk som är inställd för den här körbara filen.