Jak mogę chrootować do systemu plików z inną architekturą?

Próbuję przejść chrootdo systemu ARMplików Arch Linux x86_64.

Widziałem, że można to zrobić za pomocą static qemu, kopiując plik binarny do systemu chroot:

$ cp /usr/bin/qemu-arm archarm-chroot/usr/bin    

Ale mimo to zawsze pojawia się następujący błąd:

chroot: failed to run command ‘/bin/bash’: Exec format error

Wiem, że to oznacza, że ​​architektury się różnią. czy robię coś źle?

Nie możesz chrootować w innej architekturze. Podczas chrootowania uruchamiasz pliki binarne (z chroot) w swojej architekturze. Wykonywanie plików binarnych ARM na x86 (i x86_64 w tym przypadku) prowadziłoby do „błędu formatu wykonania”.

Jeśli chcesz uruchomić pliki binarne z innej architektury, potrzebujesz Emulatora. Qemu jest dobrym kandydatem do tego, ale musisz nauczyć się z niego korzystać. Wymagałoby to utworzenia RootFS i kompilacji jądra dla ARM. Być może będziesz potrzebować łańcucha narzędzi do kompilacji plików binarnych ARM (i jądra). Jedno jest pewne: zapomnij o metodzie chroot, nie możesz uruchamiać plików binarnych skompilowanych dla ARM na x86 (x86_64).

Edycja: Po krótkiej rozmowie z @UrichDangel zdałem sobie sprawę, że powinno być możliwe wejście do środowiska chroot za pomocą programów qemu-user (w tym przypadku qemu-arm). Chroot powinien wykonywać qemu-arm skompilowany dla architektury hosta, a następnie qemu-arm może wykonać / bin / sh (skompilowany dla arm).

Od czasu do czasu używam chroota ARM: na moim telefonie działa Linux Deploy, a obraz od czasu do czasu umiera. Następnie kopiuję go na komputer i badam sytuację z chroot w następujący sposób:

# This provides the qemu-arm-static binary
apt-get install qemu-user-static

# Mount my target filesystem on /mnt
mount -o loop fs.img /mnt

# Copy the static ARM binary that provides emulation
cp $(which qemu-arm-static) /mnt/usr/bin
# Or, more simply: cp /usr/bin/qemu-arm-static /mnt/usr/bin

# Finally chroot into /mnt, then run 'qemu-arm-static bash'
# This chroots; runs the emulator; and the emulator runs bash
chroot /mnt qemu-arm-static /bin/bash

Myślę, że problem polega na tym, że nie powinieneś kopiować, qemu-armale qemu-arm-static. Jest to statycznie skompilowany plik wykonywalny, który może uruchamiać się w chroocie bez żadnych bibliotek.

Możesz także sprawdzić, /proc/sys/fs/binfmt_miscczy istnieje plik qemu-arm. Jeśli nie, uruchom ponownie usługę binfmt_support.

Aby to działało, zainstalowałem qemu-static-armi binfmt-supportz AUR.

Przeczytaj komentarze do qemu-user-static. Musiałem zaktualizować PKGBUILDnajnowszy adres URL pobierania i skróty do makepkg, aby zakończyć.

(Aby zainstalować z AUR, należy pobrać archiwum, untar, cd, run makepkg -i)

Odpowiedź Christiana Wolfa jest ważna. update-binfmtsnie jest poprawnie wykonany, aby włączyć te formaty. Aby to zrobić, pobiegłem:

update-binfmts --importdir /var/lib/binfmts/ --import

jak opisano na stronie podręcznika dla update-binfmts. Następnie cat /proc/sys/fs/binfmt_miscpokaże różne binfmts.

Następnie upewnij się, że skopiowałeś qemu-*-staticdo usr/bin/katalogu w rzeczy, do której chcesz chrootować, a wtedy chrootpowinno działać.

Zdecydowanie możesz „chroot” do (zamontowanego) systemu plików przeznaczonego dla innej architektury i wykonać znaczącą pracę, potrzebujesz tylko odpowiednich narzędzi.

Zobacz PRoot, który jest implementacją chroot, mount --bind i binfmt_misc w przestrzeni użytkownika: https://proot-me.github.io/

Razem z emulatorami trybu użytkownika QEMU wszystko gotowe.

Chociaż zwykle nie można wykonać „pełnego” rozruchu (tj. Uruchomienie init i usług), wystarczy uruchomić niektóre pliki binarne z ich „naturalnego” miejsca, z dostępem do wszystkich ich plików konfiguracyjnych, w tym niektórych, które są zamontowane na bindach z system „hosta” itp.

sudo apt-get update
sudo apt-get install debootstrap qemu qemu-user-static
sudo qemu-debootstrap --arch armhf bionic armhf-chroot
sudo chroot armhf-chroot

uname -m 

Dodanie do odpowiedzi Luca: musisz upewnić się, że lokalizacja interpretera jest taka sama w chroot, jak w głównym systemie plików. Wynika to z faktu, że jądro wykrywa architekturę pliku wykonywalnego, a następnie używa lokalizacji interpretera, jak pokazano za pomocą, update-binfmts --displayaby go uruchomić. Więc linia

cp $(which qemu-arm-static) /mnt/usr/bin

powinno być

cp $(which qemu-arm-static) /mnt/$(which qemu-arm-static)

W przeciwnym razie możesz dostać błąd „Nie znaleziono” wewnątrz twojego chroota, ponieważ twoje jądro nie może znaleźć wymaganego interpretera, jeśli lokalizacja qemu-arm-staticnie znajduje się /usr/binw twoim systemie.

Właśnie natrafiłem na ten sam problem na Ubuntu. Miałem binfmtskonfigurowane i qemu-arm-staticskopiowane na tej samej ścieżce chroot-ed jak na systemie hosta.

Po godzinie zrobiłem to set|grep bashna maszynie hosta. Odkryłem, że mam /bin/bashdwie zmienne env: SHELLi SUDO_COMMAND. Po zamianie zmiennych mój chroot na ARM działał:

SHELL=/bin/sh SUDO_COMMAND=/bin/sh chroot hd

Sądzę, że dla tego PO wszystko, co musiał zrobić, to skonfigurować binfmts, po prostu uruchamiając:

update-binfmts --enable qemu-arm

Po uruchomieniu tego chroot w systemie plików zbrojenia byłby możliwy.