Zabawy z Raspbianem czyli jak to zrobić bez malinki - uzupełnienie

W poprzedni artykule opisywałem sposób na emulację maszyny dla architektury ARM – konkretnie RPI. Emulacja przy pomocy Qemu jak mogli się wszyscy przekonać była prosta do wykonania, główną jej wadą była niska wydajność. W ramach uzupełnienia tego tematu chciałbym opisać inną możliwość pracy z obrazem systemu przeznaczonego dla RPI.

Autorem wpisu jest Rafał Świętonowski.

Ci z czytelników, którzy słyszeli lub używali np. dystrybucji Gentoo będą wiedzieli już na początku o co chodzi. Sposób instalacji tej dystrybucji opiera się właśnie na metodzie opisanej poniżej.

O ile w przypadku wykorzystywania Qemu nie było specjalnie potrzeby wydzielania osobnego systemu (w naszym przypadku była to maszyna wirtualna uruchomiona w Virtualboxie), o tyle w tym przypadku zachęcam do takiego rozwiązania. Możliwości zepsucia głównego systemu jest kilka :)

Czytaj dalej poniżej

Tego drona chciałbym na gwiazdkę, a trzymałbym go... w kieszeni Jakub Szczęsny

Straciłeś wiarę w polskich gimnazjalistów? No to spójrz na to Tomasz Popielarczyk

O czym zatem będę pisał? Będzie o poleceniu chroot. Polecenie to zmienia katalog główny systemu (root). Taka cecha daje różne możliwości. Możemy testować aplikacje czy całe systemy w wydzielonym środowisku, separować uprawnienia czy izolować specyficzne środowiska zawierające określone bibliotek programów. Oczywiście polecenie chroot ma tez swoje wady i ograniczenia, np. dotyczące zagadnień bezpieczeństwa (np.: tylko użytkownik root może wywołać to polecenie) ale na potrzeby tego artykułu nie będziemy kłopotać sobie tym głowy. Głównym zadaniem będzie wydzielenie środowiska systemowego dla architektury ARM.

Jak poprzednio będę używał Ubuntu uruchomionego w Virtualboxie.

Przygotowanie środowiska

W poprzednim artykule instalowaliśmy już wiele programów z grupy qemu. W tym przypadku potrzebujemy następujący program:

Następnym krokiem będzie przygotowanie naszego systemu przeznaczonego dla RPI. Możemy tego dokonać na dwa sposoby.

Przekopiowanie zawartości systemu Raspbian do utworzonego katalogu

Obraz systemu Raspbian składa się z dwóch partycji (nas interesuje partycja root) dlatego poszukamy tej właściwej do zamontowania za pomocą polecenie fdisk:

Interesuje nas rozmiar każdego sektora oraz sektor startowy drugiej partycji aby wyliczyć parametry dla polecenia mount.

Rozmiar sektora (logiczny/fizyczny) w bajtach: 512 / 512
Rozmiar we/wy (minimalny/optymalny) w bajtach: 512 / 512

2014-09-09-wheezy-raspbian.img2 122880

Jedyne co trzeba teraz zrobić to wykonać skomplikowane działanie matematyczne i wyliczyć parametr offset ;) 512 * 122880 = 62914560

Następnie montujemy nasz obraz systemu Raspbian:

Teraz możemy przekopiować pliki systemowe do katalogu dla środowiska chroot:

rafal@ubuntu-rpi-vm:~/target$ sudo cp --preserve -R /mnt/temp/* ../chroot-rpi/

Parametr --preserve pozwoli nam na zachowanie specyficznych atrybutów plików. Kopiowanie odbywa się do wcześniej przygotowanego przez nas katalogu. Ja umieściłem taki katalog w katalogu domowym użytkownika, którego używam w systemie Ubuntu.

Zanim przejdziemy do kolejnego etapu, poniżej inny sposób na pracę z obrazem systemu (w tym przypadku też Raspbian).

Zamiast kopiować zawartość obrazu systemu, możemy go zamontować jako właściwe środowisko dla chroot. Sposób z wykorzystaniem polecenia mount i odpowiednimi parametrami jest już powyżej, teraz druga możliwość. Nadal zamontujemy obraz przy użyciu urządzenia loop ale używając polecenia kpartx (oczywiście musimy mieć ten program zainstalowany w systemie). W tym przypadku nie musimy obliczać wartości dla parametru offset.

Przyszła kolej na małe modyfikacje, zarówno systemu głównego jak i tego w katalogu dla środowiska chroot.

Musimy przekopiować statycznie zbudowaną wersję qemu-arm (uwaga: program musi być w takim samym katalogu, zarówno na głównym hoście jak i w środowisku chroot). Następnie musimy zamontować odpowiednie katalogi systemowe (będą potrzebne do działania różnych procesów chroot'owanego systemu, np. dla aplikacji java czy Xorg) z systemu głównego do systemu w katalogu dla środowiska chroot oraz umożliwić dostęp do sieci (Internetu).

Poniżej szczegóły tych operacji:

Zanim przejdziemy do ostatniego etapu czyli przejścia do środowiska docelowego za pomocą polecenia chroot, musimy jeszcze zarejestrować wcześniej kopiowaną wersję qemu-arm-static jako interpreter arm w kernelu głównego systemu (musimy wykonać to jako użytkownik root).

rafal@ubuntu-rpi-vm:~/target$ sudo -s
root@ubuntu-rpi-vm:~/target# echo ':arm:M::\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00
\x00\x02\x00\x28\x00:\xff\xff\xff\xff\xff\xff\xff\x00
\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff:/usr/bin/qemu-arm-static:' > /proc/sys/fs/binfmt_misc/register

(wszystko w jednej linii) Teraz możemy już „uruchomić” naszego Raspbiana :)

Poniżej przykład uruchomienia aplikacji raspi-config w środowisku chroot:

Oczywiście możemy uruchomić w takim systemie np. usługę ssh i połączyć się do takiego środowiska:

rafal@ubuntu-rpi-vm:~/target$ ssh pi@localhost

To jest połączenie z maszyny wirtualnej, na której jest środowisko chroot. Gdybyśmy chceli połączy się do tego środowiska z naszego systemu, na którym mamy uruchomioną maszynę wirtualną, wtedy trzeba ustawić odpowiednie przekierowanie portów (port forwarding) w ustawieniach sieciowych maszyny wirtualnej. Dla Virtualboxa może to wyglądać tak:

Następnie składnia jest podobna jak w opisie dla Qemu z poprzedniego artykułu:

rafal@host:~$ ssh pi@localhost -p 3022

Polecenie wydajemy na hoście, na którym jest zainstalowany Virtualbox i uruchomiona maszyna wirtualna z naszym środowiskiem chroot. Powinniśmy otrzymać rezultat jak na obrazku dla połączenia ssh powyżej.

No dobrze, a co z aplikacjami uruchamianymi w trybie graficznym ? Na to też jest sposób a nawet kilka. Możemy użyć metody xhost, połączyć się ze środowiskiem chroot przez ssh używając przekierowania X11 (opcja -X), użyć specjalnej wersji chroot (xchroot) albo zainstalować serwer VNC wewnątrz środowiska chroot.

Zobaczmy jak to działa. Najpierw spróbujemy połączyć się za pomocą ssh (połączenie z maszyny wirtualnej):

rafal@ubuntu-rpi-vm:~/target$ ssh -X pi@localhost

Poniżej wynik połączenia i uruchomienie aplikacji xpdf:

Podobny rezultat możemy osiągnąć łącząc się z hosta, na którym mamy uruchomioną maszynę wirtualną ze środowiskiem chroot.

Na koniec jeszcze jedną możliwość – z zainstalowanym serwerem VNC wewnątrz środowiska chroot.

Najpierw instalujemy serwer VNC, w naszym przypadku np. tightvnc:

root@ubuntu-rpi-vm:/# apt-get install tightvncserver

(komenda wykonywana w środowisku chroot)

Następnie możemy połączyć się z naszym środowiskiem chroot jako zwykły użytkownik za pomocą ssh i uruchomić serwer VNC. Zostaniemy zapytani o hasło dla dostępu do desktopu a następnie serwer zostanie uruchomiony na określonym porcie (domyślnie port 5901, dla pierwszej sesji vnc).

pi@ubuntu-rpi-vm ~ $ tightvncserver

Teraz możemy uruchomić klienta vnc. Na obrazku poniżej możemy zobaczyć klienta vnc uruchomionego z zewnątrz maszyny wirtualnej do serwera vnc uruchomionego w środowisku chroot. W takim przypadku musimy pamiętać aby przekierować odpowiednie porty w konfiguracji maszyny wirtualnej (wcześniej pokazałem takie przekierowanie dla usługi ssh).

Połączenie...

...oraz wynik połączenia

Jak widać powyżej możliwości jest bardzo wiele i zachęcam do poszukiwania najlepszego rozwiązania. Przykładach opisanych w niniejszym artykule pozwalają uruchomić środowisko o znacznie większej wydajności w porównaniu do emulacji Qemu, a „symulowania” systemu zanim jeszcze uruchomimy go na docelowym urządzeniu będzie w tym przypadku wygodniejsze. Oczywiście nic nie zastąpi obcowania z rzeczywistym urządzeniem (w komentarzach do poprzedniego artykułu też można było wyczytać taką sugestię), natomiast przedstawione sposoby pracy z oprogramowaniem pozwalają na zaoszczędzenie czasu np. przy kompilacji oprogramowania, pomagają w zrozumieniu budowy i zasady działania określonych rozwiązań systemowych, przetestowanie usług czy aplikacji.

Temat jest bardzo szeroki ale mam nadzieję, że te dwa artykułu dały przynajmniej podstawę do dalszych poszukiwań i eksperymentów z oprogramowaniem co sądzę może być pomocne w eksperymentowaniu z urządzeniami takimi jak RPI czy podobnymi.

Następnym razem zajmiemy się już RPI – oczywiście tym rzeczywistym a nie „symulowanym”  i aby nawiązać do jednego z komentarzy pod poprzednim artykułem, oddalimy się od "Incepcji";). Zapraszam.