Jeg vil starte wine eksekverbar (version 2.12), men jeg får følgende fejl ($ = 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 er dog der:
$ which wine /usr/bin/wine Den eksekverbare er helt sikkert der og ingen døde 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 er en 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 Jeg kan få den dynamiske sektion af den eksekverbare fil:
$ 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] Jeg kan dog ikke liste de delte objektsafhængigheder ved hjælp af ldd:
$ ldd /usr/bin/wine /usr/bin/ldd: line 117: /usr/bin/wine: No such file or directory strace viser:
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 +++ Redigeret for at tilføje forslag af @jww : Problemet ser ud til at ske, før det er dynamisk forbundet biblioteker anmodes om, fordi der ikke genereres ld debug-meddelelser:
$ LD_DEBUG=all wine bash: /usr/bin/wine: No such file or directory Selv når der kun udskrives de mulige værdier på LD_DEBUG, fejlen opstår i stedet
$ LD_DEBUG=help wine bash: /usr/bin/wine: No such file or directory Redigeret for at tilføje forslag fra @Raman Sailopal: Problemet synes at ligge i den eksekverbare, da kopiering af indholdet af /usr/bin/wine til en anden allerede oprettet fil producerer den samme fejl
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 Hvad er problemet, eller hvad kan jeg gøre for at finde ud af, hvilken fil eller mappe der mangler?
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
Dette:
$ 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 Kombineret med dette:
$ ldd /usr/bin/wine /usr/bin/ldd: line 117: /usr/bin/wine: No such file or directory foreslår stærkt at systemet ikke har /lib/ld-linux.so.2 ELF-tolk. Det vil sige, dette 64-bit-system har ingen 32-bit kompatibilitetsbiblioteker installeret. Således er @ user1334609s svar i det væsentlige korrekt.
Kommentarer
- Vil nogen tale om den vildledende fejlmeddelelse?
Svar
OK, jeg havde travlt i de sidste otte timer for at få mit system i gang igen efter CPU-overophedning lukket ned Ved genstart blev det tydeligt, at det var så skruet op, at selv efterkonsol af initrd ikke længere genkendte mit tastatur. Det er et mysterium for mig, hvordan systemet formåede at forblive operativt så længe, mens jeg prøvede at implementere de utallige forslag fra dig (mange tak !!)
Problem ved genstart:
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 og intet tastatur fungerer bagefter 🙂
Problemet var: En opdatering erstattede symlinket /lib -> /usr/lib med et bibliotek. Så det betød, at alle biblioteker og kernemoduler, som forventes at være i /lib manglede 🙂
Så jeg genskabte symlinket og geninstallerede basissystemet fra en live CD.
Nu hvor jeg har internet igen, fandt jeg også denne tråd
Jeg brugte også min pakkehåndtering muret installation på disken (kaldet pacman) fra live-cden for at geninstallere alle pakkerne til basegruppen ( måske kun kernen, så pakke linux ville have været nok, jeg ved det ikke)
For at opnå dette skal du montere hovedpartitionen af den murede installation til /mnt biblioteket i live CD-systemet og brug chroot til at få pacman til at tænke /mnt er / (indsæt dit murede systems hovedpartition til 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 For ordens skyld: Opret et relativt symlink, så ln -s usr/lib /mnt/lib og ikke ln -s /usr/lib /mnt/lib, fordi hovedpartitionen under den tidlige systemstart (initrd-fase) monteres først til /new_root.Ville symlinket være absolut, ville du få den ovennævnte fejl under tidlig opstart.
Kommentarer
- Lille tip: Når du bruger systemrescuecd, gentager jeg ofte bare over proc / sys / dev (for sti i proc sys dev; monter -obind / $ sti / mnt / $ sti; færdig) inden chroot. Men hvis du ‘ igen bruger arch install iso, er det meget nemmere at bare køre den medfølgende arch-chroot-eksekverbar fil, da den gør alt for dig. Det er i arch-install-scripts-pakken, hvis nogen vil stikke rundt. 🙂
Svar
Du forsøger at køre 32-bit applikation på et 64 bit operativsystem, så du skal installere 32-bit kompatibilitetsbiblioteker (især glibc), før dette kan fungere.
Kommentarer
- Præciser, hvordan din løsning løser sagen og besvar spørgsmålet
- Hvad Romeo sagde; ville du køre apt-get på et arch-linux-system i stedet for pacman? Og hvordan ville kompressionsbiblioteker og ncurses hjælpe dem?
Svar
FYI, jeg løb ind i det samme problem kørende i et alpebaseret dockerbillede. Den eksekverbare var en 64-bit ELF, og det alpine billede var 64-bit, og den eksekverbare arbejdede i en anden beholder. Så formodentlig var de trimmede alpine biblioteker ikke kompatible med min eksekverbare. node.js Docker-hub-siden bemærker:
Hovedadvarslen [til at køre i den alpine-baserede container] er, at den bruger musl libc i stedet for glibc og venner , så bestemt software kan løbe ind i problemer afhængigt af dybden af deres libc-krav. Imidlertid har den fleste software ikke noget problem med dette, så denne variant er normalt et meget sikkert valg. Se denne kommentartråd for Hacker News for mere diskussion af problemer, der kan opstå, og nogle pro / con-sammenligninger af brug af Alpine-baserede billeder.
Min løsning var at bruge en anden (f.eks. Debian Jessie-baseret) containerbillede.
Kommentarer
- Tak fordi du forbinder dette oprindelige sysadmin-problem med ” nye ” verden af containere!
/etc/pacman.conf. Alle afhængigheder afwine-pakken er installeret. Imidlertid geninstallere dem bare for at sikre …/lib/ld-linux.so.2til stede på dit system? Alle symptomer peger på, at det mangler, bare ved at kontrollere./lib🙂file-kommando viser, hvilken tolk der er indstillet til denne eksekverbare.