Jeg vil starte wine kjørbar (versjon 2.12), men jeg får følgende feil ($ = 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 imidlertid der:
$ which wine /usr/bin/wine Den kjørbare filen er definitivt der og 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 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 delen av den kjørbare:
$ 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 imidlertid ikke liste de delte objektavhengighetene ved hjelp av 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 +++ Redigert for å legge til forslag av @jww : Problemet ser ut til å skje før dynamisk koblet biblioteker blir bedt om, fordi det ikke genereres ld feilsøkingsmeldinger:
$ LD_DEBUG=all wine bash: /usr/bin/wine: No such file or directory Selv når du bare skriver ut de mulige verdiene til LD_DEBUG, feilen oppstår i stedet
$ LD_DEBUG=help wine bash: /usr/bin/wine: No such file or directory Redigert for å legge til forslag fra @Raman Sailopal: Problemet ser ut til å ligge i den kjørbare filen, da kopiering av innholdet i /usr/bin/wine til en annen allerede opprettet fil produserer den samme feilen
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 Hva er problemet, eller hva kan jeg gjøre for å finne ut hvilken fil eller katalog som 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 Kombinert med dette:
$ ldd /usr/bin/wine /usr/bin/ldd: line 117: /usr/bin/wine: No such file or directory Anbefaler på det sterkeste at systemet ikke har /lib/ld-linux.so.2 ELF-tolk. Det vil si at dette 64-biterssystemet ikke har noen 32-biters kompatibilitetsbiblioteker installert. Dermed er @ user1334609s svar i det vesentlige riktig.
Kommentarer
- Er det noen som kommer til å snakke om den misvisende feilmeldingen?
Svar
OK, jeg var opptatt de siste åtte timene for å få systemet mitt i gang igjen etter at CPU-overoppheting ble slått av Ved omstart ble det tydelig at det var så skrudd sammen at selv ikke tilbakeslagskonsollen til initrd ikke kjente igjen tastaturet mitt. Det er et mysterium for meg hvordan systemet klarte å være i drift så lenge, mens jeg prøvde å implementere de utallige forslagene fra deg (tusen takk !!)
Problem ved 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 og ingen tastatur fungerer etterpå 🙂
Problemet var: En oppdatering erstattet symlinken /lib -> /usr/lib med en katalog. Så det betydde at alle biblioteker og kjernemoduler, som forventes å være i /lib manglet 🙂
Så jeg gjenskape symlink og installerte basesystemet på nytt fra en live CD.
Nå som jeg har internett igjen, fant jeg også denne tråden
Jeg brukte også pakkebehandleren til muret installasjon på disken (kalt pacman) fra live-CDen for å installere alle pakkene på basegruppen ( kanskje bare kjernen, så pakke linux hadde vært nok, jeg vet ikke)
For å oppnå det, monter hovedpartisjonen til den murede installasjonen til /mnt katalogen til live CD-systemet og bruk chroot for å få pacman til å tenke /mnt er / (sett inn det murte systemets hovedpartisjon for 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: opprett en relativ symlink, så ln -s usr/lib /mnt/lib og ikke ln -s /usr/lib /mnt/lib, fordi hovedpartisjonen blir montert først under tidlig systemstart (initrd-trinn) til /new_root.Ville symlink være absolutt, ville du få ovennevnte feil under tidlig oppstart.
Kommentarer
- Lite hint: Når jeg bruker systemrescuecd, gjentar jeg ofte bare over proc / sys / dev (for sti i proc sys dev; monter -obind / $ path / mnt / $ path; done) før du gjør chroot. Imidlertid, hvis du ‘ bruker arch install iso, er det mye lettere å bare kjøre den medfølgende arch-chroot-kjørbare siden den gjør alt for deg. Det er i arch-install-scripts-pakken hvis noen vil pikke rundt. 🙂
Svar
Du prøver å kjøre 32-biters applikasjon på et 64-biters operativsystem, så du må installere 32-biters kompatibilitetsbiblioteker (spesielt glibc) før dette kan fungere.
Kommentarer
- Forklar hvordan løsningen løser saken og svar på spørsmålet
- Hva Romeo sa; vil du kjøre apt-get på et arch-linux-system, i stedet for pacman? Og hvordan ville komprimeringsbiblioteker og ncurses hjelpe dem?
Svar
FYI, jeg kjørte på det samme problemet som kjørte i et alpinbasert dockerbilde. Den kjørbare filen var en 64-bit ELF, og det alpine bildet var 64-bit, og den kjørbare kjørte i en annen container. Så antagelig var de trimmede alpine bibliotekene ikke kompatible med min kjørbare. node.js Docker-hub-side notater:
Hovedadvarselen [å kjøre i den alpinbaserte beholderen] er at den bruker musl libc i stedet for glibc og venner , så det kan hende at visse programmer støter på problemer, avhengig av dybden i libc-kravene. Imidlertid har de fleste programvare ikke noe problem med dette, så denne varianten er vanligvis et veldig trygt valg. Se denne kommentaren for Hacker News for mer diskusjon om problemer som kan oppstå og noen pro / con-sammenligninger av å bruke Alpine-baserte bilder.
Min løsning var å bruke en annen (f.eks. Debian Jessie-basert) containerbilde.
Kommentarer
- Takk for at du kobler dette opprinnelige sysadmin-problemet til » nye » verden av containere!
/etc/pacman.conf. Alle avhengigheter avwine-pakken er installert. Imidlertid installere dem på nytt for å sikre …/lib/ld-linux.so.2til stede på systemet ditt? Alle symptomer peker på at det mangler, bare sjekker./lib🙂file-kommandoen viser hvilken tolk som er angitt for denne kjørbare filen.