Haluan käynnistää suoritettavan wine -ohjelman (versio 2.12), mutta saan seuraavan virheen ($ = shell-kehote):

$ 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 

Tiedosto on kuitenkin olemassa:

$ which wine /usr/bin/wine 

Suoritettava tiedosto on ehdottomasti olemassa eikä kuollutta symlinkkiä ole:

$ 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: - 

Se on 32-bittinen 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 

Saan suoritettavan tiedoston dynaamisen osan:

$ 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] 

En kuitenkaan voi luetella jaettujen objektien riippuvuuksia käyttämällä ldd:

$ ldd /usr/bin/wine /usr/bin/ldd: line 117: /usr/bin/wine: No such file or directory 

strace näyttää:

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 +++ 

Muokattu lisäämällä ehdotus käyttäjältä @jww : Vaikuttaa siltä, että ongelma esiintyy ennen dynaamista linkitystä kirjastot pyydetään, koska ld -virheenkorjausviestejä ei luoda:

$ LD_DEBUG=all wine bash: /usr/bin/wine: No such file or directory 

Jopa silloin, kun tulostetaan vain div id = ”5e246a2a50”>

, virhe tapahtuu sen sijaan

$ LD_DEBUG=help wine bash: /usr/bin/wine: No such file or directory 

Muokattu lisäämään @Raman Sailopalin ehdotus: Ongelma näyttää olevan suoritettavassa tiedostossa, koska /usr/bin/wine -sisällön kopioiminen toiseen jo luotuun tiedostoon tuottaa sama virhe

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 

Mikä ongelma tai mitä voin tehdä saadaksesi selville mikä tiedosto tai hakemisto puuttuu?


uname -a:

Linux laptop 4.11.3-1-ARCH #1 SMP PREEMPT Sun May 28 10:40:17 CEST 2017 x86_64 GNU/Linux 

Kommentit

  • tekee ./wine / usr / bin -työssä?
  • Arch on multilib-yhteensopiva. Multilib-arkisto on käytössä kohdassa /etc/pacman.conf. Kaikki wine -paketin riippuvuudet on asennettu. Asentamalla ne kuitenkin uudelleen vain varmistaaksesi, että …
  • Onko /lib/ld-linux.so.2 järjestelmässäsi? Kaikki oireet viittaavat siihen, että se puuttuu, vain tarkistamalla.
  • @ n.m. Kyllä, olit oikeassa. Itse asiassa koko hakemisto /lib puuttui 🙂
  • Kokemus;) kun yrität suorittaa suoritettavaa tiedostoa ja saada ” -tiedostoa ei löydy ” -virhe, kun tiedosto on tietysti täällä, se ’ s tulkin puuttuu. file -komento näyttää, mikä tulkki on määritetty tälle suoritettavalle tiedostolle.

Vastaa

Tämä:

$ 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 

Yhdistettynä tähän:

$ ldd /usr/bin/wine /usr/bin/ldd: line 117: /usr/bin/wine: No such file or directory 

Ehdottaa voimakkaasti että järjestelmällä ei ole /lib/ld-linux.so.2 ELF-tulkkia. Eli tässä 64-bittisessä järjestelmässä ei ole 32-bittisiä yhteensopivuuskirjastoja asennettuna. Siten @ user1334609: n vastaus on olennaisesti oikea.

Kommentit

  • Aikooko joku puhua harhaanjohtavasta virheilmoituksesta?

Vastaus

OK, olin kiireinen viimeisten kahdeksan tunnin ajan saadakseni järjestelmän toimimaan uudelleen, kun keskusyksikön ylikuumenemisen sammutus Uudelleenkäynnistyksen yhteydessä kävi selväksi, että se oli niin ruuvattu, ettei edes initrdin varakonsoli tunnistanut näppäimistöäni. Minulle on mysteeri, kuinka järjestelmä onnistui pysymään toiminnassa niin kauan, kun yritin toteuttaa lukemattomia ehdotuksia (kiitos paljon !!)

Ongelma uudelleenkäynnistyksessä:

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 

eikä yhtään näppäimistöä toimi jälkeenpäin 🙂

Ongelma oli: Päivitys korvasi symlinkin /lib -> /usr/lib hakemistolla. Joten tämä tarkoitti sitä, että kaikki kirjastot ja ytimen moduulit, joiden oletetaan olevan /lib, puuttuivat 🙂

Joten luo symlink uudelleen ja asensin perusjärjestelmän uudelleen live-CD.

Nyt kun minulla on jälleen Internet, löysin myös tämän ketjun

Käytin myös minun muokattu levyn asennus (nimeltään pacman) live-CD-levyltä kaikkien -perusryhmän pakettien asentamiseksi uudelleen ( ehkä vain ydin, joten paketti linux olisi riittänyt, en tiedä)

Tämän saavuttamiseksi asenna muuratun asennuksen pääosio live-CD-järjestelmän hakemisto /mnt ja käytä chroot

ajattelemaan/mnton/(lisää muuratun järjestelmän pääosiosdXXX)

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 

Tietueelle: luo suhteellinen symlinkki, joten ln -s usr/lib /mnt/lib eikä ln -s /usr/lib /mnt/lib, koska järjestelmän varhaisessa käynnistyksessä (initrd-vaiheessa) pääosio asennetaan ensin kohtaan /new_root.Olisiko symlink absoluuttinen, saatko yllä mainitun virheen varhaisessa käynnistyksessä.

kommentit

  • Pieni vihje: Kun käytän systemrescuecd-tiedostoa, toistan usein vain prosessin proc / sys / dev (polulle proc sys dev; do mount -obind / $ polku / mnt / $ polku; valmis) ennen chroot-toiminnon tekemistä. Jos kuitenkin ’ käytät kaaren asennus iso -ohjelmaa, on paljon helpompaa vain suorittaa toimitettu arch-chroot-suoritustiedosto, koska se tekee kaiken puolestasi. Se on arch-install-scripts -paketissa, jos joku haluaa tunkeutua. 🙂

Vastaa

Yrität ajaa 32-bittistä sovellusta 64-bittisessä käyttöjärjestelmässä, joten Sinun on asennettava 32-bittiset yhteensopivuuskirjastot (erityisesti glibc), ennen kuin tämä voi toimia.

Kommentit

  • Selvitä, miten ratkaisusi ratkaisee tapauksen ja vastaa kysymykseen
  • mitä Romeo sanoi; suoritat apt-get arch-linux -järjestelmässä pacmanin sijaan? Ja miten pakkauskirjastot ja ncurssit auttavat heitä?

Vastaa

FYI, törmäsin samaan ongelmaan käynnissä alppipohjaisessa telakointikuvassa. Suoritettava tiedosto oli 64-bittinen ELF ja alppikuva oli 64-bittinen, ja suoritettava toimi eri säiliössä. Joten oletettavasti leikatut alppikirjastot eivät olleet yhteensopivia suoritettavan tiedostoni kanssa. node.js Docker-keskittimen sivu huomauttaa:

Päävaroitus [Käynnissä alppipohjaisessa säilössä] tarkoittaa, että se käyttää musl libc : n sijasta glibc ja ystävät , joten tietyt ohjelmistot saattavat törmätä ongelmiin libc-vaatimustensa syvyydestä riippuen. Suurimmalla osalla ohjelmistoista ei kuitenkaan ole ongelmaa, joten tämä muunnos on yleensä erittäin turvallinen valinta. Katso tämä Hacker News -viestiketju saadaksesi lisätietoja mahdolliset ongelmat ja joitain pro / con-vertailuja Alpine-pohjaisten kuvien käytöstä.

Ratkaisuni oli käyttää toista (esim. Debian Jessie -pohjaista) säilökuva.

Kommentit

  • Kiitos tämän alun perin sysadmin-ongelman liittämisestä ” uuteen ” konttien maailma!

Vastaa

Sähköpostiosoitettasi ei julkaista. Pakolliset kentät on merkitty *