64-bit bir sistemde 32-bit bir ikili çalıştırırken “Bulunamadı” mesajı alınıyor


70

Şu anda debian konusunda garip bir sorunum var (wheezy / amd64).

Bir sunucu yüklemek için bir chroot oluşturdum (bu konuda daha fazla ayrıntı veremem, üzgünüm). Hadi onun yolunu diyelim /chr_path/. İşleri kolaylaştırmak için, bu chroot'u bir debootstrap (ayrıca wheezy / amd64) ile başlattım.

Hepsi chroot içinde iyi çalışıyor gibiydi ama sunucumun installer betiğini başlattığımda şunu anladım: zsh: Not found /some_path/perl(yükleyici bazı nedenlerden dolayı bir perl binary'i içerir)

Doğal olarak, /some_path/yeri kontrol ettim ve "perl" ikilisini buldum. filechroot ortamında döndürür:

/some_path/perl ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.2.5, not stripped

Dosya var, tamam görünüyor, haklara sahip. Ben kullanabilir file, ls, vimüzerinde ama en kısa sürede denemek gibi yürütmek - ./perlörneğin - Ben olsun: zsh: Not found ./perl.

Bu durum benim için oldukça anlaşılabilir. Dahası :

  • Chroot'ta diğer temel ikilik dosyaları (/ bin / ls, ...) hataya yol açmadan çalıştırabilirim
  • Projeyle birlikte gelen diğer ikili dosyalar için de aynı sorunları yaşıyorum
  • İkili dosyayı ana kökten ( /chr_path/some_path/perl) çalıştırmaya çalıştığımda , çalışıyor.
  • İkili dosyalardan birini kopyamla koymaya çalıştım ls. Erişim haklarının aynı olduğunu kontrol ettim ama bu hiçbir şeyi değiştirmedi (biri çalışıyordu, diğeri değildi)

1
Bu, Optware yüklü ikili dosyalarda "Böyle bir dosya veya dizin yok" ile aynı sorun . Perl'inizin 32-bit bir çalıştırılabilir olduğunu unutmayın. 32 bit çalışma zamanı sistemini kaçırıyorsunuz ( libc6-i386paket veya ia32-libsçok fazla kitaplık istiyorsanız).
Gilles

@Gilles: Çok teşekkürler! Bir yetenek yükleme ia32-libs sorunu çözdü !! Perl'in 32 bit olduğunu görmüştüm, ancak ana sistem üzerinde çalıştığından (aynı dağıtım) sadece bağlantı olmadığını varsaymıştım. Aslında, ana sistemde 32 bit çalışma zamanı sistemini bir noktada kurmuş olmalıyım.
Elenaher

1
@Gilles: Bunu yinelenen bir soru olarak işaretlemek yerine kısa ve öz bir cevap olarak ekleyeceğimi düşünüyorum. Ortam, problem aynı olsa da, insanları aramanın bir veya diğerine çarpması daha olasıdır.
Caleb

1
@Caleb Kopyaları tam olarak bu sebepten silmiyoruz; bunu bulan arama yapanlar, diğer gönderiye kopyalanan bağlantıyı izleyecektir. Bu aynı sorun ise, muhtemelen sadece kapatılması gerekir
Michael Mrozek

@MichaelMrozek Bu sorudaki fikrimi değiştirdim: temel sorun aynıyken, somut çözüm biraz daha farklı (bir durumda ARM ABI'lerin karıştırılmaması, diğerinde amd64 Linux dağıtımına 32 bit destek sağlanması) . Bu yüzden sanırım bu soru neticede açık.
Gilles

Yanıtlar:


72

Bir "yükleyiciye" bağlı bir dosyayı yürütemediğinizde, aldığınız hata, yürütmekte olduğunuz dosya yerine yükleyiciye başvurabilir.

  • Dinamik olarak bağlanmış bir yerel çalıştırılabilir dosyasının yükleyicisi, dinamik kitaplıkların yüklenmesinden sorumlu olan sistemin bir parçasıdır. Bu /lib/ld.soveya benzeri bir şey /lib/ld-linux.so.2ve yürütülebilir bir dosya olmalıdır.
  • Bir betiğin yükleyicisi, shebang satırında belirtilen programdır, örneğin /bin/sh, başlangıçtaki bir komut dosyası için #!/bin/sh. (Bash ve zsh, bu durumda “komut bulunamadı” yerine “hatalı tercüman” mesajı verir.)

Hata mesajı, yükleyicinin sorun olduğunu göstermemekte yanıltıcıdır. Ne yazık ki, bunu düzeltmek zor olacaktır, çünkü çekirdek arayüzü yalnızca sayısal bir hata kodu rapor etmek için yeterli alana sahiptir, aynı zamanda hatanın aslında farklı bir dosyayla ilgili olduğunu göstermez. Bazı mermiler, kendileri komut dosyaları için çalışırlar ( #!komut dosyasındaki satırı okumak ve hata koşulu yeniden çalışmak), ancak hiçbiri yerel ikili dosyalar için aynı şeyi yapma girişimi görmedim.

lddİkili dosyalar üzerinde çalışmayacaktır çünkü bazı özel ortam değişkenlerini ayarlayarak ve daha sonra programı çalıştırarak yükleyicinin çalışmasını sağlayarak çalışır. straceÇekirdeğin rapor ettiği şeyden daha fazlasını rapor etmeyeceği için anlamlı bir bilgi vermeyecektir. Görüldüğü gibi çekirdeğin bildiği her şeyi rapor edememesidir.

Bu durum genellikle doğru sistem (veya sistem ailesi) ve üst mimarlık için yanlış bir alt mimarlık için bir ikili çalıştırmaya çalıştığınızda ortaya çıkar. Burada ELF ikili dosyalarını bekleyen bir sistemde ELF ikili dosyaları var, bu yüzden çekirdek onları iyi yüklüyor. Bunlar bir x86_64 işlemci üzerinde çalışan i386 binary'leridir, bu nedenle talimatlar mantıklıdır ve programı yükleyicisini arayabileceği noktaya getirir. Ancak program 32 bitlik bir programdır ( fileçıktının belirttiği gibi), 32 bitlik yükleyiciyi arar /lib/ld-linux.so.2ve muhtemelen yalnızca 64 bitlik yükleyiciyi /lib64/ld-linux-x86-64.so.2chroot'a yüklediniz .

32 bit çalışma zamanı sistemini chroot: loader ve programların ihtiyaç duyduğu tüm kütüphaneleri kurmanız gerekir. Debian wheezy'den itibaren, hem i386 hem de x86_64 desteğini istiyorsanız, bir amd64 yüklemesiyle başlayın ve çoklu erişim desteğini etkinleştirin : dpkg --add-architecture i386sonra çalıştırın apt-get updateve apt-get install libc6:i386 zlib1g:i386 …(hangi kitaplıkların muhtemel olduğunu görmek için Debian'ın perl paketinin bağımlılıklarının bir listesini oluşturmak istiyorsanız) çalıştırın . ihtiyaç duyulabilir, kullanabilirsiniz aptitude search -F %p '~Rdepends:^perl$ ~ri386'). ia32-libsPaketi yükleyerek ortak kütüphaneler koleksiyonundan yararlanabilirsiniz ( önce multiarch desteğini etkinleştirmeniz gerekir). Debian amd64’te wheezy’de, 32-bit yükleyici libc6-i386paketin içinde. Yükleyerek daha büyük bir 32-bit kitaplık grubunu yükleyebilirsiniz ia32-libs.


Hata mesajını tetikleyebilecek tek şey bu mu? 32 bitlik kütüphaneleri yükledim ve işte çıktısıldd ancak yine de aynı hatayı alıyorum.
Nathan Osman,


Yüklemeyi denedim lsb-coreama bunun bir yardımı olmadı. Sanırım bunun için yeni bir soru açsam iyi olur.
Nathan Osman,

Bunun için teşekkür ederim, iki gün süren tırmalama ile bitirdiniz. Her şeyin statik olarak derlendiğini sanıyordum ama olmadı!
Finn O'leary

5

İkilinin ldd(1)üzerinde koş perl. Genellikle, Not foundprogram tarafından kullanılan paylaşılan kütüphanelerden birinin bulunmaması nedeniyle açıkça görünen bir dosyadaki kafa karıştırıcı hata görünüyor .

Bu nedenle, chroot’unuzun ikili dosyalarınızın ihtiyaç duyduğu paylaşılan kütüphanelere göre eksik olması mümkündür.


Aslında alıyorum: perl is not a dynamic executablechroot'tayken ve dışarıdan doğru bağımlılıklar listesini alıyorum. Şu anda garip bir şey olup olmadığını kontrol ediyorum ama bu tür eksikliklerden kaçınmak için bir debootstrap kullandım ve halihazırda birçok kütüphaneye sahip oldum (chroot sisteminde iyi çalışan bir perl var ama farklı bir sürüm; belki de sadece bazılarını yapacağım) sembolik bağlantı?)
Elenaher

Dürüst olmak gerekirse, bootstrap'ın tam bir chroot üretmesini beklerdim, bu yüzden cevabımın bu anlamda doğru olmasını beklemiyordum. Ama daha önce chroot probleminde eksik kütüphaneyi araştırdım, bu yüzden cevabımın uçup uçmayacağını görmeyi düşündüm.
camh

bakınız Gilles ana mesaj üzerine yorum: Sen haklıydın. Bazı kütüphaneler eksikti. Debootstrap'in temel avantajı, problemi temel bir yetenek kurulumuyla
çözebilmem
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.