💻 ARM Architektur (Raspberry Pi) Test-Umgebung simulieren 💻
Moin Nerd's und Minicomputer-Fans
Bild von planet_fox auf Pixabay
Einleitung
- Wozu sollte man sich eigentlich eine Test-Umgebung schaffen, da man eigentlich mittels "Debootstrapping" und Qemu/KVM, direkt funktionierende Images erstellen kann?
Der Bau eines eigens abgestimmten und schlanken Systemes, ist sehr Zeitaufwendig und mit der Zusammenstellung von Kern-Modulen und Firmware, ist der Betrieb nur auf ganz bestimmter Hardware möglich.
Eine Test-Umgebung ermöglicht eine Zusammenstellung von Modulen und Diensten, ohne auf Besonderheiten spezifischer Geräte (z.B. Raspberry Pi) Rücksicht zu nehmen.
Ein weiterer Vorteil besteht darin, dass man im Vorfeld die Hardware nicht benötigt. Es langt lediglich die Vorstellungen über Beschaffenheit und CPU-Architektur aus. Es ist somit möglich, in der Test-Umgebung ein System zu entwickeln und nach deren Fertigstellung, der jeweils ausgewählten Hardware anzupassen. Auch bietet die Test-Umgebung die Möglichkeit, Systeme für unterschiedlicher Hardware, mit einer allgemeinen Basis der Architektur, zu testen und zu bauen.
Grundlagen
- Eigentlich ist dieser ganze Vorgang recht einfach, aber trotzdem richtet sich dieser Beitrag an den etwas Fortgeschrittenen Nutzer. Grundkenntnisse von Linux und deren Komponenten sollten schon vorhanden sein.
In meiner Anleitung wird ein Ubuntu 18.04 als Host betrieben, auf dem ein Gast-PC, mit allgemeiner ARM-Architektur und ein Grundsystem auf Debian-Stretch-Basis, simuliert wird.
Da die Test-Umgebung nicht viel Leistung benötigt, können MS Windows-Nutzer diese Simulation, auf ein in Virtual Box installiertes Ubuntu (Lubuntu), problemlos ausführen.
Weil die Umgebung speziell der ARM-Architektur nur über Qemu und KVM ausgeführt werden kann, ist es im Vorfeld nötig, diese Pakete zu installieren und sich mit der Funktionsweise vertraut zu machen.
Eine Anleitung zur Installation und Bedienung, kann man auf Ubuntuusers.de - Qemu und Ubuntuusers.de - KVM finden.
Denkt bitte daran, dass Ihr euren Account zur KVM-Gruppe hinzufügt.
id
Falls nicht, langt ein
sudo adduser $USER kvm
Nach einem System-Neustart, solltet Ihr dann der Gruppe angehören.
Zusätzlich benötigen wir libguestfs, da in unserer Testumgebung ein Bootloader nicht nötig und vorgesehen ist. - Wir starten die fertige Umgebung ganz altmodisch manuell ;)
Um eine Grundlage (Systembasis) zu schaffen, nutzen wir in dieser Anleitung einen fertigen Debian Installer, mit dem wir ein schlankes Basissystem auf dem Emulator installieren.
Selbstverständlich kann man die selben Schritte auch mit einem selbstgebauten Installer und Kernel durchführen.
Installation Medium beschaffen
Damit es für mich etwas übersichtlicher bleibt, habe ich mir ein gesondertes Verzeichnis eingerichtet, in welches ich die Installerdateien geladen habe.
wget -O installer-linux http://http.us.debian.org/debian/dists/stretch/main/installer-arm64/current/images/netboot/debian-installer/arm64/linux
wget -O installer-initrd.gz http://http.us.debian.org/debian/dists/stretch/main/installer-arm64/current/images/netboot/debian-installer/arm64/initrd.gz
Welches Debian Ihr dafür nehmt ist ganz egal. Wer's mag, kann auch ein Stabil oder Sid nehmen. Wichtig ist in unseren Fall nur, dass sie der ARM-Architektur ( binary-arm64 ) entspricht.
Auch sollte man darauf achten, dass die beiden Dateien im selben Verzeichnis geladen und so benannt werden, dass sie nicht mit dem endgültigen Kernel und initrd verwechselt werden können, welche später bei der Installation erzeugt werden.
In meinem Fall habe ich sie "installer-linux" und "installer-initrd.gz" genannt.
Da wir unter Qemu die "virt" Karte nutzen, brauchen wir keinen separaten Gerätebaum herunterladen oder erstellen, da er durch Qemu automatisch erstellt und an den Kernel übergeben wird.
Installation der Systembasis (Testumgebung)
- ein virtuelles Laufwerk im Testverzeichnis erstellen
Je nach Bedarf kann eine Festplatte mit ausreichender Größe erzeugt werden. Unser Beispiel erzeugt ein Laufwerk mit einer Größe von 16 GB.
qemu-img create -f qcow2 hda.qcow2 16G
Da wir nun eine Festplatte haben, können wir die Installation starten.
qemu-system-aarch64 -M virt -m 1024 -cpu cortex-a53 \
-kernel installer-linux \
-initrd installer-initrd.gz \
-drive if=none,file=hda.qcow2,format=qcow2,id=hd \
-device virtio-blk-pci,drive=hd \
-netdev user,id=mynet \
-device virtio-net-pci,netdev=mynet \
-nographic -no-reboot
Dieser Befehl kann komplett in einem Schritt eingegeben werden und nach Bedarf verändert werden (siehe man qemu).
-m 1024
Dieser Parameter gaukelt einen Hauptspeicher (RAM) von 1 GB vor. Wenn man mehr wünscht, kann man es gerne ändern. Einen Umrechner findet man auf https://www.gbmb.org/gb-to-mb
Nun beginnt die Installation, welche über eine Konsole überwacht und eingerichtet wird.
Hier werden Ländereinstellung, Tastenlayout und Zeitzone ausgewählt
Sowie ein Hostname, Passwort für den Root und ein Benutzerkonto angelegt.
Insgesamt kann die Installation 1 bis 2 Stunden in Anspruch nehmen, da die ausgewählten Komponenten aus dem WWW geladen werden.
Die Partitionierung der Festplatte kann für diese Testumgehung einfach per Default angelegt werden.
Es geht schneller und ist völlig ausreichend.
Außer dem Systemkomponenten benötigen wir noch ssh. Dieses sollte schon während der Installation ausgewählt werden, da wir später im laufenden System Dateien vom Host zum Gast kopieren wollen und können.
Wenn die Installation beendet ist, erscheint am Ende noch der Hinweis darauf, dass kein Bootloader installiert wurde.
Im Parameter " no-reboot " haben wir im Vorfeld einen Reboot ausgeschlossen und können diesen Hinweis ohne weiteres quittieren.
Das System wird nun vollständig heruntergefahren. - Genau genommen stürzt es ab, aber mit dem gewollten Ziel, dass es beendet ist ;)
Es empfiehlt sich eine Kopie von dem neu erstellten System zu machen, um bei der Erstellung einer neuen Testumgebung sich eine neue aufwendige Installation ersparen zu können.
Der erste Start
Da wir ja keinen Bootloader installiert haben, müssen wir Qemu mitteilen, mit welchem Kernel das System gestartet werden soll und wo sich die "Root" befindet.
Mit folgenden Befehl lassen wir uns die Partitionen anzeigen
virt-filesystems -a hda.qcow2
Hier werden zwei Partitionen angezeigt, wovon sda1 den Einhängepunkt "/boot" hat und sda2 das Wurzelsystem "/" hat.
Wir benötigen zum Starten also sda2.
Den aktuelle funktionierenden Kernel liefert uns der Befehl
virt-ls -a hda.qcow2 /boot/
Sollte obiger Befehl sowie
virt-filesystems -a hda.qcow2
einen Fehler ausgeben, so könnte ein
sudo chmod 644 /boot/vmlinuz*
auf dem Host Abhilfe bringen.
Werden zwei Kernelversionen angezeigt, so sollte der erste (Ältere) meistens arbeiten. - Zwei Kernel hat man schnell durchprobiert ;)
Hier im Beispiel wird uns 4.9.0.13 angezeigt und wir nutzen diesen Kernel für unseren ersten Start.
virt-copy-out -a hda.qcow2 /boot/vmlinuz-4.9.0-13-arm64 /boot/initrd.img-4.9.0-13-arm64
Mit diesem Befehl werden die Komponenten in unser Hostverzeichnis kopiert.
So, das war es erstmal auch schon.
Da wir das System erstmal nur auf seine Funktionalität prüfen wollen, langt ein einfacher Befehl völlig aus.
Auch hier können Parameter je nach Bedarf geändert und hinzugefügt werden. Denkt aber bitte daran, dass wir eine funktionierende Netzwerk-, Internet-Verbindung benötigen. Dieses sollte unbedingt in den Startparametern enthalten sein.
Wenn sich jemand im Vorfeld nicht ganz sicher ist, ob seine Startangaben korrekt sind und funktionieren, kann man sich ja Dateien aus einem Bootloader eines funktionierenden Systems anschauen und die Startparameter dementsprechend ableiten und testen - habe ich ebenfalls so getan und nach ein paar Versuchen ist es mir dann tatsächlich gelungen ;)
qemu-system-aarch64 -M virt -m 4096 -cpu cortex-a53 \
-kernel vmlinuz-4.9.0-13-arm64 \
-initrd initrd.img-4.9.0-13-arm64 \
-append 'root=/dev/vda2' \
-drive if=none,file=hda.qcow2,format=qcow2,id=hd \
-device virtio-blk-pci,drive=hd \
-netdev user,id=mynet \
-device virtio-net-pci,netdev=mynet \
-nographic
Mit den obigen Angaben, sollte es ohne Fehlermeldungen sauber starten
und wir können uns entweder mit dem Benutzerkonto oder Root anmelden
Ein Test ob die Paketquellen und das Internet funktionieren, kann man als root mit
apt-get update
starten.
Unser System sollte so kurz nach der Installation eigentlich auf dem neusten Stand sein.
Abschluß
Jetzt haben wir auf ziemlich einfacher Weise eine Testumgebung für ARM-Architekturen aller Art geschaffen und können nun anfangen unser System um Komponenten und Diensten zu erweitern und zu testen.
Ich sehe diese Testumgebung als gutes Hilfsmittel, mit dem ich Systeme erweitern und verändern kann, ohne sie auf einer speziellen Hardware ausführen zu müssen. - Mir ging nämlich dieses ständige auf SD-Karte kopieren und Hardware starten mächtig auf den Senkel :-)
Eine Bitte habe ich am Schluss noch. Bevor Ihr mit der Installation dieser oder einer anderen Testumgebung anfangt, solltet Ihr euch unbedingt mit der Bedienung von KVM/Qemu vertraut machen und eventuell erstmal an einer einfachen Installation eines Betriebssystems üben.
Für Neueinsteiger können diese Befehle schon sehr verwirrend und nichtssagend wirken, aber mit etwas Übung und der richtigen Lektüre ( https://help.ubuntu.com/community/KVM ) ist es durchaus Machbar ;)
Schönen Tag noch und frohes basteln
Posted with STEMGeeks
Congratulations @stuntman.mike! You have completed the following achievement on the Hive blockchain and have been rewarded with new badge(s) :
You can view your badges on your board and compare yourself to others in the Ranking
If you no longer want to receive notifications, reply to this comment with the word
STOP
Do not miss the last post from @hivebuzz:
I hope some day get one and try to learn about it.
Your decision!
Erst mal Bookmark und Reblog gesetzt. So ein Beitrag von Dir bürgt von hoher Qualität und viel Arbeit. Den werde ich mir mit mehr Zeit ansehen müssen. Fundiertes Feedback kommt also noch.Es kann ja auch als wirklich gute Dokumentation auf der Blockchain genutzt werden. Löschen ist ja nicht mehr. (Den Bilden könnte es an den Kragen gehen.
Ich finde es immer wieder sehr schade wie sehr personenabhängig das Voten von Posts ist und Du da keine Unterschiede machst.
Respekt! Der gleiche Post hätte jetzt schon ein vielfaches an Money eingenommen.
Liebe Grüße Michael
!invest_vote
!jeenger
Dem kann ich eigentlich nur zustimmen.
@mima2606 denkt du hast ein Vote durch @investinthefutur verdient!
@mima2606 thinks you have earned a vote of @investinthefutur !
Your contribution was curated manually by @mima2606
Keep up the good work!